Post by Andrei POPESCUPackage: release-notes
Command apt-key and its man page say that apt-key is deprecated, but do not
suggest an instead recommended tool. It is only mentioned that keys would
now be organized in /etc/apt/trusted.gpg.d/ . But how should I manage the
keys saved there, for instance how to update them, or what tool of the
Debian distribution is managing them there for the apt functionality of the
Debian OS?
As far as I understand it's as simple as dropping the keys in there.
When a key changes/expires/etc. replace it with the new one (if provided
by the respective repository).
Guiding me to a properly up-to-date documentation about this topic would be
welcome!
Indeed the documentation on this is a bit scarce, probably worth a
mention in the Release Notes.
Dear APT maintainers,
The short version appears to be this note to the 'add' command from
Note: Instead of using this command a keyring should be placed
directly in the /etc/apt/trusted.gpg.d/ directory with a descriptive
name and either "gpg" or "asc" as file extension.
where .gpg files are of type created with 'gpg --export' and .asc with
'gpg --armor --export'.
Your confirmation (or even better, proposes wording) would be much
appreciated.
I suggested wording for it in Bug#980743: release-notes: bullseye is
the final release to ship apt-key - that I opened back in January,
and it was added in April. So this is a duplicate.
I'll leave the bug state to you, it ain't my package, and you might
want to add a second note, I don't know.
The long version is below.
# The direct translation
If you currently have:
âwget -qO- https://myrepo.example/myrepo.asc | sudo apt-key add ââ
To translate this directly for buster (bionic) and newer, you can use:
âwget -qO /etc/apt/trusted.gpg.d/myrepo.asc https://myrepo.example/myrepo.ascâ
Older (and all) releases only support unarmored files with an extension .gpg. If you care about them, provide one, and use
âwget -qO /etc/apt/trusted.gpg.d/myrepo.gpg https://myrepo.example/myrepo.gpgâ
Some people will tell you to download the .asc and pipe it to gpg --dearmor, but gpg might not be installed, so really, just offer a .gpg one instead that is supported on all systems.
# Pretending to be safer by using signed-by
People say it's good practice to not use trusted.gpg.d and install the file elsewhere and then refer to it from the sources.list entry
by using signed-by=<path to the file>. So this looks a lot safer, because now your key can't sign other unrelated repositories. In
practice, security increase is minimal, since package maintainer scripts run as root anyway. But I guess it's better for publicity :)
As an example, here are the instructions to install signal-desktop from signal.org. As mentioned, gpg --dearmor use in there is not a good idea,
and I'd personally not tell people to modify /usr as it's supposed to be managed by the package manager, but we don't have an /etc/apt/keyrings
or similar at the moment; it's fine though if the keyring is installed by the package.
# NOTE: These instructions only work for 64 bit Debian-based
# Linux distributions such as Ubuntu, Mint etc.
# 1. Install our official public software signing key
wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg
cat signal-desktop-keyring.gpg | sudo tee -a /usr/share/keyrings/signal-desktop-keyring.gpg > /dev/null
# 2. Add our repository to your list of repositories
echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg] https://updates.signal.org/desktop/apt xenial main' |\
sudo tee -a /etc/apt/sources.list.d/signal-xenial.list
# 3. Update your package database and install signal
sudo apt update && sudo apt install signal-desktop
I do wonder why they do wget | gpg --dearmor, pipe that into the file and then cat | sudo tee it, instead of having that all in one pipeline. Maybe they want nicer progress reporting.
# Summary
We have three scenarios:
For system image building, shipping the key in /etc/apt/trusted.gpg.d seems reasonable to me; you are the vendor sort of, so it can be globally trusted.
Chrome-style debs and repository config debs: If you ship a deb, embedding the sources.list.d snippet (calling it $myrepo.list) and shipping a $myrepo.gpg in /usr/share/keyrings is the best approach. Whether you ship that in product debs aka vscode/chromium or provide a repository configuration deb (let's call it myrepo-repo.deb) and then tell people to run apt update followed by apt install <package inside the repo> depends on how many packages are in the repo, I guess.
Manual instructions (signal style): The third case, where you tell people to run wget themselves, I find tricky. As we see in signal, just stuffing keyring files into /usr/share/keyrings is popular, despite /usr supposed to be managed by the package manager. We don't have another dir inside /etc (or /usr/local), so it's hard to suggest something else. There's no significant benefit from actually using signed-by, so it's kind of extra work for little gain, though.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en