Save Docker Repository Signing Key Correctly in .asc Format

Hello,

we are in the process of automating the installation of Docker, specifically its repository, on Debian distributions and stumbled upon a problem when adding the Docker repository during preseeding.
The repository, mainly its key, can not be added automatically during preseeding, as its file extension does not match its file type.
The public repository key of Docker, which can be found here, is an ASCII-armoured key, yet it is saved as a plain file called gpg with no file extension, when it should be saved as *.asc, respectively docker.asc.

Here is the corresponding excerpt of the Debian Bullseye example preseed file for adding additional repositories:

# Additional repositories, local[0-9] available
#d-i apt-setup/local0/repository string \
#       http://local.server/debian stable main
#d-i apt-setup/local0/comment string local server
# Enable deb-src lines
#d-i apt-setup/local0/source boolean true
# URL to the public key of the local repository; you must provide a key or
# apt will complain about the unauthenticated repository and so the
# sources.list line will be left commented out.
#d-i apt-setup/local0/key string http://local.server/key
# If the provided key file ends in ".asc" the key file needs to be an
# ASCII-armoured PGP key, if it ends in ".gpg" it needs to use the
# "GPG key public keyring" format, the "keybox database" format is
# currently not supported.

https://www.debian.org/releases/bullseye/example-preseed.txt (Line 339-352)

Could Docker therefore please save its key in the corresponding format, so that the Debian installer can dearmor and add the Docker key automatically?

Ubuntu, as it’s Debian-based, will likely have the same problem.
Saving the key and saving files with the correct file ending is generally good practice.
Could the correct file extensions therefore be extended to all keys Docker uses?

EDIT: Added link to the web address where Dockers repository key can be found.

It looks like you are not using the official repository provided by Docker. Distributions like Ubuntu or Debian can have their own repositories from which you can install Docker, but it is recommended to use the one provided by Docker. In case of Debian, this is where you can find the documentation:

If you want Debian to fix the file extension, you need to ask it from them :slight_smile:

We are using the official Docker repository, it’s only that Docker’s signing key is not stored with the corresponding file extension.

To clarify my point, here are two examples:

This example has the current links:

# Additional repositories, local[0-9] available
d-i apt-setup/local0/repository string \
    https://download.docker.com/linux/debian bullseye stable
d-i apt-setup/local0/key string https://download.docker.com/linux/debian/gpg

But the specification demands it as follows:

So correct would be:

# Additional repositories, local[0-9] available
d-i apt-setup/local0/repository string \
    https://download.docker.com/linux/debian bullseye stable
d-i apt-setup/local0/key string https://download.docker.com/linux/debian/docker.asc

See the difference?
The ASCII-armoured key in the first example is saved as just gpg, but it should be saved with the extension .asc, e. g. docker.asc.
A web symlink to the same file would probably be enough, just so that the key gets downloaded as such.

Since this was only recently outlined in the Bullseye example preseed file and wasn’t outlined in the Buster example preseed file, there might be further emphasis on the correct file extension in the future and it therefore makes sense to save the key file with the corresponding file extension.

Microsoft, for example, does it with their VS Code repository as well and saves their key as microsoft.asc.

Sorry, I did not read your post carefully. I can see now you just linked an example from the debian repository.

There is one thing I don’t understand though. According to the official documentation, you should save the GPG file like this:

sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

So in the end you should have a file with the “gpg” extension in gpg format, not the ascii format. I agree that it would be better to store the file online with the correct extension, but can’t you first download the key with the right format before the preseeing?

I am not sure if what I am saying makes sense, because I have never tried preseeding. Is downloading the GPG key required even if you already downloaded it?

Note that I am not saying that there is no problem here, I am just trying to find a solution for your current case.

Since the documentation does not mention any preseeding and that method works, if you want to report it as a feature request, I think you could try here:

Preseeding basically means automating the operating system installation of Debian operating systems the official way. It’s the Debian equivalent of answer files under Windows.

Repository and GPG files are imported by the Debian installer automatically when You specify the links.
There is no scripting involved. It’s a declarative approach. The Debian installer does all the work for You.
You basically answer the questions what local repositories You want to use and what their respective key is.

You can of course script at certain installation stages with d-i preseed/early_command and d-i preseed/late_command, but it is error prone and its best to be kept at a minimum.
Here is the corresponding excerpt from the Bullseye example preseed:

# This first command is run as early as possible, just after
# preseeding is read.
#d-i preseed/early_command string anna-install some-udeb
# This command is run immediately before the partitioner starts. It may be
# useful to apply dynamic partitioner preseeding that depends on the state
# of the disks (which may not be visible when preseed/early_command runs).
#d-i partman/early_command \
#       string debconf-set partman-auto/disk "$(list-devices disk | head -n1)"
# This command is run just before the install finishes, but when there is
# still a usable /target directory. You can chroot to /target and use it
# directly, or use the apt-install and in-target commands to easily install
# packages and run commands in the target system.
#d-i preseed/late_command string apt-install zsh; in-target chsh -s /bin/zsh

The script from the Docker documentation You mentioned earlier, is not involved in the installation in any way. It is solely the Debian installer that fetches the GPG key, so there should be no double download if the Debian installer doesn’t do it.

Anyway, Your first post got me to doubt my installation script, so I looked over it again I could find an error in my script. I used the release name stable instead of the version name bullseye, while Docker only uses the version names and not the release names in its repository structure, whereas Debian mirrors use both.
So, thanks for the unintentional help. :grinning:

The Docker repository is now available during installation and I was able to install Docker during preseeding, despite the missing file extension. Still, the missing file extension is not optimal and I basically found another problem by solving a problem.

My wishes for Docker are therefore as follows:

  • Provide Your GPG key with the correct file extension and name it after You, e.g. docker.asc
  • Add the release names stable, oldstable, oldoldstable, oldoldoldstable in addition to the version names, like bullseye, buster, etc.
1 Like

Thank you for your detailed description! I could learn something :slight_smile: I actually know Linux better than Windows, but I have never used this method to install Linux. Sometimes I use something like

echo "$parameters" | mycommand

I thought you did something like that in a script.

I usually use Ansible to install everything after creating a base OS and I also create the VM with Ansible.

Now that I understand the problem, I am pretty sure you could ask for this change in the roadmap that I linked before. People who can actually make this change are usually not here on the forum.