[Rpm-maint] [rpm-software-management/rpm] Move installed gpg keys to the currently configured storage (Issue #3347)
Panu Matilainen
notifications at github.com
Wed Nov 13 06:43:28 UTC 2024
That AC proposal neglets to mention just how exactly this behavior is triggered, which is rather critical piece of information. Are new APIs and cli switches being added - which ones?
Stuff like "move new instance to proper place" is an uninteresting implementation detail, what we're really interested is the semantics that are also testable. For example, "add all keys" sounds like all keys get moved no matter what, but that's not what should happen, we should weed out any no longer legit keys in the process - in other words, those that fail to import. So it's more like "attempt to reimport all previously imported keys" than just "add all". And as a part of that reimport, any short keyids get converted to fingerprints - which is what we want. And on the semantic level I dont' think we should or need to differentiate between rpmdb and other backends, from rpmkeys perspective they should all behave the same.
So I think the requirements are more like
- a way to invoke keystore rebuild from the command line and API (and describe how it'll look like)
- supports moving keys between all keystores, including itself (eg rpmdb -> rpmdb)
- old invalid (expired, weak crypto, whatnot) keys are discarded in the process with a warning message
- old short keyid based keys are converted to fingerprint based ones
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3347#issuecomment-2472590239
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/3347/2472590239 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20241112/e7ca58ac/attachment-0001.html>
More information about the Rpm-maint
mailing list