apt/cmdline/apt-key.in, branch 2.3.14

Use short options for cmp

2021-11-26T14:33:06Z

In order to be consistent with other uses of cmp and to improve compatiblity with other implementations, like busybox one, change long options to short ones. Signed-off-by: Walter Lozano

Use `command -v` instead of `which`

2021-11-03T22:02:41Z

`which` has been deprecated in debianutils 5.0+. The recommended replacement, `command -v`, is mandated by Debian policy these days, in addition to being required by POSIX and its predecessor specs at least since 1994. Not found commands cause no output from `command -v` per POSIX, so remove the redundant 2>&1's while at it.

apt-key: Allow depending on gpg instead of gnupg

2020-05-06T10:52:57Z

Maintainer scripts that need to use apt-key del might as well depend on gpg, they don't need the full gnupg suite.

Fully deprecate apt-key, schedule removal for Q2/2022

2020-05-06T10:33:39Z

People are still using apt-key add and friends, despite that not being guaranteed to work. Let's tell them to stop doing so. We might still want a list command at a future point, but this needs deciding, and a blanket ban atm seems like a sensible step until we figured that out.

Support multiple keyrings in sources.list Signed-By

2018-09-11T11:16:11Z

A user can specify multiple fingerprints for a while now, so its seems counter-intuitive to support only one keyring, especially if this isn't really checked or enforced and while unlikely mixtures of both should work properly, too, instead of a kinda random behaviour.

apt-key: Pass all instead of gpg-agent to gpgconf --kill

2018-05-29T15:57:35Z

We want to kill everything using our temporary directory. LP: #1773992

Fix various typos reported by spellcheckers

2018-05-04T22:34:27Z

Reported-By: codespell & spellintian Gbp-Dch: Ignore

ignore unsupported key formats in apt-key

2017-10-05T15:30:25Z

gpg2 generates keyboxes by default and users end up putting either those or armored files into the trusted.gpg.d directory which apt tools neither expect nor can really work with without fortifying backward compatibility (at least under the ".gpg" extension). A (short) discussion about how to deal with keyboxes happened in https://lists.debian.org/deity/2017/07/msg00083.html As the last message in that thread is this changeset lets go ahead with it and see how it turns out. The idea is here simply that we check the first octal of a gpg file to have one of three accepted values. Testing on my machines has always produced just one of these, but running into those values on invalid files is reasonabily unlikely to not worry too much. Closes: #876508

apt-key: ignore gpg1 already imported secret key import failure

2016-12-31T02:50:06Z

On Travis and co the default gpg implementation is gpg1 which for some reason fails if a secret key which was already imported is imported again. We would prefer it to be a NOP like gpg2 handles it so we crudely check the error message. apt-key usually doesn't deal with secret keys – it only learned to do it for manual testing and the integration framework usage, so no public interface is effected. Triggered-By: 4ce2f35248123ff2366c8c365ad6a94945578d66 Gbp-Dch: Ignore

tests: cache the apt-key homedir used for Release signing

2016-12-21T18:36:10Z

Importing a new secret key into gpg(2) can be increadibly slow which prolongs the test runs significantly – by caching the homedir we gain a significant speedbonus as reimporting already present keys seems like a far less costly operation. Git-Dch: Ignore