How Linux Package Managers Verify Downloads with GPG

Linux package managers ensure system security by using GNU Privacy Guard (GPG) keys to verify that software packages and repository metadata originate from trusted sources and have not been altered in transit. By combining asymmetric cryptography with cryptographic hashing, package managers like APT, DNF, and Pacman authenticate the identity of the repository maintainer and validate the exact contents of downloaded files before executing any installation scripts.

The Foundation: Asymmetric Cryptography

The verification process relies on public-key cryptography, which utilizes a key pair consisting of a private key and a public key.

• Private Key: Maintained strictly by the software distributor or distribution maintainers, this key generates digital signatures for repositories, manifests, or individual packages.
• Public Key: Distributed openly to users and pre-installed or imported into the local operating system, this key verifies the signatures generated by the corresponding private key.

Because a signature created with a private key can only be validated with its corresponding public key, any successful verification confirms that the content was signed by the legitimate key holder.

The Two Verification Models

Different Linux distributions implement GPG verification at distinct levels of the packaging pipeline:

1. Signed Metadata and Checksums (Debian, Ubuntu / APT)

Debian-based systems verify packages indirectly through repository metadata.

• Signed Manifest: The repository provides a central manifest file (such as InRelease or Release accompanied by Release.gpg) containing the SHA-256 hashes of all available packages. This manifest is digitally signed using the repository's private GPG key.
• Metadata Validation: When you run an update command, APT downloads the manifest and uses the locally stored public key to verify the digital signature.
• Checksum Matching: When a package is downloaded, APT calculates its local SHA-256 hash and compares it to the trusted hash listed in the verified manifest. If the hashes match, the package is proven to be authentic and untampered with.

2. Direct Package Signing (RHEL, Fedora / RPM, DNF)

Red Hat-based systems embed digital signatures directly into the package files (.rpm).

• Embedded Signatures: Maintainers sign the payload and header of the RPM file itself.
• Per-Package Verification: When DNF or YUM downloads an RPM file, it extracts the signature from the package header and verifies it directly against the imported GPG public keys stored in the RPM database (/etc/pki/rpm-gpg/).

Step-by-Step Verification Workflow

1. Key Distribution: The user imports the repository's GPG public key, typically stored in dedicated directories such as /etc/apt/keyrings/ for APT or /etc/pki/rpm-gpg/ for RPM-based systems.
2. Download: The package manager fetches the requested packages along with their associated signature files or manifests over HTTP/HTTPS.
3. Signature Check: The package manager calls the cryptographic subsystem to decrypt the signature using the stored public key. If the signature matches the content, the origin is confirmed.
4. Integrity Check: The package manager computes cryptographic hashes of the local files and checks them against the signed records.
5. Execution or Abort: If the signature is invalid, expired, or untrusted, or if the file hash does not match, the package manager halts the installation immediately, displaying an integrity error (such as BADSIG or untrusted package warnings) to prevent compromised software from executing on the system.