GPG verification of RPMs

Ask Fedora
,
1

I’m little confused about GPG verification of RPMs.

dnf downloads RPM file from URL that is defined in the .repo file.
dnf use rpm for install downloaded RPM file and if in the repo file is definied gpgcheck=1 it uses -V flag with rpm.
rpm install RPM and check gpg signature if -V flag. rpm try find the public key for the RPM from something local path.
If rpm can’t find correct public key it fails.
dnf get know about this and download public key from the URL in gpgkey=https://example.com/key.asc of the repo file.
dnf try again with rpm

So, questions is:
dnf doesn’t check GPG signatures?
Always rpm try find GPG public keys from local? So dnf connect to https://example.com/key.asc only if rpm can’t find it the key local?
If GPG key isn’t in local, what is the idea that it download the key from the URL? I mean, if you can’t trust to your internet connection, the downloaded key doesn’t proof anything?
Why I need run rpm --import https://example.com/key.asc when I add a new repo? I mean, doesn’t dnf anyway download the signature immediately when I run sudo dnf upgrade?
What is the difference between rpm --import and rpmkeys --import?
Why rpm -qa list keys? The aren’t packages, right?
Where rpm stores local keys? Path /etc/pki/rpm-gpg/ contain hundreds keys but rpm -qa gpg-* just two? And I can’t find one of two key that rpm -qa gpg-* lists from /etc/pki/rpm-gpg/.

2

Normally, it does when installing a package from a repo.
In general case, this depends on the global DNF settings and custom repo settings.
It does not when the argument is an RPM file, locally downloaded or specified by a URL.

HTTPS and DoT should provide enough security, even if you don’t trust own ISP.

It helps to automate the key import.

Yes, you can also import the key manually.

There should be no difference, at least for now.

In the RPM database along with the metadata for installed packages.

The devs probably decided against using a separate key storage.

Correct.

Most of those files are just symlinks unrelated to the current version of the system, and the necessary ones should be already imported in the RPM database.

2 Likes
3

Doesn’t it also prompt you with the fingerprint of the signature? So you could, if you wanted to, check whether it’s a rogue keyfile or not:

Importing GPG key 0x12C944D0:
 Userid     : "Fedora (32) <fedora-32-primary>"
 Fingerprint: 97A1 AE57 C3A2 372C CA3A 4ABA 6C13 026D 12C9 44D0
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-32-x86_64
Is this ok [y/N]:

Cheers,
M

4

Yes, but the need to do this depends on your threat and trust model.
You can also utilize chains of trust with packages like distribution-gpg-keys.

5

Does dnf binary do this? Or it call rpm binary like I wrote in my example?*1

*1 “dnf downloads RPM file from URL that is defined in the .repo file.
dnf use rpm for install downloaded RPM file and if in the repo file is definied gpgcheck=1 it uses -V flag with rpm.”

Really? Why?

Why then we need signed packages? If you can trust to the key, that you downloaded in untrusted network, why you can’t trust to the packages, that you downloaded in the same network, without signing? By DoT you mean TLS over DNS?

Automate? IMO that is manually work.

Manually?

rpmkeys is not symlink to rpm, it’s own binary, so?

Then, how I can find them imported keys?

6

You can trace the dnf package dependencies down to rpm-libs that provides the necessary features.

You should address this question to the DNF devs on their bug tracker.

To provide additional security with data integrity and authenticity.
This is specifically relevant for repo mirrors controlled by a third party.

To trust a key, download it or its fingerprint using a secure protocol.
Secure protocols provide data integrity even in untrusted networks.

Yes.

Automation is required for unattended deployments and helps minimize human related errors when installing manually.

See the above post.

Both are provided by the same package, linked against the same libraries, and produce no detectable difference in result, so use the duck test.

The key to import is linked in the repo file, while already imported keys are in the RPM database:

rpm -q -i gpg-pubkey
7

It is more than that. The GPG verification is to ensure that the package you download was built and signed by Fedora, and if you can trust Fedora you can trust the downloaded package. HTTPS doesn’t say anything about where the data ultimately came from, and as you can download from a lot of different mirror sites, the certificate of the download morror site only tells you that you downloaded from the site you think you were downloading from.