search

rpm-software-management / rpm

The RPM package manager
http://rpm.org
Other
509 stars 368 forks source link

Make rpmkeys --list show Key fingerprint #3332

Closed ffesti closed 1 month ago

ffesti commented 1 month ago

Currently rpmkeys --list only give the version, release and summary of the gpg-pubkey packages aka short key ID, creation time and issuer. There is now way to get the fingerprint or even long key ID from RPM for the installed GPG keys.

Make the current format more useful and also offer a long format giving the full information that's available.

Currently --list uses gpg-pubkey packages to obtain this information. This is problematic as the meta data is just copied at creation time of the pseudo package and does not directly come from the key itself. In light of #3313 this functionality should be based on the keyring so it is independent of the gpg-pubkey packages and also has access to the full keys with all their detail.

AC:

pmatilai commented 1 month ago

I'd make the second point into "rpmkeys --list uses the keyring API for iterating the keys" - we don't want to replace gpg-pubkey db iteration with, say, manual fs walk to do the same, this should be in the keyring, but otherwise looks fine. Of course there's the catch that the keyring lacks any means to access the keys, so we'll need to address that first, but it's about time anyhow.

pmatilai commented 1 month ago

3337 is a pre-requisite for this, AC acked.

pmatilai commented 1 month ago

Taking back AC ack because this is too vague, and would just end up in another endless PR. We'll proceed once we agree on the literal expected output based on mockups, that's 100 times faster and easier for everybody.

Just one of these open points - this talks about subkey keyids, but shouldn't it be subkey fingerprint instead (tagging @nwalfield for input + general wisdom on these matters) ? That's what eg sq seems to do - using our test key as an example:

[pmatilai🎩︎localhost ~]$ sq --cert-store /tmp/keytst key import repos/rpm/tests/data/keys/alice.secret 
Imported B6542F92F30650C36B6F41BCB3A771BFEB04E625 Alice <alice@example.org>
(UNAUTHENTICATED) from repos/rpm/tests/data/keys/alice.secret: new
[pmatilai🎩︎localhost ~]$ sq --cert-store /tmp/keytst key list
 - Backend softkeys has the following keys:
   - B6542F92F30650C36B6F41BCB3A771BFEB04E625
     - 43253A62850DFADCACD423F11F71177215217EE0 Alice <alice@example.org>
       (UNAUTHENTICATED) (available, unlocked, for signing and decryption)
     - B6542F92F30650C36B6F41BCB3A771BFEB04E625 Alice <alice@example.org>
       (UNAUTHENTICATED) (available, unlocked, for signing and decryption)
nwalfield commented 1 month ago

this talks about subkey keyids, but shouldn't it be subkey fingerprint instead

I agree that we should prefer fingerprints to key IDs whenever possible. Unfortunately, we may not know the fingerprint if (1) the certificate is not available, and (2) the signature only references the signing key by key ID. Modern signatures include the fingerprint, but older signatures don't (and v3 signatures can't).

$ sq --cert-store ...

Consider using SEQUOIA_HOME (or --home), like this:

$ export SEQUOIA_HOME=$(mktemp -d)
$ sq key import repos/rpm/tests/data/keys/alice.secret 
...

--cert-store only overrides the location of the certificate store, not the key store, not the configuration files, etc.

ffesti commented 1 month ago

OK, this is a private key (aka key in sq lingo) but it looks like there is no way to really list public keys.

The current format of rpmkeys --list is

"%{version}-%{release}: %{summary}\n" with %{version} being the short keyid, %{release} the date of the key in hex and %{summary} the issuer + " public key" resulting in e.g. 1964c5fc-58e63918: rpm.org RSA testkey <rsa@rpm.org> public key

I would suggest using "%fingerprint %issuer public key" e.g. 771b18d3d7baa28734333c424344591e1964c5fc rpm.org RSA testkey <rsa@rpm.org> public key

Technically the "public key is redundant as we don't really deal with private keys but I think it adds a bit of clarity on what you are looking at.

I note that the sq output above (whihc is about private keys) seems to list the primary and the sub key side by side without even telling which one is which. So far we have never really listed subkeys of installed (public) keys. But the way sq and rpm deal with public keys are quite different.

ffesti commented 1 month ago

I also wonder if we want a -v variant that looks a bit more like rpm -qi gpg-pubkey e.g. prints all info we have about he keys. Even if the current packages are pretty silly there is s oem information we could print. May be even limit the sub keys to only this output.

nwalfield commented 1 month ago

Technically the "public key is redundant as we don't really deal with private keys but I think it adds a bit of clarity on what you are looking at.

I think adding a bit of context like that is a good idea. (I'd personally prefer OpenPGP certificate, but if you prefer "public key," I don't want to argue about it :)).

I note that the sq output above (whihc is about private keys) seems to list the primary and the sub key side by side without even telling which one is which.

sq key is for managing secret key material. sq pki list doesn't show subkeys, and I'd recommend not exposing this implementation detail when possible.

pmatilai commented 1 month ago

No strong opinion on the trailing "public key", but it probably starts looking redundant once you have many in a row, and will make parsing it slightly more annoying. On a related note, we should be more explicit about what 'rpmkeys --list' (and --delete) does: they are always public keys. (and, I guess here we start getting to the reasons why sq calls them certificates :sweat_smile: )

-v mode seems useful, and I'd indeed limit subkey output there. Basically rpmkeys --list outputs something you can pass to --delete, and so the subkeys don't belong.

pmatilai commented 1 month ago

Oh the "public key" part is there already in rpmkeys output, that's new enough that I clearly haven't seen its output too much by now:

[pmatilai🎩︎localhost keys]$ rpmkeys --dbpath /tmp/kr --list
757bf69e-661d22a8: rpm.org ed25519 testkey <ed25519@rpm.org> public key
5f65bbe8-661d2507: rpm.org NIST P-256 testkey <nistp256@rpm.org> public key
1964c5fc-58e63918: rpm.org RSA testkey <rsa@rpm.org> public key

In any case, yeah the <fingerprint> <issuer> format seems quite obvious, whether it has "public key" appended or not.

ffesti commented 1 month ago

OK, so here is the actual question: How do we match those keys? This used to be "simple" as we were using the normal rpm packages API. Now we need soemething new. I don't really think I want to offer the wacky gpg-pubkey shortid-time NVR. We could just match the fingerprint and the issuer. Querstion is whether to just use search so allow shorted version or require valid globs e.g. 771b18d3d7baa287* is needed or 771b18d3d7baa287 is just fine.

ffesti commented 1 month ago

Yeah, rpmkeys --list is super new. It was just implemented earlier this year and only now is released with 4.20. So it doesn't carry too much weight for the overall decision.

nwalfield commented 1 month ago

How do we match those keys?

I recommend just matching on the certificate's fingerprint (and, if you insist, perhaps on the long key ID). This is a reason to not use a spaced fingerprint representation: a fingerprint without spaces is much easier to copy and paste.

Querstion is whether to just use search so allow shorted version or require valid globs e.g. 771b18d3d7baa287*

Please don't do this!!!

pmatilai commented 1 month ago

Yep, fingerprint is should be the main handle everywhere AFAICS, but we'll need to accept the full keyid too, at least for a while. gpg-pubkeys have the full keyid in provides so we can look those up by that and ignore the shortid version.

ffesti commented 1 month ago

Here's my branch so far: https://github.com/rpm-software-management/rpm/compare/master...ffesti:rpm:3350 It does #3350 first and uses this ticket as a test case to make sure things still work. It is still missing the long output format but is build with that being added in mind as it has a callback of the matching keys. May be that functionality should move to the rpmcli but I wanted to get it working first.

ffesti commented 1 month ago

OK, I guess I finally got why @nwalfield is against listing the subkeys. My mind was "What if you need to look for one?". But if you have the public key on the system it will be found anyway. If it is not on the system, you can list it - obviously. So you would only want it listed when you can't.

Guess the answer for the "What if you need to look for one?" question is "You look at the keyserver." Or in our case: "You get the right key from the repo anyway."

pmatilai commented 1 month ago

Right. So since that appears to be the right thing to do, lets just forget about the subkeys then. Simplifies things that little bit more.

The only form subkeys are visible currently now are gpg(keyid) provides in gpg-pubkey packages, and I think very very very few people on this planet know that, much less use them.

ffesti commented 1 month ago

That being said here the first version of the new output:

previously:

> rpmkeys --list
1964c5fc-58e63918: rpm.org RSA testkey <rsa@rpm.org> public key

now

771b18d3d7baa28734333c424344591e1964c5fc rpm.org RSA testkey <rsa@rpm.org> public key

Previously

> rpm -qa gpg-pubkey
Name        : gpg-pubkey
Version     : 94843c65
Release     : 5dadbc64
Architecture: (none)
Install Date: Thu 01 Feb 2024 02:20:47 PM CET
Group       : Public Keys
Size        : 0
License     : pubkey
Signature   : (none)
Source RPM  : (none)
Build Date  : Mon 21 Oct 2019 04:10:44 PM CEST
Build Host  : localhost
Packager    : RPM Fusion nonfree repository for Fedora (2020) <rpmfusion-buildsys@lists.rpmfusion.org>
Summary     : RPM Fusion nonfree repository for Fedora (2020) <rpmfusion-buildsys@lists.rpmfusion.org> public key
Description :
-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBF2tvGQBEAC5Q2ePLZZafOkFhYHpGZdRRBCcCd+aiLATofFV8+FjPuPLL/3R
7fx9RRukL+XKs6K9houj/oYVHmBY7II1mgeRzZHo6KygnM9ph3RKqQDse4TR9+VX
rctsBRikNc7GViSoiPHLRAJeTrlwYRjPHYfF64nFtcPYfPIlGZkEG8mrHbTjkh36
NAlqb3XC0cOSsKQV5f4Wn8fAUepYUkTxA74sVHLSDcBRj3fGfizkiHohy4OjNPij
1VVvfUQXIGYwEDnrd3JF5c2o6B4MfH7h1aN+xG7GJTRswgjQtYUayUOySD5mdZ9u
lUNfPrIAvwyTnc1IvoJUGlf8wSqz8NmjTHykUU+f6Dldb4JKNavnYaVlmDH4HfK+
FVdAD/1pG/6HL94clf/g8LR3sQ0KU/UZJKbDA81n1X04OREfqdjr81U84iyKyb8S
+5nwYuJvxoe+wHg+iHAK0CXYel6V1GR51yka8+sETXyEjGvXksPMQDVPGIDzDfPr
QVijtL3/1Pgkuz1ZvvXmuxD94uV2rBvjKl1NFSWNXId2J+vI5omllGHR3qskOHFa
My9IQkbV4sMoycW/fP5xbwGhVi5q5Gjo7h6J7TIzyMf4gl6PJTp0AFhOZAMA/dXY
nLDnw+qz+iq0B3I14JSLvgCH/uSUEMl5970+COK7wmPTU7I3Hq6PMbzvqQARAQAB
tFhSUE0gRnVzaW9uIG5vbmZyZWUgcmVwb3NpdG9yeSBmb3IgRmVkb3JhICgyMDIw
KSA8cnBtZnVzaW9uLWJ1aWxkc3lzQGxpc3RzLnJwbWZ1c2lvbi5vcmc+iQJFBBMB
CAAvFiEEeb24j5u/c5EP1Albair5YZSEPGUFAl2tvGQCGwMECwkIBwMVCAoCHgEC
F4AACgkQair5YZSEPGW0Ig/+NJf5+KzbRNuFvvGURQI7SYmYtFXkrW4n6rLPWeIV
UHvd/ko74aMVds7hTWeC0cLpjRMSPuwp9xjqb6NvQaqcUK4IwHzlXocait2HzSl+
h2jI3/wSQXqNkvNrgD3rkYZZZ/x7EBBTSTRUpFPq3yHA/BBXbZNEvFsXOmFAy5y+
E5iYnfyjYKHWd0ZwIliWWtK+V5TU54WqHqKF5J2iIDgANkLXiyqx6+LJ6Ng0YfCQ
fO7IMfwtgUt34AfrHWnq0S9BW0hmtPvcYjTtveQKCeGfdMcpRRJsOrvaDDKo1Wmr
IcvGO2VwiF9i19ppghXOSy7q51wTlEqtj3PWYhmJYcRq8Jr1SqjGx73QhUPtsF67
g3vjNEm8PE7pj7vg52BJlzkx6yU+hH5ZNBRM5ll4ZjiX+X7EzKa9so83uszuwoQA
mScTwyyQDNeflnUwiSgZc7PEv1i0BYIHVK7VjmamhOWZRHaaYFCc//gcmu10TJLn
ZCGF2ZDkAdUT6EoWBsT/QCgYSFggrjH9lgKqC5ON8+F5DO1RQe84irgz9jjE9+62
kgQgWZ6F2RZm5/R28DHdAetji50XbnmXgAk/u9u2Hw2bVVJfJ0WpEVcPvA1L86SE
8i8p1fmzljwRazZAksk5Zh2QfaM0jlMYHWbKpbXQcX19Uerm7D9IkciZvDAmgBYV
S6Y=
=rOqq
-----END PGP PUBLIC KEY BLOCK-----

now

> rpmkeys --list -v
Public key
Issuer        : rpm.org RSA testkey <rsa@rpm.org>
Fingerprint   : 771b18d3d7baa28734333c424344591e1964c5fc
Key ID        : 4344591e1964c5fc
Creation Time : Thu Apr  6 12:48:24 2017
Version       : V4
Key algorithm : RSA
Hash algorithm: SHA256

Has anyone a better term for version? "Packet version?" "Key packet:?"

ffesti commented 1 month ago

Ofc this could by shorten even further if we use a line like

Key type   : V4 RSA/SHA256

Opinions?

nwalfield commented 1 month ago

rpmkeys --list -v Public key Issuer : rpm.org RSA testkey rsa@rpm.org

In OpenPGP, that's usually the "user ID".

Has anyone a better term for version? "Packet version?" "Key packet:?"

Perhaps "OpenPGP key format" or just "key format."

nwalfield commented 1 month ago

Ofc this could by shorten even further if we use a line like

Key type   : V4 RSA/SHA256

Opinions?

I'd rather not mix the version and the algorithm.

nwalfield commented 1 month ago

Key algorithm : RSA Hash algorithm: SHA256

A certificate usually includes a bunch of keys and a bunch of signatures and they may use different algorithms. So this is a bit misleading.

ffesti commented 1 month ago

Would it make sense to list all algorithms over all keys? Or just not list it at all?

nwalfield commented 1 month ago

Would it make sense to list all algorithms over all keys? Or just not list it at all?

That is going to get messy fast. I'd say defer to another tool like sq inspect.

pmatilai commented 1 month ago

For the verbose output, I'd keep the non-verbose output as basis and output the details indented, to make it easier to see which details are on which key. So something like

771b18d3d7baa28734333c424344591e1964c5fc rpm.org RSA testkey <rsa@rpm.org> public key
        User ID: rpm.org RSA testkey <rsa@rpm.org>
        Fingerprint: 771b18d3d7baa28734333c424344591e1964c5fc
        Creation Time: Thu Apr  6 12:48:24 2017
        ...

(I don't necessarily mean the above literally, just as an example of the kind of indenting I mean)

pmatilai commented 1 month ago

That is going to get messy fast. I'd say defer to another tool like sq inspect.

I agree, lets leave the details to specialist tools. But for this we'll need to have a convenient way of exporting the key material. So maybe we should add rpmkeys --export to dump the ASCII armor out?

nwalfield commented 1 month ago

Perhaps you could even try running sq inspect and including the output inline.

pmatilai commented 1 month ago

I think we'll want to manage our own output for the switches we support, otherwise it gets a bit weird with version differences and all.

ffesti commented 1 month ago

So here's the output of sg:

> sq inspect ../tests/data/keys/alice.asc 
../tests/data/keys/alice.asc: OpenPGP Certificate.

    Fingerprint: B6542F92F30650C36B6F41BCB3A771BFEB04E625
Public-key algo: RSA
Public-key size: 3072 bits
  Creation time: 2022-04-10 00:00:00 UTC
      Key flags: certification

         Subkey: 43253A62850DFADCACD423F11F71177215217EE0
Public-key algo: RSA
Public-key size: 3072 bits
  Creation time: 2022-04-10 00:00:00 UTC
      Key flags: signing

         UserID: Alice <alice@example.org>

I mean we do have the key parameters already parsed. So this should not be difficult to do. The only things currently missing is the bit length, the flags of the keys and the loop over the sub keys. The question is more, what actually makes sense.

pmatilai commented 1 month ago

Well, we're trying to get out of the OpenPGP business to the extent that we can, so we certainly do not want to add more detail than we already have. Just keep rpmkeys output simple and have an easy way to pipe to specialist tools for deeper diagnostics.

ffesti commented 1 month ago

What about just changing the caption to "Primary key algo". So you still get an idea of the algorithms used without needing all the complexity and without lying to the user.

nwalfield commented 1 month ago

What about just changing the caption to "Primary key algo". So you still get an idea of the algorithms used without needing all the complexity and without lying to the user.

That's better than the status quo, but I'd still prefer not showing anything.

FWIW, this is what sq key list shows:

$ sq key list
 - 8F17777118A33DDA9BA48E62AACB3243630052D9
   - Neal H. Walfield <neal@walfield.org> (authenticated)
   - created 2015-04-07 08:52:57 UTC

   - 2DC50AB55BE2F3B04C2D2CF8A3506AFB820ABD08
     - created 2015-04-07 09:43:48 UTC
     - usable for signing and decryption
     - @gpg-agent/default: not available, locked
   - 50E6D924308DBF223CFB510AC2B819056C652598
     - created 2015-04-07 09:43:20 UTC
     - usable for signing and decryption
     - @gpg-agent/default: not available, locked
   - C03FA6411B03AE12576461187223B56678E02528
     - created 2015-04-07 09:42:46 UTC
     - usable for signing and decryption
     - @gpg-agent/default: not available, locked

(Note this was recently improved and isn't in the version in Fedora.)

pmatilai commented 1 month ago

Actually, let's just skip the verbose mode now. It's something we can add in Feb-March if we have spare cycles, or 6.0.1 or something. But just now we have absolutely zero need for it, and we can't afford to get blocked on merely informative details.

For the non-verbose output we already have an agreed output format, and the rest of the AC is just using the keyring iterator for it.

pmatilai commented 1 month ago

Updated and ack'ed the AC as per above comment.

ffesti commented 1 month ago

Sure. Just for completeness here the state of the discussion so far:

771b18d3d7baa28734333c424344591e1964c5fc rpm.org RSA testkey <rsa@rpm.org> public key
    Key ID        : 4344591e1964c5fc
        Creation Time : Thu Apr  6 12:48:24 2017
nwalfield commented 1 month ago

The key ID is redundant.