Help me understand Katello published gpg keys?

Problem:
I want to understand why the gpg keys published at ie.:
https://redacted.net/katello/api/v2/repositories/92/gpg_key_content
contains the public gpg key used to sync upstream content, and not the public gpg key for the katello content.

I can see that ATIX subscription-manager sets:

gpgcheck: 1
gpgkey: https://redacted.net/katello/api/v2/repositories/92/gpg_key_content

in rhsm.sources so i thought i could get rid of my semi-manual way of registering new hosts, where i need to add the key to get the initial repo for installing software before using subscription-manager to register and setup the rest of the repos.

But when i look at this gpg_key_content i can see that this is the public gpg key for the source/upstream repo and not the one for the katello repo.

Expected outcome:
If my understanding is correct i would expect katello to publish the “downstream” gpg key and not the “upstream” gpg key.

Ive looked at the documentation, and the only thing i could find is in the foreman katello docs regarding setup of repos where you can specify the GPG key:

Optional: From the GPG Key list, select the GPG key if you want to verify the signatures of the Release files associated with the Debian repository.

And this is what im seeing as well, i also tried just removing the GPG keys there and when syncing i get a warning about this, so thats all fine. But i dont understand why we dont have any publishing of the gpg that the clients need, but we publish the upstream key that nobody needs?

Foreman and Proxy versions:
3.13.1
Foreman and Proxy plugin versions:

Distribution and version:
Rhel9.5
Other relevant data:

I figured i’d actually look at the DEB822 syntax and i see now that the file that subscription-manager generates isnt exactly that…

The gpgkey property doesnt seem to exist, so even tho if katello published the actual pub key, apt wouldnt magically be able to retrieve this.

But my question still stands, i dont see why we are publishing the source pub gpg and not the katello pub gpg…

Hi @nem

There’s a difference between Yum and Deb content:

  • Yum: Packages are signed by the OS vendor (Red Hat, Oracle, Fedora Project, AlmaLinux, etc) or the software vendor (e.g. nginx signs its RPM packages). If you sync those to Foreman+Katello, the signature stays on the RPM package; Katello/Pulp does not resign the packages. → Clients have to verify the signature of the packages with the GPG pub key of the original OS/software vendor. You can get associated GPG pub keys from the Katello API.
  • Deb: In the Debian/Ubuntu world, metadata of APT repositories are signed (e.g. Release.gpg and InRelease on Index of /debian-security/dists/bookworm-security). If you synchronize Deb content to Foreman+Katello, Katello will check the signature of the metadata before synchronizing it if you associate content credentials. When you do content management (e.g. creating CVs, filtering content, etc), then Pulp will re-create the APT repository metadata. Afterwards, Katello will sign the APT repo metadata with its own key. Clients have to use the pulp_deb_signing.key from your Foreman+Katello instance to verify the authenticity.

You can see the difference in Registering a Debian host compared to Registering an Oracle Linux host documentation for orcharhino (an enterprise product based on Foreman+Katello).

2 Likes

Hello,
This makes sense, i didnt know the details of how content was signed and how the clients (dnf/yum, apt) differs.

So the rhsm.sources file generated by subscription-manager contains some invalid data when on DEB systems, but it still works (just that you need to get the gpg key on the system to be able to validate the signed release files.)

I need to say, this all came from me getting frustrated with my semi-manual process of registering deb hosts. I didnt have any good way of obtaining the key before consuming my published repos. I have finally taken time to get the “new” global registration working and this is much more smooth than what i did previously.

And it automatically handles GPG keys (and certs) so i dont need to worry about it any more…