On Sunday 20 June 2021 08:11:45 Darac Marjal wrote: > On 19/06/2021 21:07, Marco Möller wrote: > > Hello, > > Command apt-key and its man page say that apt-key is deprecated, but > > do not suggest an instead recommended tool. It is only mentioned > > that keys would now be organized in /etc/apt/trusted.gpg.d/ . But > > how should I manage the keys saved there, for instance how to update > > them, or what tool of the Debian distribution is managing them there > > for the apt functionality of the Debian OS? > > Guiding me to a properly up-to-date documentation about this topic > > would be welcome! > > Marco. > > For some time, I've been using /etc/apt/trusted.gpg.d rather than > using apt-key. As I understand it, keys in apt-key are trusted to sign > *any* repository you pull from. That is, if you add a suspicious > repository and somehow they were able to push packages signed with > their key to the main debian repo servers, then you'd not be able to > distinguish between "signed by Debian" and "signed by attacker". > > Instead, the preferred method is to put binary GPG keys into > /etc/apt/trusted.gpg.d (that is, you might need to run "gpg --dearmor" > if you download an ascii-armoured key). Files there can have any name > it's purely up to the system administrator what the names are, but it > makes sense that they indicate the repository they sign. Then, in > /etc/apt/sources.list.d/*.list, you need to write: > > deb [signed-by=/etc/apt/trusted.gpg.d/somekey.gpg] > https://repo.attacker.com/ stable main > > Now, only this repository trusts that key. If packages there are > signed by another key, verification fails. Similarly, if packages in > another repository are signed by that key, verification fails. > > You ask about updating them. There is, as far as I know, no automatic > method for updating these keys, nor for automatically adding them > right now. That's because it's generally considered good practice to > add the key manually. You need to actively state that you trust this > repository on your system. So, for most repositories, that involves a > web page somewhere that says "This is our 'deb ... ' line and this is > a link to our public key." The key will usually be valid for several > years, but if it does start to fail, apt tools *will* tell you that > the key has expired, and that's time to go back and revisit the > original site, and see if they have a new key available.
I'd like to pleaed for a new apt-key, one that would survey the existing list, and on finding a key that is expired or is no longer associated, offer the option of removing it, or refreshiing it. I have up to 7 machines on my local network, usually accessed by some ssh/sshfs variation, but my current keyring since I'm first user, probably has 30 some keys, many of which are useless as the target machine has been changed by a new machine and a new bare metal install. I consider those "dead" keys to be security risks. But at present, there is not a means to identify and remove them that I am aware of. So I would plead for an apt-key replacement that would automate that process. At the present state, my connection scripts to re-establlish my local network after a reboot or power failure recovery, are all blocked because of machine replacements/reinstalls using the same ip address yadda yadda, so I must answer yes, then supply my first user password for that machine because I do want to continue connecting to that machine. That can rapidly turn into a PITA. Thanks for this thread. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>