Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1.7 2015-12-19T22:04:34Z 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 2015-08-10T15:25:26Z David Kalnischkies david@kalnischkies.de 2015-07-06T19:15:45Z urn:sha1:f14cde2ca702f72415486bf5c310208a7c500e9c The output of gpg slightly changes in 2.1 which breaks the testcase, but the real problem is that this branch introduces a new default keyring format (which is called keybox) and mixing it with simple keyrings (the previous default format) has various problems like failing in the keybox to keyring import (#790665) or [older] gpgv versions not being able to deal with keyboxes (and newer versions as well currently: https://bugs.gnupg.org/gnupg/issue2025). We fix this by being a bit more careful in who creates keyrings (aka: we do it or we take a simple keyring as base) to ensure we always have a keyring instead of a keybox. This way we can ensure that any version combination of gpv/gpgv2 and gnupg/gnupg2 without doing explicit version checks and use the same code for all of them. Closes: 781042 2015-08-10T15:25:26Z David Kalnischkies david@kalnischkies.de 2015-06-24T17:31:22Z urn:sha1:b0d408547734100bf86781615f546487ecf390d9 Limits which key(s) can be used to sign a repository. Not immensely useful from a security perspective all by itself, but if the user has additional measures in place to confine a repository (like pinning) an attacker who gets the key for such a repository is limited to its potential and can't use the key to sign its attacks for an other (maybe less limited) repository… (yes, this is as weak as it sounds, but having the capability might come in handy for implementing other stuff later). 2015-04-18T23:27:31Z David Kalnischkies david@kalnischkies.de 2015-04-18T23:24:46Z urn:sha1:05f64ca2e483709faa6bc69dfa79129d2d4c679e Conflicts: apt-pkg/acquire-item.cc cmdline/apt-key.in methods/https.cc test/integration/test-apt-key test/integration/test-multiarch-foreign 2015-04-07T20:34:34Z David Kalnischkies david@kalnischkies.de 2015-04-07T20:34:34Z urn:sha1:d5cf8851753dde4f45bfd3b48fcdf34247a8752a gnupg is case-insensitive about keyids, so back then apt-key called it directly any keyid was accepted, but now that we work more with the keyid ourself we regressed to require uppercase keyids by accident. This is also inconsistent with other apt-key commands which still use gnupg directly. A single case-insensitive grep and we are fine again. Closes: 781696