Scientific Linux GPG keys

Dear Community Members, I am using Foreman 1.22 with Katello 3.12 to provision Scientific Linux 7 (rolling) at an academic site.

I recently found that I was unable install to

  wget-1.14-18.el7_6.1.x86_64 

from the SL 7 ‘security’ yum repository owing to a gpg NOKEY error.

It seems that Scientific Linux 7 uses two gpg keys, namely RPM-GPG-KEY-sl7 and RPM-GPG-KEY-sl. I had set the former as ‘Content Credential’ when importing the SL 7 repos, but the security update has been signed with the latter.

Is there any way to assign multiple GPG keys to Products and yum repositories in Katello?

Many Thanks in Advance and Best Regards

Nick Gresham

You can assign a key to the product, but a different one directly to a repository.

Dear Dirk

many thanks for that suggestion, which does indeed seem to cure the immediate problem.

What concerns me is that there might be packages signed by either key in the same repo.

Indeed some products (e.g. more recent Puppet) specify multiple gpg keys for their yum repos.

Is there a way Katello (and underneath Pulp) can assign multiple gpg keys to a repository?

Best Regards

Nick Gresham

While possible in the repositories configuration of yum/dnf, I am quite sure Pulp 2 can not handle this at the moment (https://pulp.plan.io/issues/818). For Pulp 3 I do not see a feature request for this (https://pulp.plan.io/projects/pulp_rpm/roadmap), but perhaps you want to file one?

My personal view on this: I think a repository should only use one key for signing and I would more likely file an issue against the repository if not. You mentioned Puppet as an example, but they do only so in PC1 which is Puppet 4 and already out of support, with later versions they stopped doing so.

More seriously it seems that Scientific Linux does this: they sign RPMs with either their release key e.g.

RPM-GPG-KEY-sl7

or with their generic key

RPM-GPG-KEY-sl

This makes provisioning Scientific Linux from Katello problematic. Would anyone be able to suggest a work-around please?

In case anyone else encountering this it would seem that

subscription-manager repo-override --repo=Scientfic_Linux_7_Base_x86_64 --add=gpgkey:'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl7

(and the same for the Fastbugs and Security repos)

is a sufficient work-around.

1 Like