oss-sec mailing list archives
Re: upstream source code authenticity checking
From: Daniel Kahn Gillmor <dkg () fifthhorseman net>
Date: Thu, 25 Apr 2013 22:12:04 +0800
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
Attachment:
signature.asc
Description: OpenPGP digital signature
Current thread:
- Re: upstream source code authenticity checking, (continued)
- 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 Alistair Crooks (Apr 26)
- Re: upstream source code authenticity checking Kurt Seifried (Apr 26)
- Re: upstream source code authenticity checking Eric H. Christensen (Apr 29)
- Re: upstream source code authenticity checking Daniel Kahn Gillmor (Apr 30)
- Re: upstream source code authenticity checking Robbie MacKay (May 01)