oss-sec mailing list archives
Re: upstream source code authenticity checking
From: Alistair Crooks <agc () pkgsrc org>
Date: Fri, 26 Apr 2013 07:24:24 +0200
On Thu, Apr 25, 2013 at 08:55:00AM -0400, Josh Bressers wrote:
So, all in all, what you have is a digest, signed by someone who knows the key, or who has access to the creds (if any) for the key, or who has found out the key creds, albeit with timestamp info for when the signature took place. I'm not sure what using PGP gains us?I'm going to take a hard stance against this statement and use it as my soapbox for a bit here. This attitude is really dangerous in the world of security (but it has infected our universe). Security is hard, we all know that, but I think we like to draw a line at 100% and say "it's this or nothing". No, PGP isn't perfect, but it gains us a ton. It's a way we can say "this was signed by someone with the key". Did the bad guy have they key? Maybe, the goal isn't to get to 100%, it's to make the job of an attacker harder, which this would do. There is no system that exists in this instance that is 100% safe. What we need to do isn't talk about how useless PGP is (which it isn't), we need to talk about what's right about it and give advice so people understand how to avoid silly mistakes.
I think you misunderstand me. The mail I sent out was to warn against the magic "it's signed, so it's gospel" myth by pointing out the problems of key management. I have written my own pgp/rfc4880 implementation, and talked about it at EuroBSDcons in 2009, 2010, 2011. I would hardly do that if i thought PGP was "useless". It's a bit disappointing that my advice (in pointing out ways that PGP can be worked around in order to diminish integrity and security) was categorised as an attack on PGP itself - I shall take that as a reminder that I should be more clear in what I write.
A great example is to use a smart card. If a project is using a smart card, and tells us they're using a smart card, that would be helpful in letting us know their signatures are probably trustworthy. We would certainly know their signatures are more trustworthy than a project who uses a private key shared between 10 people. Is the smart card a perfect solution? Certainly not, but it's better than not using a smart card. How many non security people really understand this? How many of us have tried to explain it in a calm and understanding manner?
I fail to see how "using a smartcard" automatically leads to signatures "probably being trustworthy". Lest I'm misunderstood again - 2 factor authentication is good, yes, but you need to look at the set up holistically. If an unauthorised third party has root on the server being used to control the 2 factor auth, then you are in a worse position than not using 2 factor auth. Consider the SSL business model where the CAs have considerable motivation not to disclose intrusions, mis-issued certs and other such items. In the case of Diginotar, they were put out of business. And before people start telling me to get real, I'll point out that most enterprises these days have a basic assumption that they have been hacked, and are building "more secure" islands to try to fence intrusions in.
This is Red Hat's goal here. We want to help folks understand what some easy wins are. Security is hard, it will never be 100%. I'd rather see us all working together to improve what we can.
I'm all for rasing the bar. My previous mail was intended to make people think about the processes and procedures behind key management - I'm sorry it failed so dismally. I shall attempt to do better next time. If Red Hat document their key management procedures, that would be great. Having these procedures audited would be superb (albeit a very brave step), and I would be very impressed if they did. I'm not sure security is as hard as you're making out, although I'm aware that there's no silver bullet. Onwards and upwards... Regards, Alistair
Current thread:
- Re: upstream source code authenticity checking, (continued)
- Re: upstream source code authenticity checking Daniel Kahn Gillmor (Apr 30)
- Re: upstream source code authenticity checking Robbie MacKay (May 01)
- Re: upstream source code authenticity checking Alistair Crooks (May 02)
- OpenPGP certifications are identity assertions [was: Re: upstream source code authenticity checking] Daniel Kahn Gillmor (May 02)
- Re: OpenPGP certifications are identity assertions [was: Re: upstream source code authenticity checking] Simon McVittie (May 02)
- Re: upstream source code authenticity checking Kurt Seifried (May 02)
- Re: upstream source code authenticity checking Russ Allbery (May 02)
- Re: upstream source code authenticity checking Alan Coopersmith (May 02)
- Re: upstream source code authenticity checking Russ Allbery (May 02)
- Re: upstream source code authenticity checking Josh Bressers (Apr 25)
- Re: upstream source code authenticity checking Alistair Crooks (Apr 25)
- Re: upstream source code authenticity checking Marcus Meissner (Apr 26)
- Re: upstream source code authenticity checking nicolas vigier (Apr 25)
- Re: upstream source code authenticity checking Alistair Crooks (Apr 25)
- Re: upstream source code authenticity checking Florian Weimer (Apr 26)
- Re: upstream source code authenticity checking yersinia (Apr 26)
- Re: upstream source code authenticity checking Daniel Kahn Gillmor (May 04)