On Sun, Jun 20, 2021 at 10:20:42AM +0300, Andrei POPESCU wrote: > Package: release-notes > X-Debbugs-Cc: debian-u...@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.
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
signature.asc
Description: PGP signature
