add-apt-key

Since add-apt-key is not a command, here's the synopsis for the apt-key add subcommand, which it commonly refers to:

apt-key add <filename>
apt-key add -

<filename>
    The path to the GPG ASCII armored public key file to add to the trusted keyring.

-
    Instructs apt-key to read the key from standard input (stdin). This is common when piping the output of a command like curl or wget.

The term add-apt-key is a common phrase used by Linux users to describe the process of adding a GPG (GNU Privacy Guard) public key to APT's (Advanced Package Tool) trusted keyring.

It is important to note that add-apt-key is not a standalone command in Linux. Instead, users typically refer to actions performed using the apt-key utility, or more recently, a series of commands involving curl or wget and gpg.

Historically, and still commonly, users would use apt-key add to import a GPG key, typically provided by a third-party software repository. This key allows APT to verify the authenticity of packages downloaded from that repository, ensuring they have not been tampered with.

However, the apt-key utility is officially deprecated due to security concerns, as it places all added keys into a single, global trust store. If one of these keys were ever compromised, it could potentially affect the integrity of packages from all other repositories. Modern Linux distributions and APT versions encourage a more granular, per-repository key management approach, often involving placing de-armored keyrings in specific directories like /etc/apt/keyrings/ and referencing them directly in /etc/apt/sources.list.d/ entries using the signed-by option.

• add-apt-key is not a real command; it's a conceptual term.
• The apt-key utility is considered deprecated and its use is discouraged in modern Debian-based systems (e.g., Ubuntu 20.04+).
• Adding keys via apt-key places them into a global trust store (/etc/apt/trusted.gpg or /etc/apt/trusted.gpg.d/). This centralizes trust, meaning if any single key in this store is compromised, it could undermine the security of all your APT repositories.
• For enhanced security and better maintainability, adopt the modern approach of using signed-by in your sources.list entries with keys stored in dedicated keyring directories (e.g., /etc/apt/keyrings/).

For modern and more secure APT key management, avoid apt-key. Instead, download the GPG key, de-armor it, and place it directly into a dedicated keyring directory (e.g., /etc/apt/keyrings/). Then, reference this specific keyring file in your repository's .list file (e.g., in /etc/apt/sources.list.d/) using the signed-by option.

Example of Modern Key Addition:
1. Download and de-armor the key:
curl -fsSL https://example.com/example_repo_key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/example-archive-keyring.gpg

2. Add or modify your repository entry (e.g., /etc/apt/sources.list.d/example.list) to reference the new keyring:
deb [arch=amd64 signed-by=/etc/apt/keyrings/example-archive-keyring.gpg] https://example.com/repo stable main

This method ensures that the key's trust is scoped only to the specific repository it belongs to, improving security and clarity.

The concept of managing APT's trusted keys has evolved significantly. The apt-key utility has been a part of the APT ecosystem for many years, serving as the primary method to add external GPG keys for repository verification. Its design, which involved adding keys to a global keyring, was sufficient for earlier times. However, with increased focus on supply chain security and the desire for more granular control over trusted sources, its limitations became apparent. Debian and Ubuntu, as maintainers of APT, began to actively discourage the use of apt-key starting around their 20.04 LTS and 22.04 LTS releases, promoting the more secure and explicit signed-by option in sources.list entries.

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