Why does dnf give GPG signature verification errors for repos with repo_gpgcheck=1?

Ask Fedora
, ,
1

I’m trying to figure out why dnf has started complaining about GPG signatures for my third-party repositories. I feel like this is probably covered in a topic here somewhere but can’t quite find it. Thanks in advance for any ideas.

I have two third-party repositories in /etc/yum.repos.d at the moment, one for LibreWolf and one for Proton. What I’ve been seeing lately is:

$ sudo dnf upgrade
Updating and loading repositories:
 LibreWolf Software Repository                                                                100% |   5.3 KiB/s |   3.8 KiB |  00m01s
>>> Librepo error: repomd.xml GPG signature verification error: Signing key not found                                                 
 ProtonVPN Fedora Stable repository                                                           100% |   6.6 KiB/s |   3.7 KiB |  00m01s
>>> Librepo error: repomd.xml GPG signature verification error: Signing key not found                                                 
Repositories loaded.
Nothing to do.

It seems like it should have the keys and everything matches, so I’m not sure what it’s complaining about. For example in /etc/yum.repos.d/librewolf.repo I have:

[repository]
name=LibreWolf Software Repository
baseurl=https://repo.librewolf.net
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://repo.librewolf.net/pubkey.gpg

And then it looks like it already has the key:

$ rpmkeys --list 2b12ef16-627f7187
2b12ef16-627f7187: LibreWolf Maintainers <gpg@librewolf.net> public key

If I try to go through step by step with gpg and check it myself using the files from the repo, I think everything checks out:

$ wget https://repo.librewolf.net/pubkey.gpg
$ wget https://repo.librewolf.net/repodata/repomd.xml
$ wget https://repo.librewolf.net/repodata/repomd.xml.asc
$ gpg --dearmor < pubkey.gpg > pubkey.dearmor.gpg
$ gpg --no-default-keyring --keyring ./pubkey.dearmor.gpg --list-keys --with-colons | grep -i 2b12ef16
pub:-:4096:1:40339DD82B12EF16:1652519303:::-:::scSC::::::23::0:
fpr:::::::::662E3CDD6FE329002D0CA5BB40339DD82B12EF16:
$ gpg --no-default-keyring --keyring ./pubkey.dearmor.gpg --verify repomd.xml.asc repomd.xml
gpg: Signature made Wed 12 Mar 2025 04:58:09 PM EDT
gpg:                using RSA key 4DD4BBECABD32E798CC77A4047981EA73D0E1C63
gpg: Good signature from "LibreWolf Maintainers <gpg@librewolf.net>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 662E 3CDD 6FE3 2900 2D0C  A5BB 4033 9DD8 2B12 EF16
     Subkey fingerprint: 4DD4 BBEC ABD3 2E79 8CC7  7A40 4798 1EA7 3D0E 1C63

…so I don’t see why dnf says the signing key isn’t found. Any suggestions?

2

Try import the gpg key into dnf using

sudo rpmkeys --import pubkey.gpg
3

I’ve also hit this for the first time on a new install so I’m not sure if it’s a change that affects new installs only or existing installs with repos that have signing certs specified as a URL but from the first question, it sounds like existing setups may be affected.

I get the same error, even after installing the key manually

# wget -O firefoxpwa-gpgkey https://packagecloud.io/filips/FirefoxPWA/gpgkey
# rpmkeys --import firefoxpwa-gpgkey
# dnf install firefoxpwa
Updating and loading repositories:
 FirefoxPWA                                                                             100% |   2.3 KiB/s |   2.7 KiB |  00m01s
>>> Librepo error: repomd.xml GPG signature verification error: Signing key not found                                           
Repositories loaded.
Failed to resolve the transaction:
No match for argument: firefoxpwa
You can try to add to command line:
  --skip-unavailable to skip unavailable packages

It looks like this issue has been reported upstream already: dnf5 issue #2134

1 Like
4

Thanks! It doesn’t say anything, though, and then just still lists that same key, so I think it already has it:

$ sudo rpmkeys --import pubkey.gpg
$ rpmkeys --list | grep LibreWolf
2b12ef16-627f7187: LibreWolf Maintainers <gpg@librewolf.net> public key

(Am I interpreting that right? I’ve never delved much into all the signature-handling stuff in dnf/yum/rpm, or GPG in general for that matter.)

If I’m reading the man pages right, I think I can confirm that it has that exact key. I can see the package entry for it like:

$ rpm -qi gpg-pubkey-2b12ef16-627f7187 | head -n 20
Name        : gpg-pubkey
Version     : 2b12ef16
Release     : 627f7187
Architecture: (none)
Install Date: Mon 17 Mar 2025 07:52:26 AM EDT
Group       : Public Keys
Size        : 0
License     : pubkey
Signature   : (none)
Source RPM  : (none)
Build Date  : Sat 14 May 2022 05:08:23 AM EDT
Build Host  : localhost
Packager    : LibreWolf Maintainers <gpg@librewolf.net>
Summary     : LibreWolf Maintainers <gpg@librewolf.net> public key
Description :
-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBGJ/cYcBEADGzCTFlHVTGQ43a/7d0gsAzXbBhS+7kIexmS3vY19YSiGTKtBf
LYmM3JN1Rc1aF1FUD48omDXYVLhFveMh42B2Pf8kcZ8dHD+42Dwx/LKlKy0qw2yR
ftzmZNkwUoFhg/X+WEAnHKeOI11c9Cdc6sDwIC9aJ4o3VWkRdoEpG60zjCvhmEn4

And then I can see the same byte-for-byte key ASCII (just excluding empty lines present/absent around the BEGIN/END bits) like:

$ rpm -qi gpg-pubkey-2b12ef16-627f7187 | grep "PUBLIC KEY BLOCK" -A 1000 | grep -v ^$ | sha256sum
6ab4c0157b9ec55b533a4971ec98f6c9489867c22aa169ad47c8c2cdd46a9bd3  -
$ grep -v ^$ pubkey.gpg | sha256sum 
6ab4c0157b9ec55b533a4971ec98f6c9489867c22aa169ad47c8c2cdd46a9bd3  -
5

Filed as RHBZ #2352958

1 Like
6

Thanks Tim, that definitely sounds relevant. Should have mentioned it already, but I’m on dnf5 5.2.11.0 like the github issue describes.

dnf5 version 5.2.11.0
dnf5 plugin API version 2.0
libdnf5 version 5.2.11.0
libdnf5 plugin API version 2.2
7

According to the upstream issue, the suspected commit is 0f1242b from 2 weeks ago and first released in 5.2.11.0

8

You are interpreting that correctly, which means this is a bug, which others have already stated. For now you could, if you like, disable repo_gpgcheck which the Fedora repositories hasn’t been using for years.

9

Curious - why isn’t repo_gpgcheck=1 by default?

10

It is a choice by Fedora.
If you enable it, you can’t update anything as the repomd.xml file isn’t signed in the Fedora repositories and not in rpmfusion either. It is signed in Librewolf, however, by the file repomd.xml.asc.

11

I added it to dnf.conf, and I was still able to update through dnf.

12

It is a per repository setting, that is, changed in the files found in /etc/yum.d.

13

Why is that? Doesn’t that open up a route for an MTM attack?

14

The file repomd.xml is protected by the contents of metalink.xml which is downloaded from Fedora controlled servers.

<?xml version="1.0" encoding="utf-8"?>
<metalink version="3.0" xmlns="http://www.metalinker.org/" type="dynamic" pubdate="Sun, 02 Mar 2025 13:33:28 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager">
 <files>
  <file name="repomd.xml">
   <mm0:timestamp>1729778159</mm0:timestamp>
   <size>5959</size>
   <verification>
    <hash type="md5">a103470107676577f5d80a84171aa0e5</hash>
    <hash type="sha1">a0e9b164619ce0f829093b00187c1eff7e3f993b</hash>
    <hash type="sha256">cccd8f40de8963c497520d50a3ddbad525f0a180dbcb3841ff892a0f64341b29</hash>
    <hash type="sha512">821b280e9b5e74e693b5e239edf36ee41013c0cf888d27b893c833f6b8e361f9633e705d70ac4f6995d150749420216aeffb29610706d851b3667075c346fdb5</hash>
   </verification>
...

For the reason, ask someone at Fedora who could decide to enable or disable signing the repomd.xml file.

1 Like
15

The new dnf5 versions should fix this issue

Name        : FEDORA-2025-748bf44daa
Title       : dnf5-5.2.12.0-1.fc41
Severity    : Critical
Type        : unspecified
Status      : stable
Vendor      : updates@fedoraproject.org
Issued      : 2025-03-19 08:02:05
Description : [DNF 5.2.12.0 upstream release notes](https://github.com/rpm-software-management/dnf5/releases/tag/5.2.12.0)
            : 
            : This release fixes [a rather urgent 
            : regression](https://github.com/rpm-software-management/dnf5/issues/2134) where
            : DNF5 refuses to pull missing signing keys from repos during syncing.
            : 
            :
1 Like
16

Woah, thanks for sharing this, could you explain how this is fixed and what people need to do to get repo_gpgcheck to work?

(Can I also install fc41 dnf5 package on f40? Doesn’t feel like there should be any issues, should there?)

17

It may happen at some point, but it doesn’t really add any security for
us and in the past there were real interface issues with dnf around it.

I was going to look at those again, but this thread shows there’s still
issues in dnf5 with signed repodata… at least it’s fixed now.

18

I don’t know. I just saw the update information when I checked the updates. People should then just update the way they usually do, and the test if they now can install from repositories which enables repo-gpgcheck.

Just stay on dnf4.

19

I’ve been using dnf5 concurrently for testing.

20

A work-around is to find the repo in /etc/yum.repos.d and change “enabled=0” to “enabled=1”.
ONLY do this if you trust the repo. Ran into this trying to install Librewolf from their repo instead of the Flatpak.