LinuxXII · Repository Security and Supply ChainTrust
Repository trust and GPG signing
What you'll learn
- Trace the chain of trust from maintainer key to installed binary
- Verify a repository key fingerprint against an authoritative source
- Audit the trust store on a production host
- Plan the GPG signing key lifecycle
Prerequisites
Verified against Ubuntu 24.04 LTS · Debian 12 (Bookworm) · RHEL 9.x · Rocky Linux 9.x · AlmaLinux 9.x · Linux kernel 6.1 LTS / 6.6 LTS · systemd 255+ · OpenSSH 8.7p1 (RHEL 9) / 9.6p1 (Ubuntu 24.04) · nftables 1.0.x · chrony 4.x · Pacemaker 2.1.x · Corosync 3.1.x · 2026-08-09
The package trust chain is one of the most security-critical parts of a Linux host. A compromised repository or key can install backdoors on every host that trusts it. The discipline is to verify every key, audit the trust store, and rotate keys on a schedule.
The trust chain
flowchart LR
M[Maintainer private key]
P[Package + signature]
D[Distribution signing key]
R[Repository]
H[Host trust store]
V[Verified install]
M -->|signs| P
D -->|signs metadata| R
R -->|hosts| P
H -->|trusts| D
H -->|verifies| V
- The maintainer signs the package with their private key.
- The distribution’s signing key signs the repository metadata (the index that lists every package).
- The repository hosts the packages and metadata.
- The host’s trust store contains the distribution’s public key.
- The package manager verifies the metadata signature with the trust store key; if valid, the metadata is trusted.
- Each package is verified against the metadata; if signed by the maintainer key listed in the metadata, the package is trusted.
A compromise at any step breaks the chain:
- Maintainer key compromised → packages signed with it cannot be trusted.
- Distribution key compromised → metadata can be forged, leading to package substitution.
- Mirror compromised → packages can be replaced before delivery.
- Host trust store compromised → arbitrary keys can be added, trusting arbitrary sources.
$ apt-key list 2>/dev/null | head -20; rpm -qa gpg-pubkey | head -10...Illustrative output
Verifying a key fingerprint
$ apt-key list 'F57D 9C7E 4F19 6E76 4F6E 6F4D 9B57 9A6F 0E54' 2>/dev/null; rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-rockyofficial 2>/dev/null; gpg --show-keys /usr/share/keyrings/ubuntu-archive-keyring.gpg 2>/dev/null | head...Illustrative output
- Download the key from the vendors HTTPS site
- Compare the fingerprint with the vendors published fingerprint in an announcement email, on a separate website, or in their documentation
- Only then add the key to /etc/apt/trusted.gpg.d/ or /etc/pki/rpm-gpg/
- Document the comparison in the runbook. Who verified, when, and against what source
Key lifecycle
| Phase | Action |
|---|---|
| Generation | Create the key on a hardware token (YubiKey, smart card); document the fingerprint. |
| Distribution | Publish the public key on multiple channels (HTTPS website, signed email, in-person at conferences). |
| Rotation | Replace the key before it expires or is suspected of compromise. |
| Revocation | Add to key revocation lists. Hosts that fetch the new metadata automatically see the revocation. |
| Backup | Back up the private key in a secure location (split knowledge, hardware). Loss of the signing key is unrecoverable. |
Knowledge check
Knowledge check · 3 questions
Q1. How do you verify a repository signing key before trusting it?
Q2. A repository mirror compromise requires re-verifying every package that came from that mirror.
Q3. Which of the following are correct key management practices? Select all that apply.
Passing score: 75%. Answers are checked in this browser.