Frequently Asked Question

How does package signing protect against supply-chain attacks?

When apt install nginx or dnf install httpd runs, the package manager does more than fetch a .deb or .rpm from a mirror. It also fetches a small metadata file (InRelease on Debian, repomd.xml.asc on RPM systems) that has been signed by the distribution's release-management GPG key, and refuses to install anything whose hashes do not match the signed metadata. The public keys ship with the distribution in /etc/apt/trusted.gpg.d/ or the RPM keyring, so a tampered mirror cannot serve malicious binaries without the corresponding private key, which lives offline at the distribution.

This is what stops the simplest supply-chain attack: a mirror operator (or a network attacker between you and the mirror) substituting an evil binary. It does not stop every supply-chain attack. CVE-2024-3094, the xz backdoor, is the canonical cautionary tale: a trusted upstream maintainer over two years inserted malicious code into legitimately-signed releases, which then propagated through the distributions' signed channels. No signature scheme catches a compromise that originates upstream of the signers.

For a defender that means: keep package signing enabled (never use apt-get --allow-unauthenticated), pin third-party repositories to a specific key with the Signed-By: directive, prefer official distribution mirrors over random web-hosted binaries, and treat any package that adds a new GPG key as a privileged change worth reviewing.