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/[email protected]>
_______________________________________________ Rpm-maint mailing list [email protected] http://lists.rpm.org/mailman/listinfo/rpm-maint
