Key is stored in legacy trusted.gpg keyring

Reading Time: 3 minutes

Last Edited: 8/28/2022

This one started to get to me. Today is the day I decided to learn a little more about it.

The King is dead. Long live the King. This is more of a case of changing and adapting with the times. It’s also a lesson as to why you should closely review dated articles – so as not to fall into the trap of using or implementing things with outdated methods or by using insecure means. This is going to talk about a (nearly) fictitious example – but you should be able to pick up why the old method is being deprecated.

In a simple example, let’s say I have a deployment that is using elasticsearch. And let’s say at the time we installed elastic search (version 7) everything was fine. (version 8?) is out now. One day you go to update your repositories and BAM! You start to see funny messages. indicating that they are deprecating the legacy “trusted.gpg” keyring. Let’s examine what this means. And please I am not picking on anyone per see in my examples…. I am just laying the facts out. You see:

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
2 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: https://artifacts.elastic.co/packages/7.x/apt/dists/stable/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
W: https://artifacts.elastic.co/packages/oss-7.x/apt/dists/stable/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

As of this writing 8/28/2022 the fine folks of Digital Ocean still have a URL which demonstrates installing the keys. I like Digital Ocean’s Documentation – and I assume it (the URL) is left for historical reasons. On the plus side the guidance does show how we got to where we are. It’s also a reason why you should ask examine the dates of your sources very carefully. (Yes I will pick on news websites as well) It’s surprising and frustrating sometimes when this is not done. Back to our example, it was stated:

curl -fsSL https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -

This is now… bad advice. BTW, if you do that now you will see:

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@node5:/etc/apt# curl -fsSL https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
OK

Let’s call this a clue. This is to let you know that you just used “apt-key”. The problem is that the key was probably just stored in “/etc/apt/trusted.gpg”. As I am given to understand the system is going to trust this key. The problem? The system is going to trust that key. My understanding is that the system doesn’t differentiate. So once you have placed the key in the systems trusted.gpg it is well… trusted. For all things. That creates overlap and you can see where that might be a problem.

The more current way is.

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg

Now it took me writing this article to figure out what was going on here. Really understand it. So let’s unpack this. The first part of the wget is going to go get a file and on the fly we are gong to pipe it in to gpg and -dearmour it. In short the stored file “GPG-KEY-elasticsearch” is a ASCII representation of binary data. We are going to pull it down and store the binary data which is the KEY in /usr/share/keyrings. This means you might really want to think if this is where you want to store this key. The security, the attribution, comes from a coresponding change in the deb file. Please note the following change for the source deb file.

echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list

You will note the “[signed-by” for the deb reference now points where the signed key can be found. This creates a more secure mechanism that is now one-one instead of one-to-many. It associates a specific key to a specific repository. i.e. things are not loosie goosey any more.

One of the morals of this story:

In the quest to install something one should consider if what you are given to install is correct? It might be the case that OLD instructions might actually create security problems or implement bad habits. Part of this is just do the changing times. Today you install docker with 21 characters [“apt install docker.io”] The instructions for older versions had quite a few more hoops.

As a side:

I ended up using the “trusted.gpg.d” directory of apt to store the key. Time will tell if this was smart. But I think in hindsight this might be a more likely place for me at least to find the key in the future. The “key name” itself seemed appropriate and should be easy to associate with a deb.

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/elasticsearch-keyring.gpg

references:
https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-elasticsearch-on-ubuntu-18-04 (this is bad)
https://www.elastic.co/guide/en/elasticsearch/reference/current/deb.html
https://www.linuxjournal.com/article/8732