oss-sec mailing list archives

Re: upstream source code authenticity checking


From: Marcus Meissner <meissner () suse de>
Date: Sun, 21 Apr 2013 20:59:29 +0200

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


Current thread: