Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_rc2 2016-08-10T23:34:39Z 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. 2015-08-18T13:41:02Z Michael Vogt mvo@debian.org 2015-08-18T13:41:02Z urn:sha1:cdeb54d4626ddc841d8898a8283084a8de3b25ee 2014-05-23T14:46:32Z Michael Vogt mvo@ubuntu.com 2014-05-23T14:46:32Z urn:sha1:cc4800145b408de0b4afef88f4489a541024e75a