[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 21 Apr 2013 20:59:29 +0200
From: Marcus Meissner <meissner@...e.de>
To: oss-security@...ts.openwall.com
Cc: Solar Designer <solar@...nwall.com>
Subject: Re: upstream source code authenticity checking
On Sun, Apr 21, 2013 at 10:05:53AM -0700, Alan Coopersmith wrote:
> On 04/20/13 01:39 PM, Solar Designer wrote:
>> 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.)
>
> Coming from one of the common upstreams (X.Org), it would really be
> helpful if there was a "Best Practices" page we could reference, since
> we've gotten a couple complaints that we're not doing enough, but not
> concrete enough suggestions that we can go modify our release script to
> implement them. (Currently we include MD5, SHA1, & SHA256 checksums in
> the release announcement e-mails, which we tell maintainers to pgp sign
> with their own keys when sending - though unfortunately most of the
> mailing list archives break the ability to verify when they mangle
> email addresses to prevent spam harvesting from their archives.)
>
> If there was a common standard, with instructions, we'd be far more
> likely to spend the time to adopt it, than just a "make signatures
> appear somewhere, in an unspecified format".
SUSE has started to adjust its spec files to help here,
1. we use full Source URLs for the download tarballs.
This can ensure that the tarballs do not change, or if they change
a warning can pop up.
2. We are trying GPG signature checking, in cases where parallel to the tarball
lies a .sig or .asc file and there is a known keyring.
started here:
http://lists.opensuse.org/opensuse-factory/2012-12/msg00235.html
In case they are provided:
a. We refer the .sig/.asc file as with Source URL in the .spec file
b. We store the keyring in the package sources, also as a Source (no URL)
c. We use RPM macros to verify the gpg signature during build.
Our source review team has to check when the keyring changes.
This has the usual problems:
- Usage of gpg causes buildcycles if you do full transient builds of the distribution.
- Need to verify the keyring at begin and also when it changes somehow.
But yes, for upstream source providers I think it would really be nice if
they would also sign their binaries and upload the signature in parallel.
And also publish their keyring and let some keys be in the chain of trust
that could be gained from e.g. Linux fairs/conferences (LinuxTag usually
does keysigning etc.)
Savannah hosting does parts of that already, the hosting service also
offers the keyring per project.
Ciao, Marcus
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.
