Bug#968148: apt: please document replacement for 'apt-key list'

[Piotr Engelking]

Package: apt
Version: 2.1.8
Severity: wishlist

Running the 'apt key list' command gives the following information:

Warning: apt-key is deprecated. Manage keyring files in
trusted.gpg.d instead (see apt-key(8)).

Neither the manpage nor other documentation suggests what to replace
the command with. Please document it.

The command is useful for configuring sources.list and for debugging
repository signing problems.


-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (800, 'testing'), (700, 'unstable'), (600, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt depends on:
ii adduser 3.118
ii debian-archive-keyring 2019.1
ii gpgv 2.2.20-1
ii libapt-pkg6.0 2.1.8
ii libc6 2.31-2
ii libgcc-s1 10.1.0-6
ii libgnutls30 3.6.14-2+b1
ii libseccomp2 2.4.3-1+b1
ii libstdc++6 10.1.0-6
ii libsystemd0 246-2

Versions of packages apt recommends:
ii ca-certificates 20200601

Versions of packages apt suggests:
ii apt-doc 2.1.8
pn aptitude | synaptic | wajig <none>
ii dpkg-dev 1.20.5
ii gnupg 2.2.20-1
pn powermgmt-base <none>

-- no debconf information

[Julian Andres Klode]

Control: severity -1 minor

Post by Piotr Engelking
Package: apt
Version: 2.1.8
Severity: wishlist
Warning: apt-key is deprecated. Manage keyring files in
trusted.gpg.d instead (see apt-key(8)).
Neither the manpage nor other documentation suggests what to replace
the command with. Please document it.

There is no replacement. Plans need to be made at some point, though
you can arguably just run gpg on the keyring files, like this:

gpg --no-default-keyring --keyring /etc/apt/trusted.gpg.d/steam.gpg --list-key

Adding the deprecation messages now is more important than figuring out how
to replace the commands. It's 2020 and people are still using apt-key when
they should not be - a lot of apt-key adv or apt-key add commands are still
floating around.

I want to get a clear message out that apt-key is deprecated, and people should
stop using it. How we deal with the list use case is a different topic.

I also need to add a deprecation notice to apt update if a repository
was signed with a key from trusted.gpg instead of trusted.gpg.d, so we
can completely stop using trusted.gpg once bullseye (and Ubuntu 22.04) is
released, at which point all apt-key add use will naturally break :)

[Vincent van Adrighem]

Package: apt
Followup-For: Bug #968148

Dear Maintainer,

Replacing the command is not what we want to achieve here, but a few
changes in the documentation would go a long way in resolving this.

Post by Piotr Engelking
Warning: apt-key is deprecated. Manage keyring files in
trusted.gpg.d instead (see apt-key(8)).
Warning: apt-key is deprecated. Keys can simply be downloaded and
managed separately in the trusted.gpg.d directory instead using
standard file management tools (see apt-key(8)).
Use of apt-key is deprecated, except for the use of apt-key del in maintainer scripts to remove existing keys from the main
keyring. If such usage of apt-key is desired the additional installation of the GNU Privacy Guard suite (packaged in gnupg) is
required.
Use of apt-key is deprecated, except for the use of apt-key del in maintainer scripts to remove existing keys from the main
keyring. If such usage of apt-key is desired the additional installation of the GNU Privacy Guard suite (packaged in gnupg) is
required.
New keys can be managed separately in the trusted.gpg.d directory instead using
standard file management tools (see apt-key(8)).
A replacement for "sudo apt-key add -" would be "sudo tee
/etc/apt/trusted.gpg.d/keyname.gpg"

Those last two lines are a nice addition because
apt-key add examples float around a lot on the web.

Thanks for maintaining the package. Hope this helps to resolve the
issue people have.

-- System Information:
Debian Release: bullseye/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

[Julian Gilbey]

Post by Piotr Engelking
Package: apt
Followup-For: Bug #968148
Dear Maintainer,
Replacing the command is not what we want to achieve here, but a few
changes in the documentation would go a long way in resolving this.

Dear Maintainers,

I'd like to second this: I wanted to add a local key, and could not
find out how to do so now that apt-key is deprecated. I looked in
apt-secure(8), but the /etc/apt/trusted.gpg.d/ directory is not even
mentioned.

In the end, with some web searching, the only reference I found to the
"correct" way to do it was this bug report!

Please do update the manpages for apt-key and apt-secure in the way
that Vincent has suggested - ideally, in time for the bullseye freeze,
so that it is in the upcoming Debian stable. This makes it obvious
what to do instead of using apt-key: "just add/remove GPG keys to/from
the directory /etc/apt/trusted.gpg.d as desired".

Best wishes,

Julian

[Julian Gilbey]

Post by Julian Gilbey

Post by Piotr Engelking
Package: apt
Followup-For: Bug #968148
Dear Maintainer,
Replacing the command is not what we want to achieve here, but a few
changes in the documentation would go a long way in resolving this.

Dear Maintainers,
I'd like to second this: I wanted to add a local key, and could not
find out how to do so now that apt-key is deprecated. I looked in
apt-secure(8), but the /etc/apt/trusted.gpg.d/ directory is not even
mentioned.
In the end, with some web searching, the only reference I found to the
"correct" way to do it was this bug report!
Please do update the manpages for apt-key and apt-secure in the way
that Vincent has suggested - ideally, in time for the bullseye freeze,
so that it is in the upcoming Debian stable. This makes it obvious
what to do instead of using apt-key: "just add/remove GPG keys to/from
the directory /etc/apt/trusted.gpg.d as desired".
Best wishes,
Julian

Dear maintainers,

I just stumbled upon an "Ask Ubuntu" discussion, which has a very
clear explanation of (at least some of) the reasons for the
deprecation of apt-key and what to do instead:
https://askubuntu.com/questions/1286545/what-commands-exactly-should-replace-the-deprecated-apt-key/1300076#1300076

Logging it here in the hope that it will be of use to others.

Best wishes,

Julian

[David Kalnischkies]

Hi,

Post by Julian Gilbey
I just stumbled upon an "Ask Ubuntu" discussion, which has a very
clear explanation of (at least some of) the reasons for the
https://askubuntu.com/questions/1286545/what-commands-exactly-should-replace-the-deprecated-apt-key/1300076#1300076
Logging it here in the hope that it will be of use to others.

It's Julian (juliank) who runs this deprecation and I have close to zero
interest in third party repositories, so I do not want to bud in on
these BUT that linked accepted answer is really not a good answer

at least scroll a bit down and read the others if you really must.


In my opinion this isn't something a user has to concern itself with
though. The 3rd party repository has to explain how it can be added and
incidently that will be and always was at least slightly different for
all of them as they are all slightly different in what they provide and
how (flat vs. dists repo, binary or ascii key, keyring package or not,
name of components, pinning, 
). If a repository has no documentation on
how to properly use it, I at least wouldn't dare to use it
 (but I don't
use any, so there is that
).

See e.g. https://wiki.debian.org/DebianRepository/UseThirdParty

That wiki page says APT isn't supporting ASCII armored keys, but it does
nowadays – but as this isn't universally true for all apt versions still
in existence/use it's fine for now to pretend otherwise I guess.


So, not saying that is a good idea, but to achieve what the accepted
answer does without the potential failure modes this has (thanks to
particularities with the invocation of gnupg in different versions –
which might not even be installed but would need to be for apt-key):

$ sudo /usr/lib/apt/apt-helper download-file 'https://download.teamviewer.com/download/linux/signature/TeamViewer2017.asc' /etc/apt/trusted.gpg.d/teamviewer.asc

No, I haven't tried it. This is also not an endorsement of that repo,
that key or adding it to trusted.gpg.d directly. Using apt-helper as
I know that is available while wget/curl/whatever might not. Not that
I wouldn't recommend that either – and please don't ask me for some as
the only I am comfortable giving is "Don't use 3rd party repos" and that
is probably not what anyone reading this wants to hear



Best regards

David Kalnischkies

[Julian Gilbey]

Post by David Kalnischkies
Hi,

Post by Julian Gilbey
I just stumbled upon an "Ask Ubuntu" discussion, which has a very
clear explanation of (at least some of) the reasons for the
https://askubuntu.com/questions/1286545/what-commands-exactly-should-replace-the-deprecated-apt-key/1300076#1300076
Logging it here in the hope that it will be of use to others.

It's Julian (juliank) who runs this deprecation and I have close to zero
interest in third party repositories, so I do not want to bud in on
these BUT that linked accepted answer is really not a good answer…
at least scroll a bit down and read the others if you really must.
[... detailed comments and ideas snipped ...]
Best regards
David Kalnischkies

Hi David,

That's really helpful, thanks!

What seems to come from your answer is that there is no "canonical"
way to do it. But in the absence of guidance, each person setting up
their own repository will do it in their own way. I had no idea of
the potential dangers of the /etc/apt/trusted.gpg.d directory, for
example, though I'm not sure that using signed-by is necessarily
better.

What would be helpful, and what this whole thread is essentially
about, is a request for the apt maintainers, who really know the
architecture of the apt system and are probably the best-placed to
give this guidance, to provide some "official" guidelines as to best
practice in the apt packages. From your message, it seems as though
there are actually two distinct audiences: repository maintainers and
sysadmins.

Something like:

Guidelines for setting up a signed package repository
-----------------------------------------------------

Modern versions of APT require repositories to be signed. If you are
setting up a repository, you can read about signing your repository
here: [URL].

If you intend your repository to be usable by others, you will need to
provide your public key in a format that APT can use. This can be
achieved in three ways:

(1) (Recommended method) Using GPG, turn your key into a GPG v1
keyring as follows: ...

(2) Using ...

(3) Using ...

If this key is saved as /etc/apt/keyrings/myrepo.gpg, the repository
can then be accessed using a sources.list line such as:
deb [signed-by=/etc/apt/keyrings/myrepo.gpg] https://example.com/myrepo repo main


Guidelines for sysadmins to add an external package repository
--------------------------------------------------------------

Security warning: Adding external repositories can be dangerous, as
they can potentially install malicious software in place of the
official Debian versions. Only add external repositories from sources
that you trust.

In general, external repositories should provide instructions for how
to add them to your system. We just give some brief pointers here.

[... I don't know what the correct thing to write here is ...]


I hope this is of some help!

Best wishes,

Julian

[Julian Andres Klode]

Post by Julian Gilbey

Post by David Kalnischkies
Hi,

Post by Julian Gilbey
I just stumbled upon an "Ask Ubuntu" discussion, which has a very
clear explanation of (at least some of) the reasons for the
https://askubuntu.com/questions/1286545/what-commands-exactly-should-replace-the-deprecated-apt-key/1300076#1300076
Logging it here in the hope that it will be of use to others.

It's Julian (juliank) who runs this deprecation and I have close to zero
interest in third party repositories, so I do not want to bud in on
these BUT that linked accepted answer is really not a good answer…
at least scroll a bit down and read the others if you really must.
[... detailed comments and ideas snipped ...]
Best regards
David Kalnischkies

Hi David,
That's really helpful, thanks!
What seems to come from your answer is that there is no "canonical"
way to do it. But in the absence of guidance, each person setting up
their own repository will do it in their own way. I had no idea of
the potential dangers of the /etc/apt/trusted.gpg.d directory, for
example, though I'm not sure that using signed-by is necessarily
better.
What would be helpful, and what this whole thread is essentially
about, is a request for the apt maintainers, who really know the
architecture of the apt system and are probably the best-placed to
give this guidance, to provide some "official" guidelines as to best
practice in the apt packages. From your message, it seems as though
there are actually two distinct audiences: repository maintainers and
sysadmins.

Best practice will be to embed the key into a deb822 sources file, but
that's for bookworm+ and doesn't help much yet.

As of now, there are no best practices. I just drop files into
trusted.gpg.d, others drop them into /usr/[local/]share/keyrings and use
signed-by.

Hence I don't want to commit to anything too concrete yet, either way.