RPM: signing uncompressed data instead of signed data?

[James Antill]

On Thu, 2010-11-11 at 10:17 -0500, Andre Robatino wrote:
> James Antill wrote:
> 
> > IMO, as has been said before, if you have a delta method that doesn't
> > produce the exact same bits at the end ... you've probably failed. It
> > might seem like a good idea, but even if you go to the extreme lengths
> > needed to make it just for yum ... things like reposync won't be able
> > to use it, Eg.
> >
> >  http://james.fedorapeople.org/python/delta-rpm-dir.py
> 
> I realize there's a lot of stuff sitting on top of RPM that depends on
> how it works currently

 Maybe I wasn't clear ... the above code doesn't "depend on rpm" it
depends on the bits being identical, as it's used to speed up mirroring
Fedora (so the bits have to be identical for the mirror users).

> , but in terms of correctness, it still seems to
> me to make more sense to sign the uncompressed data, since that's what
> actually gets used

 "used" is a loaded word here, as others have said from the point of
view of different parts of yum/rpm it's the downloaded bits that are
"used" and the uncompressed bits that are output.

> , and it would avoid issues like
> https://fedorahosted.org/rel-eng/ticket/4224 which will have to be dealt
> with periodically as long as compression continues to improve. So let me
> rephrase the question: in an alternate universe where RPM was originally
> designed to sign the uncompressed data, and the higher-level tools were
> subsequently designed to work with that, is there any fundamental reason
> why things would be worse (or better) than they are now?

 So assuming we could magically change everything, what would we need to
do stop any differences in compression from causing problems? In theory
we could publish everything as uncompressed ... and then use http
content-encoding to add xz/etc. compression back.
 But that'd break everything that's non-http ... and any http clients
that don't do content-encoding (and AFAIK no client/server currently
supports xz in content-encoding).

 The other option is for someone to add compat. code into xz, so we can
say things like "compress how you would have with version x.y.z".