How does a Debian- or RPM-based Linux host establish that the packages it installs from a repository are authentic, and what exactly carries the cryptographic signature in each case?
answer
- one side signs the index, the other the package
- hashes chain from Release down to each .deb
- imported RPM keys are queryable as pseudo-packages
- expiry defends against freeze attacks
- TLS protects the mirror, not the artifact
basics
~20 sAPT signs the repository index: one signature over a file whose hashes chain down to each package, so individual .deb files need no signature. RPM signs each package in its own signature header, and the repository metadata can be signed separately as a second check.
solid answer
~60 sThe two ecosystems anchor trust at different places. On the APT side, the repository publishes a `Release` file listing the hashes of its index files; that file is signed, either inline as `InRelease` or with a detached `Release.gpg`. The index lists a digest for every `.deb`, so one valid signature transitively covers every package — which is why Debian packages are normally not signed individually at all. On the RPM side, each package carries its own GPG signature in its signature header, and `rpm` verifies it at install time provided the corresponding key was imported into its database, where imported keys appear as `gpg-pubkey` entries. Repositories may additionally sign their `repomd.xml` metadata, checked separately. Modern APT practice is one keyring file per repository, bound to that repository with a `Signed-By` field, so a single third-party key cannot vouch for the whole system — the old global keyring approach is deprecated. TLS is not a substitute: it protects the transport to a mirror you may not control, while the signature protects the artifact.
code
bash · 3 lines# RPM: verify a loose package, then list the keys this host trusts
rpm --checksig ./myapp-1.2.3-1.el9.x86_64.rpm
rpm -qa gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE} %{SUMMARY}\n'go deeper
Know that packages come from repositories whose contents are cryptographically signed, and that the host must already trust the publisher's public key before it will accept them.
Explain the two anchor points: APT signs the index and chains digests down to each package, while RPM signs each package in its own signature header and can additionally check signed repository metadata.
Reason about the operational failures — missing or rotated keys on long-lived hosts, expired indexes on stale mirrors, digest mismatches from partial syncs — and never resolve them by turning verification off.
Own the trust policy: which parties may vouch for code that runs as root on the fleet, whether third-party keys are scoped per repository, how signing keys are held and rotated in your build pipeline, and how key expiry is handled on images that live for years.
## The threat model first Installing a package runs vendor-supplied code as root and writes files anywhere on the filesystem. So the question "where did this package come from?" is a privilege question, not a hygiene question. Package signing exists to answer it, and to answer two more: has the artifact been modified in transit or at a mirror, and am I being served a stale set of packages to keep a known vulnerability installed? ## APT: sign the index, chain to the packages A Debian-style repository publishes, per suite: - `Packages` index files, one per component and architecture, each listing every package's control stanza plus its size and content digest, - a `Release` file that lists the digests of those index files, along with metadata such as the suite name, the origin, and a `Valid-Until` timestamp, - a signature: `InRelease` (the Release content with an inline OpenPGP signature) or a detached `Release.gpg`. Verification runs downhill. The client checks the signature on `InRelease` against a trusted key, then checks each downloaded index against the digest recorded in `Release`, then checks each downloaded `.deb` against the digest recorded in the index. One signature therefore covers the whole repository transitively, and an individual `.deb` file needs no signature of its own — which is precisely why a `.deb` downloaded from a web page is a weak distribution channel: detached from its repository, there is nothing to verify. The `Valid-Until` field is the anti-freeze defence. Without it, an attacker who can only *withhold* updates could serve last year's signed index forever, keeping vulnerable versions in place while every signature still checks out. An expired `Release` file makes the client refuse the repository — the annoying error on a machine that has been powered off for months is that mechanism working. **Key management** is where practice has changed. Historically keys went into one global keyring, and any key in it could vouch for any repository. Current practice is one key file per repository under `/etc/apt/keyrings/`, referenced by a `Signed-By` field in that repository's source entry, so a third-party vendor's key is trusted *only* for that vendor's repository. The old global-keyring tooling is deprecated on current releases and should not appear in new instructions. ``` Types: deb URIs: https://repo.example.com/debian Suites: bookworm Components: main Signed-By: /etc/apt/keyrings/example.asc ``` ## RPM: sign the package itself An RPM package has a signature header preceding its metadata header, containing digests over the header and payload plus an OpenPGP signature. `rpm` verifies it during installation when the repository or client configuration requests package checking, and it can be verified on a loose file at any time — an RPM detached from its repository is still verifiable, unlike a `.deb`. For that check to mean anything the public key must be imported into RPM's own database. Imported keys are stored as pseudo-packages named `gpg-pubkey`, so the set of keys a host trusts is queryable exactly like installed software — a useful audit surface. Repository metadata signing is a separate, additional control: `repomd.xml` may be signed, and clients can be configured to require that too. Turning both on means the index and each artifact are independently authenticated. A practical failure mode: a package built in-house and pushed to an internal repository with no signature will install fine while checking is off, then start failing the day someone enables it fleet-wide. Sign at build time, not at deploy time. ## What a signature does and does not prove A valid signature proves the artifact is byte-identical to what the holder of that private key published. It proves nothing about whether the software is safe, whether the key holder was compromised, or whether the build machine that produced the artifact was clean. Adding a third-party repository key is therefore a decision to let that party run code as root on your machines, forever, until you remove the key — and it does not weaken the distribution's own keys, but it does add a second party with equivalent reach. It also does not replace transport security, and transport security does not replace it. Mirrors are frequently run by third parties; TLS proves you are talking to *that mirror*, while the signature proves the bytes originated with the distribution. Serve over HTTPS and verify signatures. ## The errors you will actually see - **Missing public key** — the repository is signed by a key the host does not trust yet. The correct fix is to obtain the key over an authenticated channel and install it scoped to that repository; the incorrect fix, seen in far too many install guides, is to disable verification. - **Expired key** — signing keys have lifetimes; distributions rotate them and ship the successor in advance through the normal update path. A host that has not updated in a long time can end up unable to update because it lacks the new key, which is a bootstrap problem worth planning for on long-lived images. - **Expired index** — the `Valid-Until` case above, or a mirror that has stopped syncing. - **Digest mismatch** — the index and the artifact disagree, which usually means a partial mirror sync or a caching proxy serving stale content, and occasionally something worse.
- Why are individual .deb files usually not signed, and what does that imply for distributing one by hand?Because the trust chain is anchored in the signed repository index: the index carries each package's digest, so a package downloaded through the repository is already authenticated. A `.deb` handed over out of band is detached from that chain and carries nothing verifiable, which is why hand-distributed packages should be published to a signed internal repository instead.
- What attack does the Valid-Until field in a Release file defend against?A freeze or replay attack. An adversary who can only withhold traffic — a hostile mirror or a network position — could keep serving a correctly signed but old index so hosts never see security updates. Expiry bounds how long a stale but valid snapshot is accepted, so the client eventually refuses rather than believing it is up to date.
- A vendor's install instructions tell you to disable GPG checking to get their package installed. How do you respond?Treat it as a defect in their instructions. The correct path is to obtain their signing key over an authenticated channel and scope it to their repository, so their packages are verified and their key vouches for nothing else. Disabling verification removes the check for every package from that repository permanently, usually on exactly the hosts that matter.
saying these in an interview costs you the question
- Believing HTTPS on the mirror replaces package signing
- Thinking a signature proves the software is safe
- Disabling verification to work around a missing key
- Assuming every .deb file is individually signed
- Adding a vendor key globally so it vouches for all repositories