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.
Control: severity -1 minor 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 :)
Control: severity -1 minor 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 :)
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. Maybe changing the text from: And in the apt-key man-page: 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.
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
Hi, 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
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
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.
Thanks Julian - that's a really helpful explanation of the situation. Best wishes, Julian