lkml.org 
[lkml]   [2011]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: kernel.org tarball/patch signature files
On Mon, Oct 24, 2011 at 21:49, Greg KH <greg@kroah.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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2011-10-25 06:35    [W:0.085 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site