Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1.4 2015-09-14T13:22:19Z 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 2015-03-16T17:01:54Z David Kalnischkies david@kalnischkies.de 2015-03-09T23:59:44Z urn:sha1:25b86db159fbc3c043628e285c0c1ef24dec2c6e We use test{success,failure} now all over the place in the framework, so its only consequencial to do this in the situations in which we test for a specific output as well. Git-Dch: Ignore 2014-11-28T15:15:39Z James McCoy jamessan@debian.org 2014-11-28T13:21:06Z urn:sha1:69d8b8537af1dd52db5f2e0e785bdce3e52fdf8d apt-key given a long keyid reports just "OK" all the time, but doesn't delete the mentioned key as it doesn't find the key. Note: In debian/experimental this was closed with 29f1b977100aeb6d6ebd38923eeb7a623e264ffe which just added the testcase as the rewrite of apt-key had fixed this as well. Closes: 754436 2014-10-26T13:14:42Z David Kalnischkies david@kalnischkies.de 2014-10-25T11:37:05Z urn:sha1:e52aad5208281837f13018363118ff73aaaabf45 Git-Dch: Ignore