How To: 'apt-key' is deprecated, here's how to fix it

Linux Distributions Debian
1

Note: While you see me talk a lot about Ubuntu in this topic, APT is actually a Debian utility. For that reason, this topic lives in the Debian category.

Hey everyone,

If you ever had to add a custom 3rd party repository to your APT configuration (like Docker, Kubernetes, Perforce), you’ve probably used apt-key in the process. However, starting at Debian 11 and Ubuntu 20.10, apt-key is now deprecated and it will no longer be available after Debian 11 and Ubuntu 22.04.

apt-key is deprecated because it has a security weakness regarding key signing and trusting.

In this topic, I will show you the new way of adding 3rd party repositories to your APT configuration. Here’s an example of the old approach:

wget -qO - https://package.perforce.com/perforce.pubkey | sudo apt-key add -
sudo echo "deb http://package.perforce.com/apt/ubuntu focal release" > /etc/apt/sources.list.d/perforce.list

You might also have done the second line manually using a text editor, like Jay did in his recent Kubernetes video.

The new way of adding keys is as follows:

wget -qO - https://package.perforce.com/perforce.pubkey | sudo gpg --dearmor -o /usr/share/keyrings/perforce-archive-keyring.gpg
sudo echo "deb [signed-by=/usr/share/keyrings/perforce-archive-keyring.gpg] http://package.perforce.com/apt/ubuntu focal release" > /etc/apt/sources.list.d/perforce.list

So what’s new here? In the old approach, your key gets added to either /etc/apt/trusted.gpg or /etc/apt/trusted.gpg.d. As the name suggest, your key gets trusted, unconditionally, for every repository you have defined. This is bad, because if you add a 3rd party repository, it has the ability to replace packages from the official repositories.

The new approach puts your key inside its own file (in this case perforce-archive-keyring.gpg) so that it will no longer be trusted by every repository by default.
The second change is the addition of [signed-by=/usr/share/keyrings/perforce-archive-keyring.gpg] to your repository file. This indicates that this repository will only be trusted with the exact key you added a step earlier.

A couple of notes on the new approach:

  • Make sure you have the gnupg package installed so that you can use the gpg utility.
  • If the public key you’re downloading is not armored, you will need to slightly modify the first line in the new approach, check out this article which goes more in depth.

That’s it, now you can just continue your usual steps by doing sudo apt update and install your 3rd party programs! And remember, you can already start using this new approach, so you’re not forced to do it later when apt-key is gone!

Cheers,
Jasper

4 Likes
2

Hi Jasper.

Thanks for bringing this up. Everything you state is absolutely right. I stumbled upon this some time ago, and to solve the problem, I actually created a shell script to download and install keys in the preferred way.

The github page and --help option has some explanation and example of use. Hopefully this makes it a lot easier to get the key to the correct format.

Unfortunately, the command add-apt-repository does not include an option to add with a [signed-by=xyz] option, so this part has to be done manually in your sources file.

Hope some of you can use this.

2 Likes
3

Thank you for sharing this, great info!

2 Likes
4

Interesting info. Thanks for sharing.

5

I came across this issue earlier this year when I found the VPN key needed updating and it would not accept the new key in the normal way. I tried all the standard ways and variations that I found on-line but nothing worked. (If you read the articles they mentioned the difference between ascii and binary keys and the issues you can come across.) I also found the fact that apt-key was deprecated but everybody still appeared to be using it. In my case the easiest way was to reinstall the application with the latest version and that solved the problem. However if you check your installation you will probably find everything is still in the deprecated key location so there’s a lot of catching up to take place.

From a security position this change is a necessity.

6

I think the issue here will be how long things generally take to be deprecated. If I read that correctly, Ubuntu will deprecate it after the next LTS release, and considering that release will be supported for up to 5 years on servers after it makes its debut, it will be quite a long time until we stop seeing apt-key.

7

Another thing is if people upgrade to the next versions how will they get those keys moved. From what I read there is no automatic way of doing it at present. I would imagine many will just try to uninstall and re-install but that could have consequences for anything encrypted, etc.

8

Very few people prune their keys, unfortunately.

9

One of the issues is peoples lax attitudes to security. It’s even amongst some IT personnel. They want security without anything that slows them down or put a further burden on them. (That’s probably one of the reasons why very few people use TFA, (two factor authentication), or use a good password manager so they can have multiple, long, not easily remembered passwords and only need to remember the passwords manager password with hopefully TFA. Long term FIDO or similar is the way to go, but though the keys/dongles are going down in price I think it needs to go further before the general public takes it on board.)