Eliminate the gpg-pubkey pseudo-packages in rpmdb

[pmatilai]

When rpm started doing its own PGP verification in >= 4.0, it introduced gpg-pubkey pseudo-packages in the rpmdb as the rpm keyring. These pseudo-packages have been problematic throughout their existence and don't really belong to the rpmdb, at least painted as something resembling packages that they are not, and causing all manner of weird issues that shouldn't exist in the first place.

Now that rpmkeys supports --delete and --list in addition to --import, we actually have a user-level abstraction that allows us to get rid of those gpg-pubkey thingies, and while this isn't related to the package format, 6.0 seems like an appropriate place to do this.

Details to be sorted out, but for one we already can populate the keyring from the filesystem as an alternative to the gpg-pubkeys in rpmdb.

[pmatilai]

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?

[nwalfield]

I'd encourage you to use the shared OpenPGP certificate directory specification (this document hasn't yet been ratified by the IETF, but it is part of the current charter). At least Sequoia and PGPainless support reading this format. (It's the default format for sq.) Using a common format means that non-rpm tools that understand the format (e.g., sq) can be used to inspect and manage the certificate store.

[pmatilai]

Oh... that looks useful, thanks for the pointer! I saw ~/.local/share/pgp.cert.d use in sq and figured this might be intended for cross-tool sharing, but didn't get furher.

[nwalfield]

Yup! Of course, rpm should have its own dedicated certificate store. But using a common format means it is possible to use it with, e.g., sq using sq --cert-store PATH ....

[pmatilai]

Of course. The fs-backend puts it simply into "pubkeys" subdirectory of the rpmdb, typically /var/lib/rpm/pubkeys/

[pmatilai]

Skimming through the spec, interestingly to compute the path:

• format it using lowercase hex digits,

Yet the user is shown uppercase in Sequoia. GPG too, but it doesn't support this spec anyhow.

[pmatilai]

This baby has a long list of pre-requisites, at least: #3332, #3337, #3338, #3339, #3340, #3341, #3342

The final steps are actually dropping the gpg-pubkey creation code (#3346), associated hacks (#3344) and finally throwing them out of the rpmdb on the next rebuild (#3345)

Edit by @ffesti: #3347 to make the transition to the new backend possible / easy