[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <517939B4.2040207@fifthhorseman.net>
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.
