Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.2.1 2020-05-06T10:52:57Z 2020-05-06T10:52:57Z Julian Andres Klode julian.klode@canonical.com 2020-05-06T10:52:57Z urn:sha1:f9f0ae2bbb2d0bfeccddecbf8b9ec07ccd54cd9a Maintainer scripts that need to use apt-key del might as well depend on gpg, they don't need the full gnupg suite. 2020-05-06T10:33:39Z Julian Andres Klode julian.klode@canonical.com 2020-05-06T10:33:39Z urn:sha1:ee284d5917d09649b68ff1632d44e892f290c52f 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. 2018-09-11T11:16:11Z David Kalnischkies david@kalnischkies.de 2018-08-17T14:33:41Z urn:sha1:8375d5b58038fc026098dcccc3de87cd9d740334 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. 2018-05-29T15:57:35Z Julian Andres Klode julian.klode@canonical.com 2018-05-29T15:57:35Z urn:sha1:819426013c6ca6310bb469440702b6295dba4498 We want to kill everything using our temporary directory. LP: #1773992 2018-05-04T22:34:27Z David Kalnischkies david@kalnischkies.de 2018-05-04T17:56:41Z urn:sha1:b12bdeaf8acd050c5526ecc05526db70df5fd485 Reported-By: codespell & spellintian Gbp-Dch: Ignore 2017-10-05T15:30:25Z David Kalnischkies david@kalnischkies.de 2017-08-01T13:22:09Z urn:sha1:012932793ba0ea9398a9acd80593bed8e77cfbfc 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 2016-12-31T02:50:06Z David Kalnischkies david@kalnischkies.de 2016-12-31T02:50:06Z urn:sha1:9544398fce600fb62762c05a8a84231fd1a365b4 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 2016-12-21T18:36:10Z David Kalnischkies david@kalnischkies.de 2016-12-18T16:42:17Z urn:sha1:4ce2f35248123ff2366c8c365ad6a94945578d66 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 2016-11-24T23:15:12Z David Kalnischkies david@kalnischkies.de 2016-11-13T19:52:18Z urn:sha1:2906182db398419a9c59a928b7ae73cf7c7aa307 Having binary files in /etc is kinda annoying – not that the armored files are much better – but it is hard to keep tabs on which format the file has ("simple" or "keybox") and different gnupg versions have different default binary formats which can be confusing for users to work with (beside that it is binary). Adding support for this now will enable us in some distant future to move to armored later on, much like we added trusted.gpg.d years before the world picked it up. 2016-11-23T23:21:35Z David Kalnischkies david@kalnischkies.de 2016-11-12T22:22:33Z urn:sha1:8e438ede2f179f2f66268308c24d62952ac06fa4 We report warnings from apt-key this way already since 29c590951f812d9e9c4f17706e34f2c3315fb1f6, so reporting errors seems like a good addition. Most of those errors aren't really from apt-key through, but from the code setting up and actually calling it which used to just print to stderr which might or might not intermix them with (other) progress lines in update calls. Having them as proper error messages in the system means that the errors are actually collected later on for the list instead of ending up with our relatively generic but in those cases bogus hint regarding "is gpgv installed?". The effective difference is minimal as the errors apply mostly to systems which have far worse problems than a not as nice looking error message, which makes this pretty hard to test – but at least now the hint that your system is broken can be read in proper order (= there aren't many valid cases in which the permissions of /tmp are messed up…). LP: #1522988