Skip to main content
Unix & Linux

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

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.) Commented 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. Commented 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. Commented Jun 10, 2021 at 5:09
  • 1
    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! Commented Jun 11, 2021 at 13:08