Re: request to sign software

From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Keir Fraser <keir.fraser@eu.citrix.com>,
	Stephen Spector <stephen.spector@citrix.com>
Subject: Re: request to sign software
Date: Mon, 29 Mar 2010 10:47:20 -0700	[thread overview]
Message-ID: <4BB0E7A8.10403@goop.org> (raw)
In-Reply-To: <4BAF2918.4040207@invisiblethingslab.com>

On 03/28/2010 03:02 AM, Joanna Rutkowska wrote:
> Just a rather obvious request that you digitally sign all the published
> tgz packages, as well as hg/git tags, so that it was possible to ensure
> that the software I download from xen.org (or fetch from Jeremy's GIT)
> is authentic. This is especially important for those people who would
> like to build (and distribute!) their own products based on Xen.
>
> Hopefully you can start doing this with the upcoming 4.0.0 and 3.4.3
> versions of Xen, and the "official" pvops kernels (hopefully there will
> be some pvops commit tagged as "official"? I assume from
> xen/stale-2.6.32.x?)
>    

(I prefer to call it "stable", but I can see how one might get them 
confused ;)

That's an interesting idea.  But I don't think we have any 
infrastructure in place to make those signatures meaningful (ie, some 
way of usefully connecting a particular signature to a particular 
maintainer).

I guess the logical thing would be for xen.org to have a GPG cert, which 
could then sign our individual certs.  (Or something.  How does web of 
trust extend to "I'm confident this changeset is valid"?)  Then its just 
a problem of how to propagate the xen.org cert in some way so that some 
way that everyone agrees is meaningful.

On the other hand, I'm not sure how much value such signatures would 
have.  At the moment they would just certify "this is something I 
committed", but with not particular guarantees about any of the 
properties of that commit.   Commits to the stable (or any branch, of 
either kernel or Xen) are really a matter of best effort, but they may 
still be broken, insecure, etc.  Anyone using those trees bears some 
responsibility for making sure they meet their particular requirements 
(or delegate those qualification checks to someone they trust, like a 
distro).

If we added a specific meanings to tags (like, "this has passed 
automatic regression testing"), then adding a signature would perhaps be 
more meaningful.  But that signature would presumably be added by the 
test infrastructure rather than a committer.

Signatures on tar files makes a bit more sense, because they don't have 
the backing of git/hg to guarantee the integrity of the file contents, 
but there's still the question of how to make those signatures meaningful.

     J