Provide basic gpg public key management

[mdellweg]

Is your feature request related to a problem? Please describe. Pulp needs to handle public keys in some places. They are used for verifying uploaded or synced artifacts, and they may be exposed as part of a publication.

Describe the solution you'd like

• Public GPG keys can be added as a pulp content (either with an artifact, or with the ascii-armored data in a text field - up for discussion). In case data will be stored in a text field we'd need to write a separate handler to serve the pub keys.
• There can be a GPG-keyring repository type able to hold those keys.
• Repositories and Remotes that verify artifacts can add a foreign key to these GPG repositories and assume all the keys there are trusted for verification.
• Signing services can relate directly to the key and should prevent orphan cleanup from deleting the corresponding key, i.e orphan-clean up logic should be adjusted to look not only at repository_membership but also whether there are signing services that point to the key.
• It should be possible to import/export key repositories as well as they should be covered by RBAC.
• Keys should be identifiable by their fingerprint and probably stripped off their signatures (maybe store them as a separate content).
• A publication of the keyring repository should produce a keyring file (*.bkx) as a published artifact.

Describe alternatives you've considered We discussed whether keys should be content or a standalone generic model. But the benefits from handling keys as content is overwhelming.

Additional context This is not about private keys. Pulp will never set out to handle anything as sensitive as a private key. For signing we introduced the signing service already to handle all cases including the ones where you never get hold of the key itself.

[bmbouter]

The upside of having them be content is that they can be associated with repositories themselves if that is what plugin writers want. Also you get import/export and RBAC at low-cost then too.

The big benefit I see for this is the deduplication of the keys. Users wouldn't have to keep providing them over and over, and then if they ever change (rotation, perhaps?) you can update 1 object instead of N.

Overall (and without more details) this is all sounding good.

[ipanova]

@rochacbruno PTAL when you have time.

[pedro-psb]

(just connecting the dots, because I was reading this comment). This feature request should benefit from the proposal here.

[netsandbox]

@mdellweg where can I find the documentation for this new feature?

[mdellweg]

There is none yet. Also work is meant as an enabler for other ideas. What is currently possible: Create and distribute a "keyring" repository. Upload public keys into it. Download them through the distribution again. Reupload the same keys with additional signatures.