Re: apt-key says deprecated, but not saying what else to use
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>
Reply to: