Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_pre2 2016-07-01T22:03:20Z 2016-07-01T22:03:20Z David Kalnischkies david@kalnischkies.de 2016-07-01T21:44:37Z urn:sha1:f4dcab0504a68595d9e95c953ce66f46f9ad30aa Debian isn't using 'update' anymore for years and the command is in direct conflict with our goal of not requiring gnupg anymore, so it is high time to officially declare this command as deprecated. 2016-07-01T20:00:52Z David Kalnischkies david@kalnischkies.de 2016-07-01T20:00:52Z urn:sha1:08fcf9628806af202e555bd02b3611e4e9a3d757 apt-key needs gnupg for most of its operations, but depending on it isn't very efficient as apt-key is hardly used by users – and scripts shouldn't use it to begin with as it is just a silly wrapper. To draw more attention on the fact that e.g. 'apt-key add' should not be used in favor of "just" dropping a keyring file into the trusted.gpg.d directory this commit implements the display of warnings. 2016-07-01T14:40:36Z David Kalnischkies david@kalnischkies.de 2016-07-01T14:40:36Z urn:sha1:a5f9b45e4a67246f7af2c6fc62de9c531cd314a4 There is no real point in having two commands which roughly do the same thing, especially if the difference is just in the display of the fingerprint and hence security sensitive information. Closes: 829232 2016-06-14T11:55:33Z David Kalnischkies david@kalnischkies.de 2016-06-14T11:55:33Z urn:sha1:ee385a36fe753272cadac0afd7f19b123a0c3d54 2016-06-02T11:35:28Z David Kalnischkies david@kalnischkies.de 2016-06-02T09:12:39Z urn:sha1:0cfec3ab589c6309bf284438d2148c7742cdaf10 First seen on hurd, but easily reproducible on all systems by removing the 'execution' bit from the current working directory and watching some tests (mostly the no-output expecting tests) fail due to find printing: "find: Failed to restore initial working directory: …" Samuel Thibault says in the bugreport: | To do its work, find first records the $PWD, then goes to | /etc/apt/trusted.gpg.d/ to find the files, and then goes back to $PWD. | | On Linux, getting $PWD from the 700 directory happens to work by luck | (POSIX says that getcwd can return [EACCES]: Search permission was denied | for the current directory, or read or search permission was denied for a | directory above the current directory in the file hierarchy). And going | back to $PWD fails, and thus find returns 1, but at least it emitted its | output. | | On Hurd, getting $PWD from the 700 directory fails, and find thus aborts | immediately, without emitting any output, and thus no keyring is found. | | So, to summarize, the issue is that since apt-get update runs find as a | non-root user, running it from a 700 directory breaks find. Solved as suggested by changing to '/' before running find, with some paranoia extra care taking to ensure the paths we give to find are really absolute paths first (they really should, but TMPDIR=. or a similar Dir::Etc::trustedparts setting could exist somewhere in the wild). The commit takes also the opportunity to make these lines slightly less error ignoring and the two find calls using (mostly) the same parameters. Thanks: Samuel Thibault for 'finding' the culprit! Closes: 826043 2016-05-01T15:17:18Z Carsten Hey carsten@debian.org 2016-05-01T15:06:29Z urn:sha1:2e49f51915d07a6ad85c7ee4380a1e51afaa3a17 Guarding against 'broken' greps not dealing with non-text inputs "just in case" by making the input text with a proper newline. [commit message by David Kalnischkies] Reported-On: IRC Git-Dch: Ignore 2016-05-01T13:50:04Z David Kalnischkies david@kalnischkies.de 2016-05-01T12:43:23Z urn:sha1:5f17b19f8f99eb6f80a10846d5891f53c16178dc We want to stop hard-depending on gnupg and for this it is essential that apt-key isn't used in any critical execution path, which maintainerscript are. Especially as it is likely that these script call apt-key either only for (potentially now outdated cleanup) or still not use the much simpler trusted.gpg.d infrastructure. 2016-03-06T09:16:59Z David Kalnischkies david@kalnischkies.de 2016-03-06T09:16:59Z urn:sha1:031a3f254a2a73b2843ead28a2481b63ec1d7244 Fixed in f7bd44bae0d7cb7f9838490b5eece075da83899e already, but the commit misses the Closes tag and while we are at it we can add a simple regression test and micro-optimize it a bit. Thanks: James McCoy for the suggestion. Closes: 816691 2016-03-04T22:26:11Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2016-03-04T09:23:24Z urn:sha1:f7bd44bae0d7cb7f9838490b5eece075da83899e 2015-12-19T22:04:34Z David Kalnischkies david@kalnischkies.de 2015-12-18T11:35:43Z urn:sha1:803491dc568d2994745c3c4359f68053f7261658 The presents (even of an empty) secring.gpg is indication enough for gpg2 to tigger the migration code which not only produces a bunch of output on each apt-key call, but also takes a while to complete as an agent needs to be started and all that. We workaround the first part by forcing the migration to happen always in a call we forced into silence, but that leaves us with an agent to start all the time – with a bit of reordering we can make it so that we do not explicitly create the secring, but let gpg create it if needed, which prevents the migration from being triggered and we have at least a bit less of a need for an agent. Changes - even to public only keyrings - still require one, but such actions are infrequent in comparison to verification calls, so that should be a net improvement.