Date:	Tue, 25 Oct 2011 00:31:36 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Greg KH <greg@...ah.com>
Cc:	Jari Ruusu <jariruusu@...rs.sourceforge.net>,
	linux-kernel@...r.kernel.org
Subject: Re: kernel.org tarball/patch signature files

On Mon, Oct 24, 2011 at 21:49, Greg KH <greg@...ah.com> wrote:
> Please realize that we are building this whole thing back up from
> scratch here, and some services are not possible to do just yet.
>
> Also realize our constraints.  I don't want to, and in fact it's almost
> impossible to, upload the 3 compressed tarballs over a large number of
> internet connections that I have access to as I travel around the world.
> So, given that you don't want all kernel release maintainers to store
> their private keys on the server (remember what just happened), the
> ability to generate that signature would be a pretty difficult thing,
> right?
>
> So, we are working on a proposal that has a "throw away" signature for
> the compressed files, that can be verified by people after they download
> the tarball to ensure that they didn't get something "odd".  That will
> handle the sha256sum, and allow us to add future compression types with
> no need to regenerate the "real" signatures from the original release.
>
> The real check, to verify that this tarball really came from "me" should
> be done on the uncompressed tarball, which is what I can sign, and it is
> something that you, or anyone else, can reliable duplicate on their own
> by just using git and not even downloading the tarball at all.
>
> In other words, we just saved you a MASSIVE bandwidth transation for all
> of your future kernel downloads, and you can reliable know that the
> tarball you have in your system is what is on the kernel.org servers
> without you even having to download it yourself and run those
> decompression tools that you don't trus.
>
> And still you complain :)
>
> Hope this helps explain why this is the way it is.  It's as if people
> think we are just making it up as we go along...

Well, in theory it could still be done (albeit not in practice right now).

There is a tool called "pristine-tar" designed to generate a
byte-identical tar.gz given the original source tree.  Obviously with
git-archive you don't need the "tar" portion, but it also includes
"pristine-gz" and "pristine-bz2" tools which tease out and store the
original compression parameters in a small file.  It's commonly used
to be able to "import" a bunch of source files and a tarball into GIT
without storing the entire original tarball as a binary file.

So the kernel developers would locally produce the uncompressed and
compressed tarballs, then digitally sign them and create small
"pristine-{gz,bz2,xz}" archive deltas; the signatures and deltas would
be uploaded.

The kernel.org server would use the original input and compression
parameters to reconstruct the byte-identical compressed archive from
the output of "git archive --format=tar", again with the "pristine-*"
tools.

Unfortunately, while there are "pristine-gz" and "pristine-bz2" tools,
there has not yet been developed a "pristine-xz" tool:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499489

So it's not yet reasonably possible for the kernel.org archive, but
sometime in the future it might become so.

Cheers,
Kyle Moffett

-- 
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists