On 03/29/2010 07:47 PM, Jeremy Fitzhardinge wrote:
> 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.
>
gpg --gen-key
...and then publish it on xen.org and sent to xen-devel. The list is
mirrored in a few places, so it would not be trivial for the attacker to
subvert the public key in all the public archives. Users can always use
more than one different internet connections to verify the key, to get
around potential compromise at an ISP level.
This could be your "master key" and then you could simply sign other
keys (e.g. Jermey's, Keir's, etc) with this master key (simple gpg -s,
no certs, no web of trust, needed).
> 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).
>
Digital signature are *not* meant to assure any property of the signed
entity, except for its integrity and authenticity. It's perfectly ok
that you might sign a buggy version of Xen or pvops kernel. Signing is
*not* assuring correctness!
The decision of whether to trust or not the vendor (e.g. Citrix, Jeremy,
etc) is beyond the scope of digital signatures.
However, once I made a decision to trust e.g. Ctrix and let their
hypervisor run on my hardware, in my network, and have access to all my
data, then I would like to make sure that it is only Cirtix that I need
to trust really. Not tens of other engineers that are in between me and
Citrix (or even more precisely Jeremy or Keir). Those tens (or
hundreds?) other people I need to trust today (i.e. when your software
is not signed) are e.g.:
1) all the IT stuff at Citrix that have access to xen.org webserver,
2) all the IT stuff at the data center where Citrix servers are hosted,
3) all the IT stuff having access to all the network routers (especially
at the ISP) that are between me and xen.org (or git.kernel.org)
And I also need to trust e.g. that WPA2 is secure, so I can assume that
when I'm downloading the latest Xen when sitting in my living room over
WiFi, that nobody that is in my vicinity can subvert this transmission
(which is, of course, HTTP over WiFi).
> 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.
>
Please do not confuse digital signatures with a certification process.
Also, look at The Linus Tree, it has all the tags digitally signed, e.g:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tag;h=4ac8e07ee3f251ae32329a24e0b01a316b21ead9
And final argument -- one of the Xen's main selling points (especially
in case of client hypervisors) is *security*. You cannot build secure
product from building blocks that you cannot verify are coming from the
right supplier (that you chose to trust).
joanna.
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home