Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_exp3 2016-06-02T11:35:28Z 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-08T17:46:34Z David Kalnischkies david@kalnischkies.de 2016-05-08T17:46:34Z urn:sha1:2fac0dd5a7a62b67a869cd4c71c9d09159aaa31d gpg doesn't give use a UID on NODATA, which we were "expecting" (but not using for anything), but just an error number. Instead of collecting these as badsigners which will trigger a "invald signature" error with remarks like "NODATA 1" we instead adapt a message similar to the NODATA error of a clearsigned file (which is actually not reached anymore as we split them up, which fails with a NOSPLIT error, which uses the same general error message). In other words: Not a security relevant change, just a user experience improvement as we now point them to the most likely cause of the problem instead of saying "invalid signature" which would point them in the direction of the archive being broken (for everyone) instead. Closes: 823746 2016-05-01T08:50:24Z David Kalnischkies david@kalnischkies.de 2016-04-28T22:31:49Z urn:sha1:fb7b11ebb852fa255053ecab605bc9cfe9de0603 Daniel Kahn Gillmor highlights in the bugreport that security isn't improving by having the user import additional keys – especially as importing keys securely is hard. The bugreport was initially about dropping the warning to a notice, but in given the previously mentioned observation and the fact that we weren't printing a warning (or a notice) for expired or revoked keys providing a signature we drop it completely as the code to display a message if this was the only key is in another path – and is considered critical. Closes: 618445 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 2015-12-19T22:04:34Z David Kalnischkies david@kalnischkies.de 2015-12-18T12:17:11Z urn:sha1:785cb6fc843f4751ff9c57dcdf375ad061e83f36 The output changes slightly between different versions, which we already dealt with in the main testcase for apt-key, but there are two more which do not test both versions explicitly and so still had gpg1 output to check against as this is the default at the moment. Git-Dch: Ignore 2015-12-19T22:04:34Z David Kalnischkies david@kalnischkies.de 2015-12-17T16:41:11Z urn:sha1:bc8f83a5afd858206efe518c31bbb1ac948a39a3 apt-key creates internally a script (since ~1.1) which it will call to avoid dealing with an array of different options in the code itself, but while writing this script it wraps the values in "", which will cause the shell to evaluate its content upon execution. To make 'use' of this either set a absolute gpg command or TMPDIR to something as interesting as: "/tmp/This is fü\$\$ing cràzy, \$(man man | head -n1 | cut -d' ' -f1)\$!" If such paths can be encountered in reality is a different question… 2015-12-19T22:04:34Z David Kalnischkies david@kalnischkies.de 2015-12-15T16:20:26Z urn:sha1:3abb6a6a1e485b3bc899b64b0a1b7dc2db25a9c2 This doesn't allow all tests to run cleanly, but it at least allows to write tests which could run successfully in such environments. Git-Dch: Ignore 2015-09-14T13:22:19Z David Kalnischkies david@kalnischkies.de 2015-09-13T20:16:32Z urn:sha1:fecfbf2e4cbb71d20364306baf6aa7886c5f3ecd Filenames we get could include spaces, but also the tmpdir we work in and the failures we print in return a very generic and unhelpful… Properly supporting spaces is a bit painful as we constructed gpg command before, which is now moved to (multilevel) calls to temporary scripts instead. 2015-08-10T15:25:26Z David Kalnischkies david@kalnischkies.de 2015-07-07T20:11:20Z urn:sha1:4e03c47de15164f2656d9655edab6fb3570cb2f2 The previous commit returns to the possibility of using just gpgv for verification proposes. There is one problem through: We can't enforce a specific keyid without using gpg, but our acquire method can as it parses gpgv output anyway, so it can deal with good signatures from not expected signatures and treats them as unknown keys instead. Git-Dch: Ignore 2015-08-10T15:25:26Z David Kalnischkies david@kalnischkies.de 2015-07-07T09:46:39Z urn:sha1:25f2731928f0b571f7521d7d7a7e301499d0f6ee If all keyrings are simple keyrings we can merge the keyrings with cat rather than doing a detour over gpg --export | --import (see #790665), which means 'apt-key verify' can do without gpg and just use gpgv as before the merging change. We declare this gpgv usage explicit now in the dependencies. This isn't a new dependency as gnupg as well as debian-archive-keyring depend on and we used it before unconditionally, just that we didn't declare it. The handling of the merged keyring needs to be slightly different as our merged keyring can end up containing the same key multiple times, but at least currently gpg does remove only the first occurrence with --delete-keys, so we move the handling to a if one is gone, all are gone rather than an (implicit) quid pro quo or even no effect. Thanks: Daniel Kahn Gillmor for the suggestion