apt-secure

apt-secure

Note: apt-secure is a documentation page describing APT's security model, not an executable command with runtime options or arguments. Its 'invocation' is typically man apt-secure.

apt-secure describes the security model employed by APT for managing software packages. It explains how APT verifies the authenticity and integrity of packages downloaded from repositories. At its core, this system relies on cryptographic signatures: each repository's Release file (or InRelease) is signed by a GPG key.

APT checks this signature against a keyring of trusted keys. Historically, trusted keys were managed globally in /etc/apt/trusted.gpg and apt-key was used for management. Modern APT, however, emphasizes per-repository trust via the Signed-By option in sources.list(5), pointing to specific keyring files (e.g., in /etc/apt/trusted.gpg.d/).

This mechanism ensures that packages originate from a legitimate source and haven't been tampered with during transmission, protecting the system from malicious or corrupted software. If a signature verification fails, APT will refuse to install or upgrade packages from that source, issuing a warning.

The apt-key(8) command, especially apt-key add, is largely deprecated due to its global trust model. Modern practice dictates using the Signed-By option in sources.list(5) entries to specify per-repository keyrings.
Adding untrusted or unknown GPG keys to your system can severely compromise its security, as it allows APT to implicitly trust any package signed by that key, regardless of its origin.
Always ensure that the key used to sign a repository is obtained from a secure and trusted source.

While apt-secure is a documentation page, understanding its principles is crucial for managing external repositories securely.
When adding a new repository (e.g., a PPA), you typically download its GPG key and place it in a dedicated keyring file within /etc/apt/trusted.gpg.d/.
Then, in your sources.list file or a new .list file in /etc/apt/sources.list.d/, you specify the repository URL along with the Signed-By option pointing to the keyring file you just added.
For example:
deb [signed-by=/usr/share/keyrings/myrepo-archive-keyring.gpg] https://example.com/debian stable main
This ensures APT only trusts packages from example.com if they are signed by the key in myrepo-archive-keyring.gpg, rather than globally trusting it.

Initially, APT's security relied on a single, globally trusted keyring. Users would typically add repository keys using apt-key add. This approach, while simple, had a significant drawback: adding a key granted trust to all repositories signed by it, making it difficult to manage granular trust.

Over time, the need for more isolated and explicit trust management grew. The Signed-By option was introduced in sources.list(5) entries, allowing administrators to specify the exact keyring file (often placed in /etc/apt/trusted.gpg.d/) that should be used to verify a particular repository. This significantly improved security by limiting the scope of trust. Consequently, the apt-key command's add functionality was deprecated in favor of manual key management within /etc/apt/trusted.gpg.d/ combined with the Signed-By directive. The InRelease file format was also introduced to combine the Release file and its signature into a single download, improving efficiency.

apt(8), sources.list(5), apt-key(8), gpg(1)