All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
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 23:09:26 +0200	[thread overview]
Message-ID: <4BB11706.5020301@invisiblethingslab.com> (raw)
In-Reply-To: <4BB0E7A8.10403@goop.org>


[-- Attachment #1.1: Type: text/plain, Size: 4684 bytes --]

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.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 226 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

  reply	other threads:[~2010-03-29 21:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-28 10:02 request to sign software Joanna Rutkowska
2010-03-29 17:47 ` Jeremy Fitzhardinge
2010-03-29 21:09   ` Joanna Rutkowska [this message]
2010-03-30  7:00     ` Keir Fraser
2010-03-30  9:46       ` Joanna Rutkowska
2010-03-30  9:59         ` Keir Fraser
2010-04-01 16:37       ` Ian Jackson
2010-04-01 20:06         ` Weird RAM handling with Xen 3.4.3-RC3 Thomas Goirand
2010-03-30  9:58   ` request to sign software Joanna Rutkowska

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BB11706.5020301@invisiblethingslab.com \
    --to=joanna@invisiblethingslab.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=jeremy@goop.org \
    --cc=keir.fraser@eu.citrix.com \
    --cc=stephen.spector@citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.