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:
- upstream source code authenticity checking Solar Designer (Apr 20)
- Re: upstream source code authenticity checking Alan Coopersmith (Apr 21)
- Re: upstream source code authenticity checking Marcus Meissner (Apr 21)
- 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 Alistair Crooks (Apr 24)
(Thread continues...)
- Re: upstream source code authenticity checking Alan Coopersmith (Apr 21)