Delete v3 signature support for built packages

[dralley]

RHEL and CentOS 7 are going out of support in a couple of weeks - obviously we won't want to cut a release until after that.

There's a few other simplifications that can be done that aren't part of this series currently, I'll probably do followup PRs for those.

📜 Checklist

• Commits are cleanly separated and have useful messages
• A changelog entry or entries has been added to CHANGELOG.md
• Documentation is thorough
• Test coverage is excellent and passes
• Works when tests are run --all-features enabled

[dralley]

@cat-in-136 Are you OK with dropping EL7 support once it hits EOL in ~6 weeks?

[cat-in-136]

I agree that it is time to retire support for legacy rpm version.

[cmeister2]

I'll review the content later. Does this remove the ability to read and write old packages, or just build them? Generally I'm loath to delete functionality unless it's strictly necessary - there are companies where they have to maintain old distro images for a long time and removing the ability to interface with EL7 packages would mean they needed to fork the crate. If there is an undue maintenance cost then that's certainly worth considering against the feature though.

…

On Tue, 7 May 2024, 14:54 cat_in_136, ***@***.***> wrote: I agree that it is time to retire support for legacy rpm version. — Reply to this email directly, view it on GitHub <#225 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPA36NB4HUXK3FMG5CSIRTZBDMHVAVCNFSM6AAAAABHHM37YOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJYGQ3DMMZWGM> . You are receiving this because your review was requested.Message ID: ***@***.***>

[dralley]

I'll review the content later. Does this remove the ability to read and
write old packages, or just build them?

You should be able to read and write them fine. Verifying signatures and digests for old packages would be a bit weaker because at the time there was no PAYLOADDIGEST in the header (added in 2015-2016 IIRC), so the only thing covering the payload integrity is the V3 signatures.

It does remove the ability to build them unless 9df3d74 is dropped from the series. Theoretically we could, I just figured it'd be cleaner to draw a hard line.

The primary maintenance benefit is that it allows us to generate the signature header from the primary header alone, rather than needing to look at both the primary header and the payload. That simplifies the remote signing use case significantly (where you create a signature remotely from a checksum, rather than having access to the RPM).

[drahnr]

Is there a use-case for verifying old packages still, while not generating any new packages with the legacy algorithms/features?

[dralley]

You mean leaving in the code that verifies V3 signatures while dropping the code that generates them?

It's a reasonable half-step, generating them is the messiest part.

Note that you can still verify the signatures of old packages with this patchset, and it's not completely meaningless (the header is signed, and the header has file digests), but yeah it would be neutered a bit.

[drahnr]

You mean leaving in the code that verifies V3 signatures while dropping the code that generates them?

Precisely. It wouldn't break verifying code, yet would stop producing broken signature schemes. I think a deprecation warning would also be in order.

To sum up, I propose a cadence of three (3) releases.

1. immediate - add deprecation warnings on all legacy crypto types
2. weeks - delete the generation part of broken crypto schemes, keep the verficiation logic with deprecation notices for obsolete crypto types
3. months - delete the verification logic, give people to migrate all their container workloads

Happy to hear your opinion

[dralley]

Well in terms of "immediate", we don't have anything else ready to release at the moment... Dunno that's worth doing a release solely to announce deprecations

It would be functionally equivalent to sticking to 0.14, and of course people can read the release notes before they upgrade

[dralley]

@drahnr I've pared the PR down to merely removing the legacy signatures and digests from built, or resigned packages, and continuing to "verify" them.

Is that OK w/ you?