1

I want to use the signed-by option on all the repositories of my /etc/apt/sources.list.d/debian.sources, point to the keys in /usr/share/keyrings instead of /etc/apt/trusted.gpg.d before disabling this directory, as I have understood, this old way of doing is insecure. I don't know if this only apply to third-party repositories but better be safe than sorry.

However, when adding the signed-by option, I found myself unable to know which key to link to which repo, seeing that the key's names don't match the repos:

debian-archive-bullseye-automatic.gpg
debian-archive-bullseye-security-automatic.gpg
debian-archive-bullseye-stable.gpg
debian-archive-buster-automatic.gpg
debian-archive-buster-security-automatic.gpg
debian-archive-buster-stable.gpg
debian-archive-keyring.gpg
debian-archive-removed-keys.gpg
debian-archive-stretch-automatic.gpg
debian-archive-stretch-security-automatic.gpg
debian-archive-stretch-stable.gpg

My /etc/apt/sources.list.d/debian.sources looking like this:

Types: deb
URIs: https://deb.debian.org/debian/
Suites: buster
Components: main
Signed-By: /usr/share/keyrings/debian-archive-buster-stable.gpg

Types: deb-src
URIs: https://deb.debian.org/debian/
Suites: buster
Components: main
Signed-By: /usr/share/keyrings/debian-archive-buster-stable.gpg

Types: deb
URIs: https://security.debian.org/debian-security
Suites: buster/updates
Components: main
Signed-By: /usr/share/keyrings/debian-archive-buster-security-automatic.gpg

Types: deb-src
URIs: https://security.debian.org/debian-security
Suites: buster/updates
Components: main
Signed-By: /usr/share/keyrings/debian-archive-buster-security-automatic.gpg

Types: deb
URIs: https://deb.debian.org/debian/
Suites: buster-updates
Components: main
Signed-By: /usr/share/keyrings/debian-archive-buster-automatic.gpg

Types: deb-src
URIs: https://deb.debian.org/debian/
Suites: buster-updates
Components: main
Signed-By: /usr/share/keyrings/debian-archive-buster-automatic.gpg

Types: deb
URIs: https://deb.debian.org/debian
Suites: buster-backports
Components: main
Signed-By: /usr/share/keyrings/debian-archive-buster-automatic.gpg

This doesn't throw me any error when doing apt update and I can install software but I would like to know a method to know for sure which key I should append to the signed-by option for each repo without having to do guesswork, and be left with doubts.

I know of apt-key list but the information are pretty much the same, how does "Debian Security Archive Automatic Signing Key" is supposed to tell us that it signs buster-updates AND buster-backports? Is it normal that one key can sign multiple suites? I would have expected one key per suite.

Also, the opposite: how do I know what a key signs? How do I know I don't have useless keys in /usr/share/keyrings or that they are signing malicious repositories?

1 Answer 1

3

For context, current best practices for third-party repositories are documented in the Debian wiki page on third-party repository usage and in this “How to properly use 3rd party Debian repository signing keys with apt” blog post. Eventually they should be extended to Debian’s own repositories, see this issue for example.

Assuming you trust your current setup, you can map signed archive release files to keys by listing the keys used to sign them; for example:

$ gpgv /var/lib/apt/lists/security.debian.org_dists_buster_updates_InRelease
gpgv: Signature made Mon 07 Jun 2021 23:03:07 CEST
gpgv:                using RSA key 379483D8B60160B155B372DDAA8E81B4331F7F50
gpgv: Can't check signature: No public key
gpgv: Signature made Mon 07 Jun 2021 23:03:07 CEST
gpgv:                using RSA key 5237CEEEF212F3D51C74ABE0112695A0E562B32A
gpgv: Can't check signature: No public key

shows that the Debian 10 security updates are signed by RSA keys 379483D8B60160B155B372DDAA8E81B4331F7F50 and 5237CEEEF212F3D51C74ABE0112695A0E562B32A. These are respectively “Debian Security Archive Automatic Signing Key (9/stretch)” and “Debian Security Archive Automatic Signing Key (10/buster)”. To determine that, look at the individual keyrings in /usr/share/keyrings, with a command such as for file in /usr/share/keyrings/*.gpg; do echo $file; gpg --list-keys --no-default-keyring --with-subkey-fingerprint --keyring $file; done.

This isn’t ideal; for more authoritative usage information, you can apply the following rules:

  • “stable” keys (e.g. “Debian Stable Release Key (10/buster)”) are used with the corresponding stable repositories;
  • automatic keys are used as described in their announcement emails, e.g. the Buster keys and the Bullseye keys.

Repository indexes are often signed by two keys to allow for some overlap.

You shouldn’t care about individual files under /usr/share/keyrings, but rather about packages providing files there (and of course, files which aren’t provided by a package). However the map described above also works to find keys which are no longer used in your setup.

Starting with APT 2.4, it will be possible to specify signing keys in .sources snippets, e.g.

URIs: https://deb.debian.org
Suites: stable
Components: main contrib non-free
Signed-By:
 -----BEGIN PGP PUBLIC KEY BLOCK-----
...
 -----END PGP PUBLIC KEY BLOCK-----
4
  • Then I have a problem because, after comparing the ID, I found out that only one ID out of the five signing the four release files matches one from the eleven keys I have in /usr/share/keyrings. See pastebin.com/GBD2rBFC (I put a OK next to the single match.)
    – Some_user
    Jun 9, 2021 at 23:16
  • After further research, I found that I could check a signature against a key with gpg --no-default-keyring --keyring /usr/share/keyrings/debian-archive-buster-security-automatic.gpg --verify /var/lib/apt/lists/security.debian.org_debian-security_dists_buster_updates_InRelease. It showed me that the subkey was the one which matched, not the primary one. As I understand, primary keys are used for en/decrypting messages and subkeys for signing. Which means that to find the right fingerprints, you had to add the --with-subkey-fingerprint to your command.
    – Some_user
    Jun 10, 2021 at 4:55
  • After verification, I found that all my release files were signed using those subkeys except the one corresponding to the third fingerprint for the stable repository. pastebin.com/3LiW7jf6 You will see that every release file is signed by one subkey from Stretch and one from Buster. Phew, that was hard! Edit your answer if you want me to accept it (or I do it later). Thanks for your help nonetheless, that put me in the right direction and it was very interesting.
    – Some_user
    Jun 10, 2021 at 5:09
  • That’s odd, my gpg lists subkeys even without that option (which is how I was able to match things up). I’ve added it to my answer! Jun 11, 2021 at 13:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .