[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: apt-key says deprecated, but not saying what else to use



On 20.06.21 14:11, 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.

Thanks a lot, this is quite helpful information!

I now understand that these gpg keys in the /etc/apt/trusted.gpg.d/ sub-directory are managed by apt after simply having placed manually the files there, each file containing a binary formatted key. These keys are automatically trusted by apt and hence the "trusted.gpg.d" label for that sub-directory. Keys at this location are not related to the openPGP key management which as a user is usually done with the explicit use of the gpg command. Because of apt internally managing these keys and these keys not intended to become manipulated manually with the gpg command by the system administrating user, the gpg command --refresh-keys cannot be used as a replacement for the deprecated "apt-key update" command.
Please correct me if I would have got it wrong.
Thanks a lot! Marco.


Reply to: