|
Message-ID: <20130422085252.GG1588@symphytum.spacehopper.org> Date: Mon, 22 Apr 2013 09:52:52 +0100 From: Stuart Henderson <sthen@...nbsd.org> To: oss-security@...ts.openwall.com Subject: Re: upstream source code authenticity checking 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.
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.