<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/methods/http.h, branch 1.6_beta1</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.6_beta1</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.6_beta1'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2017-12-13T22:56:29Z</updated>
<entry>
<title>report transient errors as transient errors</title>
<updated>2017-12-13T22:56:29Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2017-10-25T22:57:26Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=47c0bdc310c8cd62374ca6e6bb456dd183bdfc07'/>
<id>urn:sha1:47c0bdc310c8cd62374ca6e6bb456dd183bdfc07</id>
<content type='text'>
The Fail method for acquire methods has a boolean parameter indicating
the transient-nature of a reported error. The problem with this is that
Fail is called very late at a point where it is no longer easily
identifiable if an error is indeed transient or not, so some calls were
and some weren't and the acquire system would later mostly ignore the
transient flag and guess by using the FailReason instead.

Introducing a tri-state enum we can pass the information about fatal or
transient errors through the callstack to generate the correct fails.
</content>
</entry>
<entry>
<title>allow the auth.conf to be root:root owned</title>
<updated>2017-07-26T17:09:04Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2017-07-07T20:21:44Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=881ec045b6660e2fe0c6953720260e380ceeeb99'/>
<id>urn:sha1:881ec045b6660e2fe0c6953720260e380ceeeb99</id>
<content type='text'>
Opening the file before we drop privileges in the methods allows us to
avoid chowning in the acquire main process which can apply to the wrong
file (imagine Binary scoped settings) and surprises users as their
permission setup is overridden.

There are no security benefits as the file is open, so an evil method
could as before read the contents of the file, but it isn't worse than
before and we avoid permission problems in this setup.
</content>
</entry>
<entry>
<title>http: Add support for CONNECT proxying to HTTPS locations</title>
<updated>2017-06-30T13:00:41Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2017-06-30T11:24:04Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=64207dad49f1c803d2b004ccf8fc6432789a8cc2'/>
<id>urn:sha1:64207dad49f1c803d2b004ccf8fc6432789a8cc2</id>
<content type='text'>
Proxying HTTPS traffic requires the proxy providing the
CONNECT method. This implements the client side of it,
although it is a bit hacky.

HTTP connect is a normal HTTP CONNECT request, followed
by a normal HTTP response, just that the body of the
response is the TCP stream of the target host.

We use a special wrapper in case there are data bytes
in the header packets - in that case, the bytes are
stored in a buffer and the buffer will be drained first,
afterwards the connection continues directly with the
TCP stream (with one more vcall).

Also: Do not send full URI to https destinations when proxying,
as we are directly interfacing with the destination data stream.
</content>
</entry>
<entry>
<title>methods: connect: Switch from int fds to new MethodFd</title>
<updated>2017-06-28T13:52:38Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2017-06-28T08:55:08Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=5666084ecfe140aaa3f89388de557c2f875b4244'/>
<id>urn:sha1:5666084ecfe140aaa3f89388de557c2f875b4244</id>
<content type='text'>
Use std::unique_ptr&lt;MethodFd&gt; everywhere we used an
integer-based file descriptor before. This allows us
to implement stuff like TLS support easily.

Gbp-Dch: ignore
</content>
</entry>
<entry>
<title>rename ServerMethod to BaseHttpMethod</title>
<updated>2016-12-31T01:29:21Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-12-09T14:13:09Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=d8617331afc39281d5925033975b6097128786f4'/>
<id>urn:sha1:d8617331afc39281d5925033975b6097128786f4</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>separating state variables regarding server/request</title>
<updated>2016-12-31T01:29:21Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-11-09T11:25:44Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=13a9f08de18dea0dfc1951992b0ddeda9c2fa2dd'/>
<id>urn:sha1:13a9f08de18dea0dfc1951992b0ddeda9c2fa2dd</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>reorganize server-states resetting in http/https</title>
<updated>2016-08-16T16:49:37Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-08-11T14:59:13Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ebdb6f1810a20ac240b5b2192dc2e6532ff149d2'/>
<id>urn:sha1:ebdb6f1810a20ac240b5b2192dc2e6532ff149d2</id>
<content type='text'>
We keep various information bits about the server around, some only
effecting the currently handled file (like sizes) while others
should be persistent (like pipeline detections). http used to reset all
file-related manually, which is a bit silly if we already have a Reset()
method – which does reset all through –, so extending it with a
parameter for reuse and calling it from https too (as this was
previously resetting by just creating a new state struct – it uses no
value of the persistent state-keeping yet as it supports no pipelining).

Gbp-Dch: Ignore
</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>
<entry>
<title>implement generic config fallback for methods</title>
<updated>2016-08-10T21:19:44Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-31T16:05:56Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=30060442025824c491f58887ca7369f3c572fa57'/>
<id>urn:sha1:30060442025824c491f58887ca7369f3c572fa57</id>
<content type='text'>
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 -&gt; https -&gt; http for https sources. With this config
infrastructure this could be implemented now.
</content>
</entry>
<entry>
<title>use the same redirection handling for http and https</title>
<updated>2016-08-10T21:19:44Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-08-02T12:49:58Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=4bba5a88d0f6afde4414b586b64c48a4851d5324'/>
<id>urn:sha1:4bba5a88d0f6afde4414b586b64c48a4851d5324</id>
<content type='text'>
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.
</content>
</entry>
</feed>
