* 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. 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. Thanks, Florian _______________________________________________ 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
