RPM verification procedure not compatible with `rpm --delsign` behavior

[eloquence]

In freedomofpress/securedrop-yum-test#40 (comment), @eaon and @gonzalo-bulnes discovered that the version of rpm included in Debian 11, Fedora 36 and Fedora 37 exhibits --delsign behavior that conflicts with our current build artifact verification procedure: https://github.com/freedomofpress/securedrop-workstation-dev-rpm-packages-lfs/blob/main/.github/pull_request_template.md

Specifically, --delsign produces an RPM that differs from the original unsigned RPM, and the differences appear to vary depending on which signature was originally applied. This conflicts with the following step:

Unsigned RPM after running rpm --delsign on the signed RPM results in the checksum found in the build logs

This issue is to track any procedural changes we may want to make to account for this difference, as well as upstream coordination & related issues.

[eloquence]

This was discussed briefly in today's developer hangout. One potential workaround we discussed is for the person producing the RPM to attach the checksum of their rpm --delsign output to the build log, which could approximate the level of confidence in build integrity that we currently have based on this process. At least per Michael's and Gonzalo's testing on Fedora and Debian so far, the --delsign behavior appears to be deterministic across those platforms.

[cfm]

@eaon and I realized yesterday that we'd dropped the ball on this and caught up about it just now.

I'm going to create reproducible test cases for the rpm --{add,del}sign behavior we've observed on Debian buster (inverse operations as expected) and Fedora 37 (not inverse), from which I'll then draft an upstream ticket for @eaon to review.

[cfm]

Test cases: https://gist.github.com/cfm/3559664c4f496fbb9beeade5f9411e5e

Draft to follow next week!

[cfm]

Filed upstream in rpm-software-management/rpm#2382.

[eaon]

I confirmed today that rpm-software-management/rpm#2396 fixes the regression, --delsign now behaves as we expect it in rpm's master branch. I asked if they'd consider it for inclusion in the upcoming 4.18.1 release, but either way, we have a path to make our verification procedures work again. 🎉