Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_rc1 2016-08-10T23:34:39Z 2016-08-10T23:34:39Z David Kalnischkies david@kalnischkies.de 2016-08-06T20:54:31Z urn:sha1:0568d325ad8660a9966d552634aa17c90ed22516 With apts http transport supporting socks5h proxies and all the work in terms of configuration of methods based on the name it is called with it becomes surprisingly easy to implement Tor support equally (and perhaps even a bit exceeding) what is available currently in apt-transport-tor. How this will turn out to be handled packaging wise we will see in https://lists.debian.org/deity/2016/08/msg00012.html , but until this is resolved we can add the needed support without actively enabling it for now, so that this can be tested better. 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-08-10T21:19:44Z David Kalnischkies david@kalnischkies.de 2016-08-04T06:45:38Z urn:sha1:61db48241f2d46697a291bfedaf398a1ca9a70e3 Socks support is a requested feature in sofar that the internet is actually believing Acquire::socks::Proxy would exist. It doesn't and this commit isn't adding it as that isn't how our configuration works, but it allows Acquire::http::Proxy="socks5h://…". The HTTPS method was changed already to support socks proxies (all versions) via curl. This commit implements only SOCKS5 (RFC1928) with no auth or pass&user auth (RFC1929), but not GSSAPI which is required by the RFC. The 'h' in the protocol name further indicates that DNS resolution is delegated to the socks proxy rather than performed locally. The implementation works and was tested with Tor as socks proxy for which implementing socks5h only can actually be considered a feature. Closes: 744934 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-08-10T21:19:44Z David Kalnischkies david@kalnischkies.de 2016-08-02T12:49:58Z urn:sha1:4bba5a88d0f6afde4414b586b64c48a4851d5324 cURL which backs our https implementation can handle redirects on its own, but by dealing with them on our own we gain finer control over which redirections will be performed (we don't like https → http) and by whom so that redirections to other hosts correctly spawn a new https method dealing with these instead of letting the current one deal with it. 2016-08-10T21:19:44Z David Kalnischkies david@kalnischkies.de 2016-08-02T20:44:50Z urn:sha1:57401c48fadc0c78733a67294f9cc20a57e527c9 Having the detection handled in specific (http) workers means that a redirection loop over different hostnames isn't detected. Its also not a good idea have this implement in each method independently even if it would work 2016-08-10T21:19:44Z David Kalnischkies david@kalnischkies.de 2016-08-03T19:17:26Z urn:sha1:ece81b7517b1af6f86aff733498f6c11d5aa814f Closes: #623443 2016-08-10T21:19:44Z David Kalnischkies david@kalnischkies.de 2016-07-31T16:46:34Z urn:sha1:d415fc795a69d6a5039964e88f97561183d6ab44 2016-08-10T14:17:19Z Julian Andres Klode jak@debian.org 2016-08-09T15:40:01Z urn:sha1:c85c4bed0a4b32ee2dcbd86ea819e39f3d8beb84 Bye, bye, old friend. 2016-08-06T20:36:02Z Julian Andres Klode jak@debian.org 2016-08-06T19:03:43Z urn:sha1:f3de2dbaf657f9040a4da448c57267de0fef7d33 Introduce an initial CMake buildsystem. This build system can build a fully working apt system without translation or documentation. The FindBerkelyDB module is from kdelibs, with some small adjustements to also look in db5 directories. Initial work on this CMake build system started in 2009, and was resumed in August 2016.