Date: Thu, 25 Apr 2013 07:55:59 +0200 From: Alistair Crooks <agc@...src.org> To: oss-security@...ts.openwall.com Subject: Re: upstream source code authenticity checking On Wed, Apr 24, 2013 at 10:19:15PM -0400, Eric H. Christensen wrote: > This is a good discussion to have. I've recently started working on > "best practices" articles at Red Hat and feel this would make an > excellent article on how we can all improve the security of our > source code that inevitably gets pushed into the various > distributions. > > What is really the best, most proper way of desiminating releases? > I really don't like the use of MD5 for checksums (I'd prefer > something out of the SHA-2 or SHA-3 family of hashing algorithms) > and I really *do* like the use of PGP for signing the code. I do > foresee some practices within the use of PGP that might not be > great, though. > > So what is the best way of authenticating the source code? My apologies - obviously I didn't make myself clear previously. Verifying a signature on a (SHA1, by default) digest will get you the information that a person with access to the private key said that the digest was calculated at a certain time. It also leads to the following questions: Q1. who has access to the private key? A1. divulgence of creds and the key itself may be known or not, so even with the most stringent key protection and hygiene in place, the answer to (1) is "unknown" Q2. is the key protected by a passphrase? A2. We'll never know. It's irrelevant too, due to Q1/A1 Q3. has the key expired or been revoked? A3. At last, one we can answer. Of course we'll know when it expires. Unfortunately, revocation may make itself to key servers, maybe not. And even if it did, what was the last time of refresh for the public key that we have? Q4. where's the public key for this? A4. could be anywhere. If it's on one of the HKP servers, then cool. Not, however, that it can be verified - I know of at least one person who has had pubkey information uploaded to the key servers for a key he had no knowledge about. Anyone can put whatever email address into the userid that they want. If it came with the tarball, ho hum. Q5. what was signed? A5. if it comes out as a text document, according to RFC 4880, it has some weird properties; hopefully all tar files will be binary. Whatever, what was signed was something with the same digest as the tarball. Default algorithm is SHA1. Second pre-image attacks on SHA1 are getting closer to being possible, and there are means to modify entries in the tarball so that an attack is much easier. Q6. Is this a DSA key? (DSA keys rely on good entropy at signing time) If so, how good was the entropy on the machine used to generate the signature? A6. Again, unknown. Q7. Has someone found the k value for Q6/A6 previously? A7. They might have done. We'd only know if they told us. Q8. Did anyone have root access to the machine where gpgagent was running? A8. unknown 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? Regards, Alistair
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.