Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.8.0 2019-01-22T11:24:22Z 2019-01-22T11:24:22Z David Kalnischkies david@kalnischkies.de 2018-09-11T23:44:18Z urn:sha1:7bf533967fb385b9625a1ee4dd7c6542a84b489c Telling the acquire system which keys caused the gpgv method to succeed allows us for now just a casual check if the gpgv method really executed catching bugs like CVE-2018-0501, but we will make use of the information for better features in the following commits. 2019-01-22T11:24:22Z David Kalnischkies david@kalnischkies.de 2018-09-11T14:45:06Z urn:sha1:6b01cd087e6f92c5511fe6eea73699e075aa699a Having a method take a bunch of string vectors is bad style, so we change this to a wrapping struct and adapt the rest of the code brushing it up slightly in the process, which results even in a slightly "better" debug output, no practical change otherwise. Gbp-Dch: Ignore 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-09-11T11:16:11Z David Kalnischkies david@kalnischkies.de 2018-08-17T09:59:45Z urn:sha1:ff8fa4ab4b80384a9240f0df63181f71077a8d83 If we limit a file to be signed by a certain key it should usually accept also being signed by any of this keys subkeys instead of requiring each subkey to be listed explicitly. If the later is really wanted we support now also the same syntax as gpg does with appending an exclamation mark at the end of the fingerprint to force no mapping. 2018-08-19T15:30:31Z David Kalnischkies david@kalnischkies.de 2018-08-16T21:36:41Z urn:sha1:b934870c4f893be28eb1537910c0aadce6dd6e09 gpgs DETAILS documentation file declares that GOODSIG could report keyid or fingerprint since gpg2, but for the time being it is still keyid only. Who knows if that will ever change as that feels like an interface break with dangerous security implications, but lets be better safe than sorry especially as the code dealing with signed-by keyids is prepared for this already. This code is rewritten still to have them all use the same code for this type of problem. 2017-07-12T11:57:51Z Julian Andres Klode jak@debian.org 2017-07-12T11:40:41Z urn:sha1:87274d0f22e1dfd99b2e5200e2fe75c1b804eac3 This makes it easier to see which headers includes what. The changes were done by running git grep -l '#\s*include' \ | grep -E '.(cc|h)$' \ | xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/' To modify all include lines by adding a space, and then running ./git-clang-format.sh. 2017-01-19T14:59:38Z David Kalnischkies david@kalnischkies.de 2017-01-19T14:14:19Z urn:sha1:93cff633a830e222693fc0f3d78e6e534d1126ee Most of them in (old) code comments. The two instances of user visible string changes the po files of the manpages are fixed up as well. Gbp-Dch: Ignore Reported-By: spellintian 2016-11-25T22:45:19Z Julian Andres Klode jak@debian.org 2016-11-25T12:12:28Z urn:sha1:33d7a8d672c8c720947e81158de4a5a07be05b72 Change the trust level check to allow downgrading an Untrusted option to weak (APT::Hashes::SHA1::Weak "yes";), so it prints a warning instead of an error; and change the default values for SHA1 and RIPE-MD/160 from Weak to Untrusted. 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 2016-09-01T17:24:26Z David Kalnischkies david@kalnischkies.de 2016-09-01T16:55:20Z urn:sha1:6dc85f53d92b9763a1509a6472227c54bc70b01d In gpgv1 GOODSIG (and the other messages of status-fd) are documented as sending the long keyid. In gpgv2 it is documented to be either long keyid or the fingerprint. At the moment it is still the long keyid, but the documentation hints at the possibility of changing this. We care about this for Signed-By support as we detect this way if the right fingerprint has signed this file (or not). The check itself is done via VALIDSIG which always is a fingerprint, but there must also be a GOODSIG (as expired sigs are valid, too) found to be accepted which wouldn't be found in the fingerprint-case and the signature hence refused.