oss-sec mailing list archives
Re: upstream source code authenticity checking
From: Alistair Crooks <agc () pkgsrc org>
Date: Fri, 26 Apr 2013 07:41:47 +0200
On Thu, Apr 25, 2013 at 03:40:46PM +0200, nicolas vigier wrote:
On Thu, 25 Apr 2013, Alistair Crooks wrote: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.Even if the key comes with the tarball, if the tarball is always signed with the same key for all releases, then it's useful. You download the key the first time, keep it somewhere (for instance in the package source) and use it again to check next releases. And if a new release is signed with a different key you know you need to be more careful and can check if the key change is legitimate.
Possibly. You actually know very little about the key before and after the signing took place; so you have no way of ascertaining whether the key has been used to sign other things fraudulently. Where a role account is used to sign packages, this is more worrying. But, yes, I'm being alarmist here again. I do agree that signing things is way better than not; but I am also well aware that just because something is signed does not mean that it should be treated as being without need of security.
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.Same could be said about ssh, tls or almost anything using cryptography ...
Absolutely, they share the same building blocks - see the Karlsruhe 2010 proceedings for how to interchange ssh and pgp keys for signing and verification. And the only difference between SSL and PGP is the assurance model - whether a trusted third party should be used (FSVO "trusted"), or whether that should be crowdsourced to the web of trust model. Regards, Alistair
Current thread:
- OpenPGP certifications are identity assertions [was: Re: upstream source code authenticity checking], (continued)
- 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)