Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4_beta3 2016-12-31T01:29:21Z 2016-12-31T01:29:21Z David Kalnischkies david@kalnischkies.de 2016-12-09T14:13:09Z urn:sha1:d8617331afc39281d5925033975b6097128786f4 This 'method' is the abstract base for http and https and should as such be called out like this rather using an easily confused name. Gbp-Dch: Ignore 2016-12-31T01:29:21Z David Kalnischkies david@kalnischkies.de 2016-11-09T11:25:44Z urn:sha1:13a9f08de18dea0dfc1951992b0ddeda9c2fa2dd Having a Reset(bool) method to partially reset certain variables like the download size always were strange, so this commit splits the ServerState into an additional RequestState living on the stack for as long as we deal with this request causing an automatic "reset". There is much to do still to make this code look better, but this is a good first step which compiles cleanly and passes all tests, so keeping it as history might be beneficial and due to avoiding explicit memory allocations it ends up fixing a small memory leak in https, too. Closes: #440057 2016-12-08T13:48:12Z Lukasz Kawczynski n@neuroid.pl 2016-12-08T13:48:12Z urn:sha1:49b91f6903804183dbe1abb12ce1f9803a3dee5f 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-11-11T22:40:37Z David Kalnischkies david@kalnischkies.de 2016-11-11T09:32:31Z urn:sha1:11c96d7618faecc8fab9edfd83b2b2e0afefda3b Suggested in #529794 2016-11-11T22:39:50Z Edgar Fuß ef@math.uni-bonn.de 2016-11-11T09:20:23Z urn:sha1:324bb34d77a43d1be411c402b2e11f588194439a [Comment from commiter:] I have the feeling that the issue itself is fixed for a while already as nowadays we have testcases involving a webserver closing the connection on error (look for "closeOnError") and no even remotely recent reports about it, but moving the content clearance above the failure report is a valid change and shouldn't hurt. Closes: #465572 2016-11-10T15:39:07Z David Kalnischkies david@kalnischkies.de 2016-11-10T09:37:29Z urn:sha1:e40a4a3e381a8cb6c8b924e9ce545512769bddff The 0.0.0.0:0 tor reports is pretty useless by itself, but even if an IP would be reported it is better to show the user the hostname we wanted the proxy to connect to in the same error message. We improve upon it further by looking for this bind address in particular and remap error messages slightly to give users a better chance of figuring out what went wrong. Upstream Tor can't do that as it is technically wrong. 2016-09-04T20:00:48Z David Kalnischkies david@kalnischkies.de 2016-09-04T16:53:26Z urn:sha1:99fdd8034b4a5cdb0100a33d0b3d5e26079c1695 Commit 3af3ac2f5ec007badeded46a94be2bd06b9917a2 (released in 1.3~pre1) implements proper fallback for SRV, but that works actually too good as the RFC defines that such an SRV record should indicate that the server doesn't provide this service and apt should respect this. The solution is hence to fail again as requested even if that isn't what the user (and perhaps even the server admins) wanted. At least we will print a message now explicitly mentioning SRV to point people in the right direction. Reported-In: https://bugs.kali.org/view.php?id=3525 Reported-By: Raphaël Hertzog 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.