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

Move installed gpg keys to the currently configured storage #3347

Open
ffesti opened this issue Sep 30, 2024 · 8 comments
Open

Move installed gpg keys to the currently configured storage #3347

ffesti opened this issue Sep 30, 2024 · 8 comments
Assignees
Labels
crypto Signatures, keys, hashes and their verification RFE

Comments

@ffesti
Copy link
Contributor

ffesti commented Sep 30, 2024

Pratically we only really support gpg-pubkey packages as storage for pgp keys. If we support more backends in earnest we need a way to move keys from one storage backend to another to prevent users needing to re-import the keys.

This should probably be done completely automatically to make transition from one default to another easy and seamless. Alternatively would could offer a way to export the keys to a script(let) could export them, switch the default and then re- import the keys. While adding support to export keys may seem useful (although may not really needed if stored on disk anyway) doing the transition within rpm itself if probably less hassle and saver.

@ffesti ffesti added RFE crypto Signatures, keys, hashes and their verification labels Sep 30, 2024
@pmatilai
Copy link
Member

Right, we could have a keystore "rebuild" mode akin to how rpmdb backend can be changed by rebuilding it.

I was pretty much thinking of just letting users reimport the keys though - a distro user will only see 4.x -> 6.x and the associated keystore change when upgrading their distro, and at least in Fedora each version has their own key so lots of unused cruft accumulates over time. My home server has keys from eight different Fedora versions imported.

@pmatilai
Copy link
Member

Such a rebuild mode serves as a cleanup operation too - just like with the rpmdb. And just like --rebuilddb I think the keystore rebuild should

  • drop any keys it cannot load (which in this context is rather obvious), with a warning
  • be able to convert from one keystore to another
  • ...including the original format for a simple "rebuild" behavior

@ffesti ffesti self-assigned this Nov 8, 2024
@ffesti
Copy link
Contributor Author

ffesti commented Nov 8, 2024

Hmm, the question is on how to do that in a save way. E.g. for the database backend there is no clean slate to start from. We ofc could remove all gpgpubkey packages and then add the loaded keys back. But that leaves things very vulnerable inbetween.

The file based backends can at least save stuff elsewhere by manipulating %_keyringpath.

Hmm, with the key store in the rpmdb directory does that survive an rpmdb --rebuild?

@pmatilai
Copy link
Member

pmatilai commented Nov 8, 2024

Yes, gpg-pubkeys do survive rpmdb --rebuild currently. But they don't get reimported so they stay in the short id mode.

@pmatilai
Copy link
Member

pmatilai commented Nov 8, 2024

For the db, I guess you could basically create an empty rpmdb in an alternative path where you put them temporarily.

@ffesti
Copy link
Contributor Author

ffesti commented Nov 8, 2024

Should have worded this better: Do the fs backend keys survive a rpmdb --rebuild?

@pmatilai
Copy link
Member

pmatilai commented Nov 8, 2024

Oh, that. No idea.

@ffesti
Copy link
Contributor Author

ffesti commented Nov 11, 2024

AC:

  • Read keys from all supported back ends
  • For file based back ends
    • create a new instance in temporary directory
    • add all keys
    • move new instance to proper place
    • delete all old key directories
    • delete all pgp-pubkey packages
  • For rpmdb backend,
    • Add all keys to the rpmdb replacing existing ones
    • Remove all gpg-pubkey packages not just added
    • delete all old key directories

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: In Progress
Development

No branches or pull requests

2 participants