[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#990086: apt-key is deprecated in bullseye, how to manage keys instead



On Sun, Jun 20, 2021 at 10:20:42AM +0300, Andrei POPESCU wrote:
> Package: release-notes
> X-Debbugs-Cc: debian-user@lists.debian.org, apt@packages.debian.org
> 
> On Sb, 19 iun 21, 22:07:35, Marco Möller wrote:
> > 
> > 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 
> apt-key(8):
> 
>     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

Attachment: signature.asc
Description: PGP signature


Reply to: