COPR: GPG key changed?

Ask Fedora
, ,
1

Hi,
I maintain my “own” COPR, and use it for my installations, of course.

When I upgraded from system installation F37 to F38 (yesterday), some packages from the F38 branch of the COPR were already successfully installed/updated. These were older builds, from pre-release time (perhaps even when F38 was Rawhide).

Now yesterday, I added and rebuilt some packages in this COPR, and tried updating to them from the dnf command line, and got this:

Copr repo for non-fed owned by barsnick                                                                                                                                                                       2.0 kB/s | 1.0 kB     00:00    
GPG key at https://copr-be.cloud.fedoraproject.org/results/barsnick/non-fed/pubkey.gpg (0xB2AE9EC7) is already installed
The GPG keys listed for the "Copr repo for non-fed owned by barsnick" repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.. Failing package is: hilite-1.5-8sunshine.fc38.x86_64
 GPG Keys are configured as: https://copr-be.cloud.fedoraproject.org/results/barsnick/non-fed/pubkey.gpg
Public key for pipemeter-1.1.3-1.fc38.5sunshine.x86_64.rpm is not trusted. Failing package is: pipemeter-1.1.3-1.fc38.5sunshine.x86_64
 GPG Keys are configured as: https://copr-be.cloud.fedoraproject.org/results/barsnick/non-fed/pubkey.gpg
Public key for smbnetfs-0.6.3-0.fc38.2sunshine.x86_64.rpm is not trusted. Failing package is: smbnetfs-0.6.3-0.fc38.2sunshine.x86_64
 GPG Keys are configured as: https://copr-be.cloud.fedoraproject.org/results/barsnick/non-fed/pubkey.gpg
Public key for srelay-0.4.8p3-0.20190209.git3149960.fc38.7sunshine.x86_64.rpm is not trusted. Failing package is: srelay-0.4.8p3-0.20190209.git3149960.fc38.7sunshine.x86_64
 GPG Keys are configured as: https://copr-be.cloud.fedoraproject.org/results/barsnick/non-fed/pubkey.gpg
Public key for tcpblast-20120518-0.fc38.5sunshine.x86_64.rpm is not trusted. Failing package is: tcpblast-20120518-0.fc38.5sunshine.x86_64
 GPG Keys are configured as: https://copr-be.cloud.fedoraproject.org/results/barsnick/non-fed/pubkey.gpg
Public key for veracrypt-1.25.9-0.fc38.1sunshine.x86_64.rpm is not trusted. Failing package is: veracrypt-1.25.9-0.fc38.1sunshine.x86_64
 GPG Keys are configured as: https://copr-be.cloud.fedoraproject.org/results/barsnick/non-fed/pubkey.gpg
The downloaded packages were saved in cache until the next successful transaction.

Did the signing key in my COPR change? If so, how do I update it locally for the installation? Will this break packages signed with an old key?

In other words: How do I fix this situation? What should I have done in preparation?

Thanks,
M.

3

Of what, of these packages? Will try, but one of them was even built just now (new version and release), and fails. I don’t see what bumping will change.

4

Try updating the local key:

# List installed keys
rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n" gpg-pubkey | sort -k 2

# Remove installed key
sudo rpm -e gpg-pubkey-XXXXXXXX-XXXXXXXX

# Import repo key
sudo rpm --import https://download.copr.fedorainfracloud.org/results/${USER}/${REPO}/pubkey.gpg

Also confirm the GPG key URL in the repo file is valid:

sudo dnf config-manager --dump copr\* | grep -e gpg
3 Likes
5

That fixed it, thank you!

Why did it break?
Anyway, a user using any arbitrary COPR in their installation shouldn’t have to do this, right?

M.

6

FWIW, I’ve also upgraded to F38, installed some Copr packages that were built for F38 2-3 months ago, as well as some that were built today, and didn’t encounter this issue.

Why is the GPG key URL given as https://copr-be.cloud.fedoraproject.org/results/barsnick/non-fed/pubkey.gpg though? In the repo file it’s normally like this:

gpgkey=https://download.copr.fedorainfracloud.org/results/...

Something to do with mirrors? Or is your repo file different? /etc/yum.repos.d/_copr...

1 Like
7

Good observation! I have no idea. I added those coprs ages ago, and never manually modified the configuration. This machine was built January 2020, and the gpg-pubkey rpms noted something like
Install Date: Tue 14 Jan 2020 08:53:26 AM CET
Build Date : Thu 05 Feb 2015 07:03:22 PM CET

On a different machine, installed in November 2021 (still on F37), they report:
Install Date: Wed 01 Dec 2021 10:13:15 AM CET
Build Date : Tue 18 Feb 2020 11:38:18 AM CET

BTW, the keys not working on F38 were
gpg-pubkey-817fa275-54d3b06a
gpg-pubkey-b2ae9ec7-54d3b085

and the ones on the F37 machine (not broken yet) are
gpg-pubkey-817fa275-5e4bbe99
gpg-pubkey-b2ae9ec7-5e4bbe9a

So apparently, the keys could have changed in February 2020, and existing installations didn’t pick it up, and worked until now?

M.

8

The Fedora distribution and infrastructure rely on crypto policies to keep security at a high enough level, however it requires periodic updates:

This also raises security requirements to crypto keys, since old keys may use vulnerable algorithms, or may not have enough key length to provide the chain of trust.

It appears that updating Copr keys requires manual action on the client side.