[Rpm-maint] [rpm-software-management/rpm] RFE: add support for multiple OpenPGP signatures per package (Issue #3385)

[Jan Zerebecki]

I would expect migration to happen this way:
* a dnf repo has only rpms with only one old signature
* dnf and rpm and distribution-repo-keys package or dns repo metadata for offering new keys are updated to support the new signature format and include the new key
* a release cycle happens so people can still update to this old repo (rolling distries wait time and make a snapshot)
* the next release of the repo is rebuilt to have all rpms only have new signature type with the new key; dnf knows old and new key, but the old repo only uses the old one and the new repo only used the new key; so the switch of a repo to a new key can happen atomically as long as dnf knows both keys
* after some time or a release cycle an update to distribution-repo-keys or dnf repo metadata with remove-key instructions removes the old key

Supporting two keys at the same time would be to hedge against one being compromised and migration would work the same as above.

I currently don't see how a more complicated migration would give you any advantages except more chance for errors.

If you really want to make it more complicated you could make a migration with phases of unsupported signature formats and/or optional keys by recording in the dnf repo meta data the list of keys of signatures to expect and marking some of these keys optional and/or skip-if-unsupported and passing that list to rpm. So you can have both flexibility and strict by default.

Does any of that work for your use cases?

If you have a use case that needs a more complicated migration, can you explain what leads to that need or what the advantages are?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3385#issuecomment-2460478976
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/issues/3385/2460478976 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20241106/84693920/attachment-0001.html>