<p>(answering my own question)</p>
<p>Short answer: digesting compressed payload instead of compressing the digested payload is expedient.</p>
<p>Long answer: RPM goes to some lengths to preserve streaming-without-peeking-at-magic for *.rpm packages.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>(aside)<br>
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.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/rpm-software-management/rpm/issues/184#issuecomment-291007573">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ANb80z8a7IiG6DT0G9hbNmb670W4Rzmjks5rr_JVgaJpZM4MsMhO">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ANb803MmfwyBDS9JZRYlzArukg14LtOwks5rr_JVgaJpZM4MsMhO.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/rpm-software-management/rpm/issues/184#issuecomment-291007573"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/rpm-software-management/rpm","title":"rpm-software-management/rpm","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/rpm-software-management/rpm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@n3npq in #184: (answering my own question)\r\n\r\nShort answer: digesting compressed payload instead of compressing the digested payload is expedient.\r\n\r\nLong answer: RPM goes to some lengths to preserve streaming-without-peeking-at-magic for *.rpm packages.\r\n\r\nThe 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.\r\n\r\nThere 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.\r\n\r\nThe 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.\r\n\r\n(aside)\r\nI 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."}],"action":{"name":"View Issue","url":"https://github.com/rpm-software-management/rpm/issues/184#issuecomment-291007573"}}}</script>