oss-sec mailing list archives
Re: upstream source code authenticity checking
From: Stuart Henderson <sthen () openbsd org>
Date: Mon, 22 Apr 2013 09:52:52 +0100
On 2013/04/22 01:27, Alistair Crooks wrote:
On Sun, Apr 21, 2013 at 12:39:39AM +0400, Solar Designer wrote:Hi, I just found this recent blog post by Allan McRae of Arch Linux: http://allanmcrae.com/2012/04/how-secure-is-the-source-code/ Thank you for doing this, Allan! Are you contacting the upstream authors to request that they start to properly sign their releases? (I've been doing that on some occasions, sometimes with success.) I think that placing both "MD5 checksum provided on same site as download" and "PGP signature, key difficult to verify" in the same "yellow" category is inconvenient for us. "MD5 checksum provided on same site as download" only helps verify downloads from mirrors against the master site, whereas "PGP signature, key difficult to verify" achieves a lot more - once a distro is already including the package (and has already taken the risk of it having been tampered with), then verifying further updates to the package becomes almost as reliable as it would have been with proper signing (with a "readily verifiable" key). So we need four categories, or simply "MD5 checksum provided on same site as download" should be in "red", not in "yellow".The BSD ports and packages systems have had this checking in place since day 1, and with different checksums - FreeBSD now use sha256, pkgsrc uses sha1 and rmd160, and I don't know what OpenBSD uses; the digests are all held as part of the packaging system itself. One of the side benefits of this is recognising when upstream changes tarballs without changing version numbers. I think the Arch Linux people could leverage the work done here. Regards, Alistair
OpenBSD changed to sha256 for this 5 years ago, we also check file size. This does cause some problems for projects which rely on dynamically generated tarballs though; in the past we've had trouble with github and bitbucket (they seem to be somewhat stable at the moment but I'm not convinced it won't happen again). Has anyone come up with a better way to handle that situation? I wonder if it might be worth looking at infrastructure to verify PGP signatures as part of the framework too though, this is potentially useful for updates.
Current thread:
- upstream source code authenticity checking Solar Designer (Apr 20)
- Re: upstream source code authenticity checking Alan Coopersmith (Apr 21)
- Re: upstream source code authenticity checking Marcus Meissner (Apr 21)
- Re: upstream source code authenticity checking Jeremy Stanley (Apr 21)
- Re: upstream source code authenticity checking Allan McRae (Apr 21)
- Re: upstream source code authenticity checking Alistair Crooks (Apr 21)
- Re: upstream source code authenticity checking Allan McRae (Apr 21)
- Re: upstream source code authenticity checking Alistair Crooks (Apr 21)
- Re: upstream source code authenticity checking Stuart Henderson (Apr 22)
- Re: upstream source code authenticity checking Allan McRae (Apr 21)
- Re: upstream source code authenticity checking Eric H. Christensen (Apr 24)
- Re: upstream source code authenticity checking Alistair Crooks (Apr 24)
- Re: upstream source code authenticity checking Allan McRae (Apr 24)
- Re: upstream source code authenticity checking Kurt Seifried (Apr 25)
- Re: upstream source code authenticity checking Daniel Kahn Gillmor (Apr 25)
- Re: upstream source code authenticity checking Alistair Crooks (Apr 25)
- Re: upstream source code authenticity checking Kurt Seifried (Apr 25)
- Re: upstream source code authenticity checking Dag-Erling Smørgrav (Apr 26)
- Re: upstream source code authenticity checking Kurt Seifried (Apr 26)
- Re: upstream source code authenticity checking Dag-Erling Smørgrav (Apr 26)
- Re: upstream source code authenticity checking Alistair Crooks (Apr 24)
- Re: upstream source code authenticity checking Alan Coopersmith (Apr 21)