Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Stuart Henderson <sthen-7YlrpqBBQ3VAfugRpC6u6w <at> public.gmane.org>
Subject: Re: upstream source code authenticity checking
Newsgroups: gmane.comp.security.oss.general
Date: Monday 22nd April 2013 08:52:52 UTC (over 4 years ago)
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.
 
CD: 3ms