Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make rpmkeys --list show Key fingerprint and sub key IDs #3332

Open
ffesti opened this issue Sep 26, 2024 · 2 comments
Open

Make rpmkeys --list show Key fingerprint and sub key IDs #3332

ffesti opened this issue Sep 26, 2024 · 2 comments
Labels
crypto Signatures, keys, hashes and their verification RFE
Milestone

Comments

@ffesti
Copy link
Contributor

ffesti commented Sep 26, 2024

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:

  • rpmkeys --list shows Key fingerprint, issuer and creation time
  • rpmkeys --list uses the keyring iterator for accessing keys, rather than gpg-pubkey pseudo-packages
  • rpmkeys --list -v gives Key IDs for subkeys and all other availablke information about the key
@ffesti ffesti added the RFE label Sep 26, 2024
@pmatilai
Copy link
Member

pmatilai commented Sep 26, 2024

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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crypto Signatures, keys, hashes and their verification RFE
Projects
Status: Backlog
Development

No branches or pull requests

2 participants