[Rpm-maint] [rpm-software-management/rpm] Q: RPMTAG_PAYLOADDIGEST: compute before or after compression? (#184)

Jeff Johnson notifications at github.com
Sun Apr 2 19:09:10 UTC 2017


(answering my own question)

Short answer: digesting compressed payload instead of compressing the digested payload is expedient.

Long answer: RPM goes to some lengths to preserve streaming-without-peeking-at-magic for *.rpm packages.

The usual RPM approach is/was to add/save tags in the metadata header to determine choices like format/signature/digest/compression algorithm (and parameters) into the metadata header. So doing a digest on the compressed payload permits digest/compression to be more easily setup before examining magic in the plaintext blob for RPM.

There are  consequences for other applications that wish to manipulate the rpm file format that do not use the upper layers of the RPM api where the choices can be buried. The consequences  are added application complexity, with a continual application churn to handle Newer! Better! Bestest! features like RPMTAG_PAYLOAD verification, and a need to pretend "legacy compatibility" with disablers while waiting for application implementations.

The ripple effect of a change like RPMTAG_PAYLOADDIGEST (or rpmarchive/tar payloads, or ECC signatures) throughout the rpm tool chain takes years, and one (at least me ;-) wonders whether the work is even useful if it takes years to achieve widely deployed implementations.

(aside)
I think a better approach going forward in RPM will be to use certificates/signatures (which buries the choices of signature/digest algorithm in "standard" ways), and to add API's to select one-of-N choices (like archive/compression format) lazily using magic in the objects, rather than adding explicit metadata tags.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/184#issuecomment-291007573
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20170402/56919fb5/attachment.html>


More information about the Rpm-maint mailing list