RPM: signing uncompressed data instead of signed data?

[Andre Robatino]

I came across the following old post, which I'm not responding to in-thread due
to its age.

https://www.redhat.com/archives/fedora-devel-list/2009-September/msg00517...

The question was raised why RPMs sign their compressed data, rather than
uncompressed. (One advantage would be to avoid deltarpm rebuild failures due to
changes in compression such as the recent one in xz.) The answer had to do with
the fact that higher-level tools (createrepo and yum) depend on the current
behavior, but that doesn't address whether it's just an early design mistake
that we're locked into now, or if there's actually some overall advantage to
doing things this way (that outweighs the obvious disadvantage of inflexibility
in how the data is compressed). Can anyone shed some light on this?

[Bruno Wolff III]

On Thu, Nov 11, 2010 at 10:41:13 +0000,
  Andre Robatino <robatino(a)fedoraproject.org&gt; wrote:
>  
>  The question was raised why RPMs sign their compressed data, rather than
>  uncompressed. (One advantage would be to avoid deltarpm rebuild failures due to
>  changes in compression such as the recent one in xz.) The answer had to do with
>  the fact that higher-level tools (createrepo and yum) depend on the current
>  behavior, but that doesn't address whether it's just an early design mistake
>  that we're locked into now, or if there's actually some overall advantage to
>  doing things this way (that outweighs the obvious disadvantage of inflexibility
>  in how the data is compressed). Can anyone shed some light on this? 
Uncompressing hostile data is generally not a good thing to be doing. From
that aspect it makes more sense to sign the compressed payload.

[James Antill]

On Thu, 2010-11-11 at 10:41 +0000, Andre Robatino wrote:
>  I came across the following old post, which I'm not responding to
> in-thread due
>  to its age.
>  
>  https://www.redhat.com/archives/fedora-devel-list/2009-September/msg00517...
>  
>  The question was raised why RPMs sign their compressed data, rather than
>  uncompressed. (One advantage would be to avoid deltarpm rebuild failures due to
>  changes in compression such as the recent one in xz.) 
 That's not true, there are four checks for delta rpms:

1. yum-presto runs checksums on the installed rpm, and the downloaded
deltarpm. If these pass it then creates a new .rpm from those two
sources.

2. Yum then checks that any rpm it has on disk matches the checksum it
has from the repodata.

3. Yum then asks rpm to check the gpg signature of the new rpm.

4. Yum then looks at the SHA1HEADER for the rpm (which, again, is over
the compressed contents).

...now it's possible that #3 will change within the next year or so, but
it is much more likely to end up simpler than more complicated (Eg.
detached signature of the entire file).
 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

-- 
James Antill - james(a)fedoraproject.org
http://yum.baseurl.org/wiki/whatsnew/3.2.29
http://yum.baseurl.org/wiki/YumBenchmarks
http://yum.baseurl.org/wiki/YumHistory