From: Joanna Rutkowska <joanna@invisiblethingslab.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: Different xen-3.4.3.tar.gz in Fedora RPM
Date: Fri, 18 Jun 2010 15:07:40 +0200 [thread overview]
Message-ID: <4C1B6F9C.3080300@invisiblethingslab.com> (raw)
In-Reply-To: <C8412BD7.17D2F%keir.fraser@eu.citrix.com>
[-- Attachment #1.1: Type: text/plain, Size: 1790 bytes --]
On 06/18/2010 02:57 PM, Keir Fraser wrote:
> On 18/06/2010 13:10, "Joanna Rutkowska" <joanna@invisiblethingslab.com>
> wrote:
>
>> So, I downloaded xen-3.4.3.tar.gz from fedora mirror (using their
>> original Makefile for RPM building), and diffed the two versions --
>> changes (cosmetic cleanup mostly) are innocent, but, hey, why would
>> anybody do such a thing? After allm we would expect only one version of
>> xen-XXX.tar.gz, right? Patches should be the proper way for customizing
>> tarballs for packaging, no?
>>
>> Or am I missing something?
>
> Well, I think this and your other point have one simple answer. If I wanted
> the maximum possible confidence in the bits I was building, I would obtain
> them from the original source, as it were. In this case that means, for
> example:
> # hg clone -r RELEASE-3.4.3 http://xenbits.xensource.com/xen-3.4-testing.hg
> If you want your own tarball for some reason:
> # hg archive -t tgz xen-3.4.3.tar.gz
>
> It doesn't seem very hard to me. I maintain the repo and sign the releases
> myself.
But you *do* publish sigs for Xen 4:
http://bits.xensource.com/oss-xen/release/4.0.0/xen-4.0.0.tar.gz.sig
So, why can't you do the same for 3.4.3 tarball?
Sure, I could use hg in my RPM Makefile, but this would require me to
install hg first, and also the download process I think takes longer
than if it was a simply tar, and also requires to create a tmp directory
that later must be removed.
> Downloading tarballs from Fedora, or even from our own xen.org
> website, introduces more people between you and me. And it seems you
> very likely care about that.
>
From the security point of view it doesn't matter, as long as both are
signed by one of the keys signed by xen.org.
j.
[-- 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
next prev parent reply other threads:[~2010-06-18 13:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-18 12:10 Different xen-3.4.3.tar.gz in Fedora RPM Joanna Rutkowska
2010-06-18 12:23 ` Joanna Rutkowska
2010-06-18 12:39 ` Pasi Kärkkäinen
2010-06-18 13:25 ` M A Young
2010-06-18 12:57 ` Keir Fraser
2010-06-18 13:07 ` Joanna Rutkowska [this message]
2010-06-18 13:19 ` Keir Fraser
2010-06-18 15:42 ` Ian Jackson
2010-06-18 16:00 ` Joanna Rutkowska
2010-06-18 13:47 ` M A Young
2010-06-18 13:31 ` John Haxby
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=4C1B6F9C.3080300@invisiblethingslab.com \
--to=joanna@invisiblethingslab.com \
--cc=keir.fraser@eu.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.