Further musings on the topic: rpmts supports populating the keyring from either
the rpmdb or keys-in-directory, but the keyring itself is a transient in-memory
thing, only good for verifying. That was the minimal goal back then, a long
long ago. Going forward the storage part needs to be more sanely hooked in
there.
Support for keys-in-directory is very barebones really, eg there's no support
for listing or removing them. Stuff that the rpmdb gpg-pubkey replacement
obviously needs - gpg-pubkeys only work because the API is skewed, you import
with a special API but erase and iterate using the rpmdb/header stuff.
We may want to enhance the fs-based keyring to manage those, but I'm not sure
keys-in-directory cuts it in the wild. Packages could drop arbitrary files in
the directory and whatnot - that's not necessarily a problem, the fact that
imported implies trusted is, if importing means just dropping a file in a
directory.
We could always whip up something with sqlite or so, but Sequoia of course has
its own keyring. Maybe we could offload this there - at least as one option?
@nwalfield, thoughts on that?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3313#issuecomment-2376502856
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/3313/[email protected]>
_______________________________________________
Rpm-maint mailing list
[email protected]
http://lists.rpm.org/mailman/listinfo/rpm-maint
