Date: Thu, 25 Apr 2013 22:12:04 +0800 From: Daniel Kahn Gillmor <dkg@...thhorseman.net> To: oss-security@...ts.openwall.com CC: Kurt Seifried <kseifried@...hat.com>, Alistair Crooks <agc@...src.org>, Josh Bressers <bressers@...hat.com> Subject: Re: upstream source code authenticity checking On 04/25/2013 03:30 PM, Kurt Seifried wrote: > At a minimum this raises the bar for attackers when trying to insert a > fake release/whatever. The real problem however is the cost of doing > this. Key creation/storage/management/backup/etc is all non trivial > and not free. Is the cost of this worth it? Yes, this cost is worth it. People who take the time to publish source code on the dirty dirty internet have a responsibility to their users to take the integrity of their publications seriously. The simple workflow of "the release manager has the OpenPGP key for the project on the keyring of her personal development machine" (while probably less robust than the ideal scenario), has an extremely low cost to implement and raises the bar for an attack significantly. > I think if we are going to push this we need to come up with a pretty > good set of guidelines that are easy to follow and implement. Things > like creation of keys, usage, storage, how to handle key roll overs, > lost keys, etc. These would be great things to have, but many projects aren't even signing their releases yet. I don't want us to spec out a byzantine ruleset that would put people off from *starting* to sign their releases. Maybe such a policy could break out the sophisticated stuff into the form of "baseline", "level 1", "level 2", etc. That way we could encourage all projects to get to the "baseline" (which should be short and simple) without requiring them to "level up" right away (to offline key storage, key transition statements, etc). Some existing ideas about "best-practice" for maintaining an openpgp key (and public keyring) have been collected here, though they aren't specific to software publishers: https://we.riseup.net/debian/openpgp-best-practices (it's a wiki, folks are invited/encouraged to improve it) > Maybe even have a trusted party signs packages sent to > them, confirms the package with the project through some other trusted > channel like secure email or because they know the guy in real life/etc. i'm not sure who "the guy" is, but there's nothing stopping anyone with intimate knowledge of the free software ecosystem (e.g. maybe one of the foundational distros?) from certifying packaged releases and publishing them. Arguably, the distros that sign their source manifests are already doing this work, though they may be in different forms from one another or from upstream. for public third-party assertions to be useful in the real world, though, there needs to be easy/public audit infrastructure that anyone can run to catch the appearance of malicious/variant versions. Regards, --dkg Download attachment "signature.asc" of type "application/pgp-signature" (1028 bytes)
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.