Keep APT Repository Trust Narrow with apt-secure

Adding a third-party repository is a decision to trust its signing key, and apt-secure is the mechanism that enforces it. This guide shows what APT actually authenticates, how to inspect the keys and sources on your machine, and how to add a repository without making every configured key trusted for it. Allow about 10 minutes for inspection, longer if you must verify a vendor's key fingerprint through a separate trusted channel.

The examples use APT 2.8.3.

1. Check the APT version and source files

Start as your normal user. This is an inspection step and does not need elevated privileges. APT reads the traditional .list files and the newer deb822 .sources files from the configured source directories.

$ apt --version
apt 2.8.3 (amd64)
$ apt-config dump | grep -E '^(Dir::Etc::(sourcelist|sourceparts))'
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
$ find /etc/apt/sources.list.d -maxdepth 1 -type f -print | sort

Checkpoint: identify the file for each repository you mean to keep. A file with an unfamiliar name is not automatically malicious, but it deserves the same provenance check as the repository it configures.

2. Understand the trust boundary

During apt-get update, APT verifies repository metadata such as an InRelease file, or a Release file with its detached Release.gpg signature. The Release metadata contains checksums for package indexes, so a valid chain lets APT detect changes to the indexes and downloaded packages.

• It authenticates the archive, not every package. You are trusting the archive maintainer and the signing key. It does not replace per-package signature tools such as debsig-verify.
• It helps against a tampered mirror or a network attacker. It cannot protect you from a compromised archive signing key or the signing service itself.

Check the keyring files before adding anything:

$ find /usr/share/keyrings /etc/apt/keyrings -maxdepth 1 -type f -readable -print 2>/dev/null | sort
$ apt-key list

The second command may print a deprecation warning on current systems. Do not treat that warning as a reason to disable authentication. Default distribution keyrings are normally already installed; adding a key is generally only needed for a third-party source.

3. Prefer a repository-specific Signed-By keyring

For a vendor repository, obtain its key through a channel whose authenticity you can verify, and confirm the published fingerprint before installing it. Do not copy a placeholder command with an unknown URL into a root shell. The keyring should be readable by the _apt system user. Package-managed keyrings belong in /usr/share/keyrings; operator-managed keyrings belong in /etc/apt/keyrings.

The following is a configuration shape, not a command to run unchanged. Replace every uppercase placeholder after verifying the vendor's instructions and fingerprint:

Types: deb
URIs: https://REPOSITORY.EXAMPLE/
Suites: SUITE_NAME
Components: main
Signed-By: /etc/apt/keyrings/REPOSITORY-ARCHIVE-KEYRING.gpg

Save that stanza as a filename ending in .sources, such as /etc/apt/sources.list.d/REPOSITORY.sources. Writing under /etc/apt needs elevated privileges. The absolute path matters: APT will use the specified keyring for that source rather than treating every trusted key as a possible signer.

Checkpoint: inspect the file before updating:

$ sudo sed -n '1,20p' /etc/apt/sources.list.d/REPOSITORY.sources
$ sudo test -r /etc/apt/keyrings/REPOSITORY-ARCHIVE-KEYRING.gpg && echo 'keyring readable'

4. Run an authenticated update

apt-get update needs elevated privileges because it writes package lists. It contacts every enabled source, so a failure may belong to a repository you did not just add. Read the source name and the exact authentication error before changing configuration.

$ sudo apt-get update
...
Reading package lists... Done

Successful completion means the configured metadata passed the checks APT applied. It does not prove that a newly added vendor is reputable. If APT reports a missing public key, get the key from the repository owner through a trusted channel and compare its fingerprint.

Warning: do not fix a missing-key error by making an unrelated keyring globally trusted.

5. Treat insecure overrides as an emergency exception

Unsigned repositories are refused by default during update operations. APT 2.8.3 recognises Acquire::AllowInsecureRepositories=true and the per-source allow-insecure=yes, but these reduce the protection and are discouraged. Trusted=yes suppresses even warnings and can breach the security boundary.

A repository that was authenticated and then loses authentication is a separate downgrade error. It needs Acquire::AllowDowngradeToInsecureRepositories=true or the per-source equivalent, and should normally be treated as a repository incident instead.

Security warning: do not put these settings into permanent configuration just to make an update go green. If a controlled local archive genuinely needs an exception, scope it to that source, record why, and remove it when the archive is signed.

Recovery: to undo a temporary per-source exception, edit the source file, remove allow-insecure=yes or trusted=yes, then run:

$ sudo apt-get update

6. Investigate changed repository information

APT also protects the meaning of a repository. Changes to fields such as origin, codename or version are shown because preferences and upgrade decisions may depend on them. Since APT 1.5, an information change needs explicit confirmation before updates continue. Stop and verify that the change is expected, especially during a distribution upgrade or after editing a source suite.

Do not blindly approve a prompt that appears after a source edit. Compare the configured URI and suite with the publisher's documentation, then inspect the affected source file. If the change was accidental, restore the previous suite or disable the source and run the update again.

Tip: disabling a deb822 source is reversible. Add Enabled: no, then remove or change that field when the source is ready to return.

Common traps

• Confusing HTTPS with authentication. HTTPS encrypts transport, while apt-secure validates signed repository metadata. You want both where available.
• Confusing a valid signature with safe software. A signature identifies an accepted archive key; it is not a code review.
• Using the wrong file format. One-line entries use .list and square-bracket options. Deb822 stanzas use .sources and fields such as Signed-By:.
• Forgetting the filename rules. Files in sources.list.d need the right extension and a name made from letters, digits, underscores, hyphens and periods, or APT may ignore them.
• Ignoring time checks. Release metadata can expire. Check the machine clock and the mirror before disabling validity checks.

Done means

• Sources known. APT's version and active source files are identified.
• Keys verified. Every third-party source has a key obtained and fingerprint-checked through a trusted channel.
• Trust scoped. Third-party sources use an appropriate Signed-By keyring where practical.
• Update clean. sudo apt-get update completes without unexplained authentication errors.
• No shortcuts left behind. No permanent insecure or globally trusted override was added merely to silence APT.