Packages, repositories and signing

Before you read. Lesson 08 established that packages are signed and that the machine holds the key. That was a one-sentence answer to a question worth asking properly.

A signature proves the package came from whoever holds the key and was not altered afterwards. It is the difference between trusting a network path and trusting a publisher.

So what does adding a third-party repository actually commit you to?

Not one package. Every package that publisher will ever ship you, installed automatically by dnf upgrade at 2am, running as root. That is a larger decision than the two commands it takes suggest, and this lesson is mostly about making it deliberately.

Some words you will need

repository

A server holding packages plus an index. The machine has a list of them.

GPG key

The publisher's public key. Used to verify signatures; holding it is the trust decision.

signature

Proof a package was produced by the key holder and has not changed since.

pin

A rule holding a package at a version, or preferring one repository over another.

alternatives

A mechanism letting several packages provide the same generic command.

What breaks without this

You install unsigned software and do not notice. Every family has a flag that disables verification, and it appears in a great many internet instructions.

A third-party repository quietly replaces system packages. A badly-scoped repo can supply a newer glibc or systemd than the distribution, and the machine becomes unsupportable.

You cannot answer “where did this file come from”. Which is the first question in any incident involving an unexpected binary.

What a signature proves

A package is downloaded and rpm -K is asked to check it. That command reports on two independent things in one line.

# AlmaLinux 10.2, x86_64
$ cd /tmp; dnf download tree -q >/dev/null 2>&1 || dnf install -y -q dnf-plugins-core >/dev/null 2>&1 && dnf download tree -q >/dev/null 2>&1; ls *.rpm 2>/dev/null && rpm -K tree*.rpm && echo '--- and the full signature line ---' && rpm -qpi tree*.rpm 2>/dev/null | grep -i signature
tree-2.1.0-8.el10.x86_64.rpm
tree-2.1.0-8.el10.x86_64.rpm: digests signatures OK
--- and the full signature line ---
Signature   :

digests signatures OK is the whole verification, and it is two separate checks. Digests confirm the file is intact, the contents match the checksums recorded in the package. Signatures confirm the package was signed by a key the machine trusts.

The keys the machine trusts are themselves stored as pseudo-packages:

# AlmaLinux 10.2, x86_64
$ dnf install -y -q tree >/dev/null 2>&1; echo '--- who signed this package ---'; rpm -qi tree | grep -E 'Signature|Name|Version'; echo '--- and the keys this machine trusts ---'; rpm -q gpg-pubkey --qf '%{SUMMARY}\n' | head -4
--- who signed this package ---
Name        : tree
Version     : 2.1.0
Signature   :
--- and the keys this machine trusts ---
AlmaLinux OS 10 <packager@almalinux.org> public key

One key, one publisher. That listing is the machine’s complete trust set for packages, and on a server that has accumulated third-party repositories over the years it is worth reading, every entry is somebody who can install software as root on that machine.

What a signature does not prove is worth being equally clear about. It says nothing about whether the software is safe, well-written, or free of vulnerabilities. It proves origin and integrity, and those are exactly two properties. A signed package from a compromised publisher is a correctly signed malicious package.

Adding a repository, on each family

RHEL family, a .repo file in /etc/yum.repos.d/:

[example]
name=Example Software
baseurl=https://packages.example.com/el10/$basearch/
enabled=1
gpgcheck=1
gpgkey=https://packages.example.com/RPM-GPG-KEY-example

sudo rpm --import https://packages.example.com/RPM-GPG-KEY-example
sudo dnf repolist

gpgcheck=1 is the line that matters and the one that instructions sometimes tell you to set to 0. Never do that. If a repository’s packages are unsigned, that is information about the publisher, not an obstacle to route around.

Debian family, a source list plus a keyring:

curl -fsSL https://packages.example.com/gpg.key \
  | sudo gpg --dearmor -o /usr/share/keyrings/example.gpg

echo "deb [signed-by=/usr/share/keyrings/example.gpg] https://packages.example.com stable main" \
  | sudo tee /etc/apt/sources.list.d/example.list

sudo apt update

signed-by= is the modern form and it matters. The old apt-key add put a key into a global keyring that was trusted for every repository, so a third-party key could sign a replacement for any Debian package. signed-by= scopes the key to one source, which is the whole point of adding a key at all. apt-key is deprecated and removed on current releases.

EPEL is the exception worth knowing by name on the RHEL family: Extra Packages for Enterprise Linux, maintained by the Fedora project, and the usual source for things RHEL does not ship.

sudo dnf install epel-release

It is packaged, so the repository definition and the key arrive together and verifiably, which is the pattern to prefer for any third party that offers it.

sudo rpm --import https://packages.example.com/RPM-GPG-KEY-example
rpm -qa gpg-pubkey --qf '%{SUMMARY} %{VERSION}\n'   # confirm what you imported
sudo dnf install thepackage

[epel]
priority=99

Package: *
Pin: origin download.example.com
Pin-Priority: 100

dnf repoquery --qf '%{name} %{repoid}' --installed | grep -v ' baseos\| appstream'
apt-cache policy
apt list --installed 2>/dev/null | grep -v Debian

Querying what is installed

The low-level tools answer questions about the local database. They do not talk to repositories.

rpm -V is the one worth knowing and rarely used. It compares every installed file against the checksums, sizes, permissions, and ownership recorded at install time, and reports what differs:

sudo rpm -Va | grep -v '^..5......  c '

The output is a column of flags per file (5 a changed checksum, S size, M mode, U owner) and the c marks config files, which are supposed to change, hence filtering them out. A modified binary in /usr/bin with no explanation is a genuine finding, and this is the only routine way to notice one.

debsums -c is the Debian equivalent and needs installing.

Holding a package back

Sometimes a package must not move: a database certified against one point release, or a kernel a vendor driver was built against.

Every hold stops security updates for that package, silently, indefinitely. The person who set it will have moved on and the hold will not have. It is a decision with an expiry date and no mechanism to enforce one.

Three things make it survivable: record it where the fleet’s configuration lives rather than only on the machine, scope it as narrowly as possible (one package, never a repository) and put a review date on it somewhere a human will see.

Excluding kernels to protect an out-of-tree driver is the specific case worth refusing. It trades a driver problem for an unpatched kernel, which is considerably worse. DKMS from lesson 10 solves it properly.

[example]
includepkgs=example-agent example-agent-plugins
priority=99

sudo update-alternatives --config java     # Debian family
sudo alternatives --config java            # RHEL family
sudo update-alternatives --display java    # what is registered, and priorities

sudo update-alternatives --install /usr/local/bin/mytool mytool /opt/mytool/2.1/bin/mytool 100

Across distributions

The deb822 format (the .sources files with Types:, URIs:, and Signed-By: keys seen in lesson 08) is replacing the one-line .list format on Debian and is clearer. Both work on current releases.

Prove it

After adding a repository:

# Is it enabled, and what is it called
dnf repolist                        # RHEL family
apt policy                          # Debian family

# What is it actually offering
dnf repoquery --repo=example --available | head -20
apt list --all-versions -a thepackage

# Which repository will a package come from
dnf info thepackage | grep -i repo
apt policy thepackage

# Is verification actually on
grep -r gpgcheck /etc/yum.repos.d/
grep -r signed-by /etc/apt/sources.list.d/

apt policy thepackage is the underrated one. It shows every available version, which repository each comes from, and which one apt would install, answering “why am I getting this version” in a single command.

What trips people up

1. GPG check failed

NO_PUBKEY on Debian or GPG check FAILED on RHEL means the key is missing or does not match.

Import the key properly. Do not reach for --nogpgcheck or --allow-unauthenticated; the message is the security control working.

A second cause worth knowing: the publisher rotated their key. Their documentation will say so, and the fix is importing the new one, not disabling the check.

2. apt-key in an instruction

Deprecated and removed on current releases, because it trusted the key for every repository rather than one.

gpg --dearmor into /usr/share/keyrings/ and reference it with signed-by=. Any guide still using apt-key is old enough to be worth double-checking generally.

3. A third-party repo replacing system packages

The repository offers a newer glibc or systemd and wins the version comparison, and the machine stops being the distribution it claims to be.

includepkgs= and priority= on RHEL, pin priorities on Debian. Check what a repository offers before enabling it.

4. A package that will not move

Usually a hold or an exclude set months ago by somebody who has left.

dnf versionlock list or apt-mark showhold. Also check exclude= in /etc/dnf/dnf.conf and anything in /etc/apt/preferences.d/.

5. Assuming a signature means “safe”

It proves origin and integrity only. A signed package from a compromised publisher is a correctly signed malicious package, and supply-chain attacks work precisely this way.

Work it through

A vendor’s installation guide for their monitoring agent reads:

curl -s https://packages.vendor.example/setup.sh | sudo bash

You are asked to install it on forty production servers. Reason it out before reading on.

What that command does, spelled out: downloads a script whose contents nobody has seen, over a connection whose only guarantee is that the hostname matched a certificate, and executes it as root. It will almost certainly add a repository and a key, and it may do anything else at all.

Once. On forty machines. With no record of what it did.

What to do instead, in order.

Read it first. curl -s https://packages.vendor.example/setup.sh | less. That one change costs nothing and turns an unknown into a known. It will typically show you the repository URL and the key URL, which are the two things you actually need.

Add the repository yourself, with the key imported explicitly and the fingerprint checked against the vendor’s documentation on a different page:

sudo rpm --import https://packages.vendor.example/RPM-GPG-KEY
rpm -qa gpg-pubkey --qf '%{SUMMARY} %{VERSION}\n'

Scope it. includepkgs=vendor-agent vendor-agent-* and priority=99 in the .repo file, so this vendor can never supply anything except their agent. Check what they are offering first:

sudo dnf repoquery --repo=vendor --available | wc -l

Four hundred packages including openssl is a different proposition from six packages, and it is worth finding out which before rather than after.

Then install normally, with verification on, and let configuration management place the repo file and the key on all forty rather than a curl-to-bash on each.

Test on one machine, and record what changed:

sudo dnf history          # what the transaction actually did
sudo dnf history info 42

Which also gives you dnf history undo 42 if it goes wrong, something the shell script cannot offer.

Now the point worth extracting. The package manager already solves this problem and the script asks you to opt out of it. Signature verification, a record of what was installed, a list of files owned, an upgrade path, and a rollback are all things you get for free from dnf install and lose entirely from curl | bash.

The habit: when a vendor offers a script and a repository, take the repository. And when they offer only a script, read it, because the repository is in there, and using it directly is nearly always available to you even when the documentation does not mention it.

Try it

Optional, on any machine.

1. rpm -qa gpg-pubkey --qf '%{SUMMARY}\n' or ls /usr/share/keyrings/ /etc/apt/trusted.gpg.d/. Read your trust set.
2. dnf repolist or apt policy. Name every repository and why it is there.
3. rpm -qf $(which ls) or dpkg -S $(which ls).
4. rpm -ql coreutils | head or dpkg -L coreutils | head.
5. sudo rpm -Va | head -20 or sudo debsums -c. Read the flags.
6. apt policy bash or dnf info bash | grep -i repo.
7. update-alternatives --display editor if it exists, and follow the symlinks.

Verification step. You have it when you can add a third-party repository, scoped to the packages you actually want, with its key verified, and explain to somebody why --nogpgcheck was not part of it.

Check yourself

sudo rpm -Va | grep -v ' c '

References

• rpm(8) - Linux man-pages project. Accessed 2026-08-07.
• dpkg(1) - Linux man-pages project. Accessed 2026-08-07.
• sources.list(5) - Debian Project. Accessed 2026-08-07.
• apt-secure(8) - Debian Project. Accessed 2026-08-07.
• dnf.conf(5) - DNF project. Accessed 2026-08-07.
• update-alternatives(1) - Debian Project. Accessed 2026-08-07.

Every block above with a distribution and architecture header was captured by running the command on an AlmaLinux 10.2 container. Blocks without one are illustrative.