Implement a new openpgp.cert.d based keystore

[pmatilai]

We already have the "fs" keystore as an alternative to gpg-pubkey's in rpmdb, but it's primitive at best. This isn't our core business anyhow, so we'd rather outsource that to something else. A hot tip from @nwalfield in #3313 reveals there's a standard-in-progress that suits our needs: https://datatracker.ietf.org/doc/draft-nwjw-openpgp-cert-d/ - no point looking further.

Sequoia-sq and some other tools/libraries already supports this so we don't need to implement the standard by ourselves (with the possible exception of reading keys from it), we can just call 'sq' to do the actual job. For those worried about dependencies: sequoia-sq is a self-contained thing, it adds no other dependencies that rpm wouldn't already drag in (assuming sane build configuration). It does have build-dependencies of course, but AIUI those would be mostly covered by rpm-sequoia already.

FWIW, a gnupg based keystore would of course be possible, but the implementation is private to gnupg and gnupg itself depends on non-FIPS compliant crypto libraries and does not offer choice on that matter.

[nwalfield]

we can just call 'sq' to do the actual job

I'm not so excited about programs shelling out to sq. Although we plan to have a stable API in a few months, we still don't have machine-readable output. (We plan to implement that in 2025.) I'd rather we specify an API, and then I implement it in rpm-sequoia (or some another library?).

For those worried about dependencies: sequoia-sq is a self-contained thing, it adds no other dependencies that rpm wouldn't already drag in (assuming sane build configuration). It does have build-dependencies of course, but AIUI those would be mostly covered by rpm-sequoia already.

This is half true. sq pulls in a few more dependencies than rpm-sequoia. I've attached some slides that hopefully make this clearer.

What I'm proposing here is only adding a dependency on sequoia-cert-store or the lower-level pgp-cert-d library, and not the key store, or the network services, etc.

[Conan-Kudo]

Honestly, we need our own directories anyway, because we need keys stored in /usr preloaded by vendors and keys stored in /etc that the user adds.

[pmatilai]

I'm not so excited about programs shelling out to sq. Although we plan to have a stable API in a few months, we still don't have machine-readable output. (We plan to implement that in 2025.) I'd rather we specify an API, and then I implement it in rpm-sequoia (or some another library?).

API in rpm-sequoia would be by far preferred by me too, and something I thought would eventually happen anyhow, this was more based on "what tools do we have right now". The shell-out part I envisioned would be basically for import and delete, where the only thing we care is exit code from the call, not looking at any of the output. Just reading the bits off disk shouldn't be too complicated for rpm to implement by itself. The overall picture wasn't probably too clear in the initial description, sorry about that.

This is half true. sq pulls in a few more dependencies than rpm-sequoia. I've attached some slides that hopefully make this clearer.

Nod. I'm thinking more in the terms of distros there: eg Fedora and RHEL already have sequoia-sq, so even the build-dependencies are something that already are there. And in any case, it's a handful of dependencies, not 120 new.

What I'm proposing here is only adding a dependency on sequoia-cert-store or the lower-level pgp-cert-d library, and not the key store, or the network services, etc.

Yup, for an API directly in rpm-sequoia, that sounds good.

[Conan-Kudo]

I'm not so excited about programs shelling out to sq. Although we plan to have a stable API in a few months, we still don't have machine-readable output. (We plan to implement that in 2025.) I'd rather we specify an API, and then I implement it in rpm-sequoia (or some another library?).

API in rpm-sequoia would be by far preferred by me too, and something I thought would eventually happen anyhow, this was more based on "what tools do we have right now". The shell-out part I envisioned would be basically for import and delete, where the only thing we care is exit code from the call, not looking at any of the output. Just reading the bits off disk shouldn't be too complicated for rpm to implement by itself. The overall picture wasn't probably too clear in the initial description, sorry about that.

I would rather avoid this, because we will wind up in a situation where things parse the output as API. This happened in DNF with rpmkeys and it happens all the time in Zypper too.

[pmatilai]

Well, I specifically said "not looking at any of the output" in there 😅

[Conan-Kudo]

Unfortunately, while we can do reasonable things, I can't expect our consumers to. 😓

[pmatilai]

I don't know what you mean by that. We would not be forwarding any output from those programs either, except stderr I guess but that's no different to getting error messages from a library beneath you.

[nwalfield]

Honestly, we need our own directories anyway, because we need keys stored in /usr preloaded by vendors and keys stored in /etc that the user adds.

@Conan-Kudo, what do you mean by "we need our own directories"? Are you agreeing that we should use the Shared OpenPGP Certificate Directory for these directories, or are you saying that rpm should use its own format? If the latter, how do you imagine this format would look, and how would it be managed?

[Conan-Kudo]

I don't care what the format looks like, but we should not use the same shared PGP certs directory used by plain Sequoia, GnuPG, etc.

Essentially, we need to maintain the equivalent of our own keyring with our own import semantics.

[nwalfield]

I don't care what the format looks like, but we should not use the same shared PGP certs directory used by plain Sequoia, GnuPG, etc.

Thanks for clarifying. I was quite confused by your "anyway." I agree that rpm should use its own certificate store.

Essentially, we need to maintain the equivalent of our own keyring with our own import semantics.

What semantics are you thinking of here? Why should rpm's import semantics differ from, say, vanilla sq.

[pmatilai]

I think @Conan-Kudo just means that we shouldn't be using any users certs directory, but something specific rpm.
Ie what we do now, and I don't see it changing, I don't see anything here even suggesting it would change.

[Conan-Kudo]

Yes, more or less. The only other thing I'd like us to do is add the ability to have GPG keys shipped in RPM packages (like fedora-gpg-keys does) go into a location in /usr rather than /etc (e.g. /usr/lib/sysimage/rpmpgpkeys.d or similar).

[nwalfield]

Thanks for the clarifications.

[pmatilai]

Currently importing a key into rpm(db) implies trusting that key. That's not something we'd want to do for keys dropped into a directory by random packages.

Differentiating between known keys and trusted keys, basically for the purposes of determining whether a package can be installed or not, is something we've needed to do for a long time, but that's a topic for a ticket of its own.

Edit: filed #3358 for that purpose, it's good to have an item open for it. I'm quite positive we've had such a ticket on some tracker but we've tracker-hopped enough that a lot of history has gotten lost.

[pmatilai]

We should think about the name of this keystore a bit: the keystore in #3437 is intentionally a simple one that just implements the fs layout, with no support for the root trust stuff. Going forward we'd like a proper implementation from Sequoia that does, and so we should preserve the primary name of opengpgp.cert.d for that "full version". And name the built-in simplified version in somehow self-documenting fashion. Something in the spirit of "openpgp_notrust" or so (not to say I like that name). Thoughts?

[Conan-Kudo]

Actually, I'd flip it on its head: trust should be per-system instance and can be in /etc/pki/rpm-pgp/trusted-keys.d and a regular /etc/pki/rpm-pgp/keys.d and /usr/share/pki/rpm-pgp-keys.d (or /usr/lib/sysimage/rpm-pgp-keys.d) for keys that need TOFU (as the current workflow does now with packaged keys) should be used as the point for new keys.

I feel like that describes enough of how this works.

[pmatilai]

Trust based on just somebody dropping files in a directory isn't sufficient, really. You can trust a packager enough to install content on your system, but not enough to trust anybody they choose to trust. In social media terms, you have friends you trust, but you don't trust their friends.

[Conan-Kudo]

So then, all keys are TOFU? Then what? Where are trusted keys?

[pmatilai]

See https://www.ietf.org/archive/id/draft-nwjw-openpgp-cert-d-00.html#name-rooting-trust - that's the standard draft we're talking about implementing in this ticket.

[Conan-Kudo]

SHOULD NOT have any subkeys.

Does this mean subkeys aren't supportable? We have distributions using subkeys (e.g. AlmaLinux).

[ffesti]

This is for the Trust Root certificate only. The keys in the directory ofc can have sub keys.

[Conan-Kudo]

Okay, and we don't have those for RPM PGP, so I am confused how we're going to have trust established in the first place. Nobody wants to be a PGP CA, and that's what this spec calls for.