On 11/23/18 3:16 PM, Florian Weimer wrote:
* Jonathan Dieter:
On Tue, 2018-11-20 at 12:45 +0000, Michael Schroeder wrote:
On Mon, Nov 19, 2018 at 08:30:14PM +0000, Jonathan Dieter wrote:
Just to be clear on this, unlike deltarpm, zchunked rpms shouldn't
require extra CPU usage on the client side as they don't go through the
decompress-recompress cycle that deltarpms do. Re-assembling a zchunk
file requires no compression or decompression.
Btw, we can easily do that for deltarpms as well. We only recompress
because we want a rpm that is bit-identical to the remote one.
Having a '-u' option that makes applydeltarpm write a rpm with an
uncompressed payload and no payload signatures is just a couple of
lines of code.
But the problem is that you would lose the signatures. To make this
work, we would need to create signatures of both the compressed and
uncompressed rpm (which wouldn't be a bad idea). Is there some way we
could (ab)use the current rpm format to make this work, or would it be
a backwards-incompatible change?
The problem is that the RPM header hash covers quite a few fields that
change if the payload compression changes. I'm not even sure if the
compressed payload itself is hashed.
The old MD5 hash covers the header + compressed payload, and since >=
4.14 there's a separate SHA256 hash on the compressed payload alone.
IIRC, primary.xml only contains compressed payload hashes, not the
header hash, so if we cannot reproduce the compressed payload, then the
hashed chain from the centralized mirror manager to the individual RPM
packges is broken. This hash chain is very much needed for security
because RPM signing itself is quite broken.
primary.xml contains hashes over the *entire* package, which is quite a
different thing - it only tells you the package you received is the same
as in the repo, but it says absolutely nothing about the validity of the
package as such.
rpm >= 4.14.2 enforces validation of the entire payload before starting
installing using the best hash available, and also has a true enforcing
signature mode available. There are various shortcomings in still of
course, but it's nowhere near as bad as it's traditionally been.
- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
