Introduce GPG Key Support for Pulp RPM Remote Creation

[VrindaMarwah]

As I can see currently, Pulp RPM remote creation does not provide an option to manage GPG keys required for validating RPM repository metadata and packages. This limitation makes it difficult to enforce secure package verification.

Requirement:
When creating an RPM remote using pulp rpm remote create, user can specify a GPG key and enforce GPG signature verification during repository sync. Clear error reporting when GPG validation fails.

[dralley]

Hello, this is a valid feature request, but we do have similar ones already open, could you please add any details to these existing requests which you feel are missing?

#2258
#2285

Also, could you expand a bit on your specific needs and why the standard client-side signature verification enforced by DNF etc. falls short for your particular workflow? It just helps to understand how "worth it" this would be to add.

[VrindaMarwah]

Hi @dralley – expanding on our requirement:

We want to enforce package integrity and authenticity whenever an upstream RPM repository is synced into Pulp.
What this means is that if any upstream RPM repository is configured and synced into Pulp, we should ensure that:

• GPG signature verification is enabled
• Packages are validated against a trusted GPG public key
• Unsigned or improperly signed RPMs are rejected
• Sync does not proceed silently without verification

Why this is important
When syncing from an upstream source, we are effectively trusting external content.

Expected Behavior in Pulp
For every RPM remote used in a sync:

• A gpgkey (or equivalent configuration) must be provided.
• Signature verification should be enabled (gpgcheck=1 equivalent behavior).
• Sync should fail if:
  - The key is missing
  - The signature is invalid
  - The package is unsigned (if policy requires strict signing)

[VrindaMarwah]

Hi @dralley - was wondering if you have any update on the above requirement?

[dralley]

@VrindaMarwah Thanks, that is helpful.

It is possible to add in the medium term, I think it will require some reconfiguration and refactoring of our sync pipeline to accomplish, but that needs to happen anyways. I appreciate the details.

A few more questions:

How do you envision it working? Do you expect all packages in a repo to be uniformly signed by A particular key, or just one of a shared set of trusted keys? What about key rotations? A specific example: RHEL is currently in the process of gradually re-signing packages with PQC (quantum-safe crypto) keys, so there is a mix of packages signed by different Red Hat release keys.

[dralley]

We currently have some features planned around checking the key fingerprints as a bit of a half-step towards full verification. Also, presumably the validation should be uniform, i.e. packages uploaded or copied into the repo also perform the same signature validation, not just sync.

[daviddavis]

@dralley we'd be interested in the non-sync use cases. Is there a separate issue for that or should I just follow this issue?

[dralley]

Part of the key management is already kinda implemented: pulp/pulpcore#5133

But, we have not really used this at all yet, and integration is probably a challenge. How do you tie public keys to repos and packages, how is the verification handled, etc.

[dralley]

@daviddavis (and others) - for now I suppose we can just use this as a discussion thread. Eventually we can split off the different use cases that come out of it.

I have also heard from some others that it would be useful to store additional metadata beyond just the fingerprints, such as signature version and algorithm type. But, I suppose if you were storing public keys on a keyring inside of Pulp, you could always just have that info attached to the public keys, and correlate it using the fingerprint. And that potentially enables verification use cases.