<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/test/integration/skip-method-http-socks-client, branch 2.9.1</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=2.9.1</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=2.9.1'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2017-09-26T17:32:15Z</updated>
<entry>
<title>proper error reporting for v3 onion services</title>
<updated>2017-09-26T17:32:15Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2017-09-26T17:27:30Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=f3e34838d95132e5f318e85525326decbfb19e36'/>
<id>urn:sha1:f3e34838d95132e5f318e85525326decbfb19e36</id>
<content type='text'>
APT connects just fine to any .onion address given, only if the connect
fails somehow it will perform checks on the sanity of which in this case
is checking the length as they are well defined and as the strings are
arbitrary a user typing them easily mistypes which apt should can be
slightly more helpful in figuring out by saying the onion hasn't the
required length.
</content>
</entry>
<entry>
<title>improve SOCKS error messages for http slightly</title>
<updated>2016-11-10T15:39:07Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-11-10T09:37:29Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e40a4a3e381a8cb6c8b924e9ce545512769bddff'/>
<id>urn:sha1:e40a4a3e381a8cb6c8b924e9ce545512769bddff</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>implement socks5h proxy support for http method</title>
<updated>2016-08-10T21:19:44Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-08-04T06:45:38Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=61db48241f2d46697a291bfedaf398a1ca9a70e3'/>
<id>urn:sha1:61db48241f2d46697a291bfedaf398a1ca9a70e3</id>
<content type='text'>
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&amp;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
</content>
</entry>
</feed>
