Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3.1 2016-09-04T20:00:48Z 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-08-26T13:49:14Z Julian Andres Klode jak@debian.org 2016-08-23T12:57:11Z urn:sha1:8265d6c8fdc2dd835d9cf2a47af13461fa421389 Gbp-Dch: ignore 2016-08-10T23:34:39Z David Kalnischkies david@kalnischkies.de 2016-08-06T11:53:05Z urn:sha1:8665dceb5cf2a197ae270b08066f05c8a2870223 Doing a direct connect to an .onion address (if you don't happen to use it as a local domain, which you shouldn't) is bound to fail and does leak the information that you do use Tor and which hidden service you wanted to connect to to a DNS server. Worse, if the DNS is poisoned and actually resolves tricking a user into believing the setup would work correctly… This does block also the usage of wrappers like torsocks with apt, but with native support available and advertised in the error message this shouldn't really be an issue. Inspired-by: https://bugzilla.mozilla.org/show_bug.cgi?id=1228457 2016-07-06T13:53:59Z David Kalnischkies david@kalnischkies.de 2016-07-06T12:49:39Z urn:sha1:3af3ac2f5ec007badeded46a94be2bd06b9917a2 Instead of only trying the first host we get via SRV, we try them all as we are supposed to and if that isn't working we try to connect to the host itself as if we hadn't seen any SRV records. This was already the intend of the old code, but it failed to hide earlier problems for the next call, which would unconditionally fail then resulting in an all around failure to connect. With proper stacking we can also keep the error messages of each call around (and in the order tried) so if the entire connection fails we can report all the things we have tried while we discard the entire stack if something works out in the end. 2016-01-05T19:49:19Z Michael Vogt mvo@debian.org 2016-01-05T19:49:19Z urn:sha1:0b7d34ee9dd467b23835377f911af47019d8f713 The PopFromSrvRecs() already removed the entry from the active list, so the extra SrvRecords.erase() was incorrect. Git-Dch: ignore 2015-11-05T11:21:33Z David Kalnischkies david@kalnischkies.de 2015-11-05T01:25:13Z urn:sha1:920c367267398945ff48cac6ea7196f7151f181e AI_IDN is a glibc extension, but we can worry about this at the time actually anyone is seriously trying apt on non-glibc systems. Closes: 763437 2015-11-04T17:42:28Z David Kalnischkies david@kalnischkies.de 2015-11-03T15:05:14Z urn:sha1:23d35ec15a849ee755f51a99939b0131e8faefa5 This flags is generally handy to avoid having to deal with ipv6 results on an ipv4-only system, but it prevents e.g. the testcases from working if the testsystem has no configured address at the moment (expect loopback), so allow it to be sidestepped and let the testcases sidestep it. Git-Dch: Ignore 2015-08-31T15:48:54Z David Kalnischkies david@kalnischkies.de 2015-08-31T15:48:54Z urn:sha1:b830f576a81751f4b04bc889fa82aaca0e6fc3ea Reported-By: gcc Git-Dch: Ignore 2015-08-24T10:39:57Z Michael Vogt mvo@ubuntu.com 2015-08-24T10:39:57Z urn:sha1:c8ec5ab764e90565b58ba5f55f4d9d6939b44c69 Thanks: Julian Andres Klode Git-Dch: ignore 2015-08-20T09:41:51Z Michael Vogt mvo@debian.org 2015-08-20T08:40:45Z urn:sha1:c29dbdffcb6f67812f823f1f844b87320cf6b437 Also add "Debug::Acquire::SrvRecs" debug option and the option "Acquire::EnableSrvRecods" to allow disabling this lookup.