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

[Andrei POPESCU]

Package: release-notes
X-Debbugs-Cc: debia...@lists.debian.org, a...@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.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

[Julian Andres Klode]

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

[Andrei POPESCU]

Control: retitle -1 release-notes: deprecations not obvious from the table of contents
Control: severity -1 minor

On Du, 20 iun 21, 09:40:14, Julian Andres Klode wrote:
>
> 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.

Indeed, I seemed to remember this, but couldn't find it just by looking
at the table of contents, because it's under "Deprecated components for
bullseye".

Maybe we should have sub-headings for each component?

[Paul Gevers]

Control: close -1

Hi,

On Mon, 21 Jun 2021 08:42:58 +0300 Andrei POPESCU
<andreim...@gmail.com> wrote:
> Control: retitle -1 release-notes: deprecations not obvious from the table of contents
> Control: severity -1 minor
>
> On Du, 20 iun 21, 09:40:14, Julian Andres Klode wrote:
> >
> > 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.
>
> Indeed, I seemed to remember this, but couldn't find it just by looking
> at the table of contents, because it's under "Deprecated components for
> bullseye".
>
> Maybe we should have sub-headings for each component?

I think that's going a bit too much bloat, hence closing this bug.
Please reopen, anybody, if you agree with Andrei.

Paul