Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.6_beta1 2017-07-12T11:57:51Z 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. 2016-08-25T13:22:28Z David Kalnischkies david@kalnischkies.de 2016-08-25T13:22:28Z urn:sha1:29c590951f812d9e9c4f17706e34f2c3315fb1f6 In 105503b4b470c124bc0c271bd8a50e25ecbe9133 we got a warning implemented for unreadable files which greatly improves the behavior of apt update already as everything will work as long as we don't need the keys included in these files. The behavior if they are needed is still strange through as update will fail claiming missing keys and a manual test (which the user will likely perform as root) will be successful. Passing the new warning generated by apt-key through to apt is a bit strange from an interface point of view, but basically duplicating the warning code in multiple places doesn't feel right either. That means we have no translation for the message through as apt-key has no i18n yet. It also means that if the user has a bunch of sources each of them will generate a warning for each unreadable file which could result in quite a few duplicated warnings, but "too many" is better than none. Closes: 834973 2016-08-10T21:19:44Z David Kalnischkies david@kalnischkies.de 2016-07-31T16:05:56Z urn:sha1:30060442025824c491f58887ca7369f3c572fa57 The https method implemented for a long while now a hardcoded fallback to the same options in http, which, while it works, is rather inflexible if we want to allow the methods to use another name to change their behavior slightly, like apt-transport-tor does to https – most of the diff being s#https#tor#g which then fails to do the full circle fallthrough tor -> https -> http for https sources. With this config infrastructure this could be implemented now. 2016-05-28T16:12:02Z David Kalnischkies david@kalnischkies.de 2016-05-28T11:22:38Z urn:sha1:8b79c94af7f7cf2e5e5342294bc6e5a908cacabf We use a wild mixture of C and C++ ways of generating output, so having a consistent world-view in both styles sounds like a good idea and should help in preventing regressions. 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-29T08:16:42Z urn:sha1:46e00c9062d09a642973e83a334483db1f310397 A keyring file can include multiple keys, so its only fair for transitions and such to support multiple fingerprints as well.