Safeguard
Developer Tools•

Adding a third-party apt repository safely with signed-by

Store a repository key in its own file and point signed-by at it, not the global trust store. Steps for Debian and Ubuntu, with pinning and key rollover.

Safeguard Security Team
3 min read

Put the third-party repository's key in its own keyring file, and reference that file with signed-by in the source entry. Do not drop the key into the global trust directory or use apt-key add. A key trusted globally can vouch for packages from any repository, including your official one.

Why the global key is a problem

The Debian wiki guidance on third-party repositories is direct: the certificate must not be placed in the trusted.gpg.d directory or loaded with apt-key add. The reason is scope. A key in the global store is trusted for every repository without a signed-by setting. A compromised third party could then sign a malicious update to a package that normally comes from your distribution.

Step by step

  1. Download the repository's key over HTTPS to a location only root can write. Debian's guidance describes a binary, dearmored OpenPGP certificate file.
  2. If the key is ASCII armored, convert it with gpg --dearmor or the sq packet dearmor command.
  3. Store the file. Debian says to use /usr/share/keyrings if a package will manage future key updates, and /etc/apt/keyrings if you will manage the key yourself. On releases older than Debian 12 and Ubuntu 22.04, you may need to create the keyrings directory with mode 0755.
  4. Create a file in /etc/apt/sources.list.d, either a list file or a Deb822 sources file, and set signed-by to the path of the key file.

An example one line entry looks like this, where you replace the names with the repository's own:

deb [signed-by=/etc/apt/keyrings/vendor.gpg] https://repo.example.com/apt stable main

Debian is explicit that signed-by must point to a file, not a fingerprint, because a fingerprint would add the key to the global store.

Pin it

Debian recommends a preferences file in /etc/apt/preferences.d that pins by origin hostname. Use priority 100 to allow upgrades from that origin, or 1 to block automatic upgrades, and never a higher value. Pinning stops the third party from silently replacing system packages. Note that origin pinning cannot tell apart several repositories on the same host.

Plan for key rollover

Keys expire or get rotated. Debian suggests shipping the key in a keyring package, installed under /usr/share/keyrings, with the pin allowing that package to upgrade. If you publish a repository, do this for your users.

Publisher side

Sign the repository metadata, document the key fingerprint on your site, and rotate with notice. Our piece on checksum versus signature explains why the fingerprint should be published somewhere other than the download itself.

Checking your existing machines

Audit what is trusted today. Look at the global trusted keys directory and any keys loaded with the old tool, and list which repositories rely on them. For each, move the key into a dedicated file and add the signed-by setting, then run an update to confirm apt still accepts the repository. Remove repositories nobody can explain. It is a small clean-up that shrinks the set of parties who can push code to your servers.

Quick check

Is apt-key add still fine on older systems?

Debian's guidance says not to load keys that way. Use a dedicated keyring file and signed-by.

Can I use a fingerprint in signed-by?

Debian says signed-by must point to a file, because a fingerprint would add the key to the global trust store.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.