Skip to main content
RunBook Academy

LinuxXII · Repository Security and Supply ChainTrust

Repository trust and GPG signing

Foundation⏱ ~10 minbashgpgapt-keyrpm --checksig

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

Not yet marked complete on this device.

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
  1. The maintainer signs the package with their private key.
  2. The distribution’s signing key signs the repository metadata (the index that lists every package).
  3. The repository hosts the packages and metadata.
  4. The host’s trust store contains the distribution’s public key.
  5. The package manager verifies the metadata signature with the trust store key; if valid, the metadata is trusted.
  6. 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.
Read-only / Safetrust store inventory
$ apt-key list 2>/dev/null | head -20; rpm -qa gpg-pubkey | head -10
...

Illustrative output

Verifying a key fingerprint

Read-only / Safekey fingerprints
$ 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

  1. Download the key from the vendors HTTPS site
  2. Compare the fingerprint with the vendors published fingerprint in an announcement email, on a separate website, or in their documentation
  3. Only then add the key to /etc/apt/trusted.gpg.d/ or /etc/pki/rpm-gpg/
  4. Document the comparison in the runbook. Who verified, when, and against what source

Key lifecycle

PhaseAction
GenerationCreate the key on a hardware token (YubiKey, smart card); document the fingerprint.
DistributionPublish the public key on multiple channels (HTTPS website, signed email, in-person at conferences).
RotationReplace the key before it expires or is suspected of compromise.
RevocationAdd to key revocation lists. Hosts that fetch the new metadata automatically see the revocation.
BackupBack up the private key in a secure location (split knowledge, hardware). Loss of the signing key is unrecoverable.

Knowledge check

Knowledge check · 3 questions

  1. Q1. How do you verify a repository signing key before trusting it?

  2. Q2. A repository mirror compromise requires re-verifying every package that came from that mirror.

  3. Q3. Which of the following are correct key management practices? Select all that apply.

Passing score: 75%. Answers are checked in this browser.