[Rpm-maint] [rpm-software-management/rpm] Support uncompressed/reconstructed payloads (#861)

Will Woods notifications at github.com
Tue Sep 24 19:18:58 UTC 2019

#163 / commit 91aa078 added `RPMTAG_PAYLOADDIGEST` and `RPMTAG_PAYLOADDIGESTALGO`, so RPM now verifies the integrity of the payload. But there are tools (e.g. `deltarpm`) that reconstruct RPM payloads from individual parts. Given an RPM header and the individual file contents, the original (uncompressed) payload can be easily reconstructed by adding the appropriate CPIO headers, but there's no way to verify the integrity of the reconstructed payload other than re-compressing it and letting RPM verify PAYLOADDIGEST, which wastes a bunch of CPU & disk i/o and then sometimes fails randomly because of minor, unpredictable differences in compressor output.

To fix this I propose adding a second digest (`RPMTAG_PAYLOADDIGEST_UNCOMPRESSED`?) for the _uncompressed_ payload, and then either:

1. Fall back to uncompressing the payload and checking the uncompressed digest if the original verification fails (unsafe, slow)
2. Add another tag (maybe `SIGTAG_PAYLOAD_UNCOMPRESSED`?) which directs RPM to assume the payload is already uncompressed; external programs could manually set that flag when reconstructing an RPM, or
3. Add a new tag (`RPMTAG_PAYLOAD_MAGIC`?) that gives magic bytes (e.g. the first 4 bytes) for the compressed and uncompressed payload, so RPM can identify uncompressed/reconstructed payloads.

Either way, RPM would also need to override/ignore `RPMTAG_PAYLOADCOMPRESSOR` when the "uncompressed payload" flag is set. But that only happens in 3 places that I can see, so that's doable.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20190924/d084c142/attachment.html>

More information about the Rpm-maint mailing list