Re: Replacing apt's http method (dropping curl)
On 6/27/17 2:00 PM, Julian Andres Klode wrote:
> Hi everyone,
>
> as we discussed before in IRC, we plan to eventually replace
> our existing curl-based https method with our http method,
> by adding TLS support to it. This will move HTTPS support
> into apt proper, removing the apt-transport-https package.
>
> I'm not sure how long this will take, I hope we get something
> useful next month.
>
> Rationale
> =========
> * The https method is split out of apt because curl has a lot
> of dependencies (29 vs 7 on my test setup, 15.9 vs 4 MB of
> disk space)
> * We want https to be a default these days, even if it provides
> only minor security improvements.
> * Our http method is actually tested a lot because it is the
> default and supports advanced features, the https method just
> does curl easy stuff sequentially.
>
> Transition plan
> ===============
> I plan to do this in two stages, both of which I expect to
> happen in unstable if all features have been implemented
> quickly. There might be feature-incomplete alphas in
> experimental.
>
> In the first stage, the "https" method is renamed to
> "https+curl", and a https->http symlink is added in apt.
>
> If no significant regressions are reported (we might drop
> some options or increase some checks), and the package has
> been in testing for some time, the apt-transport-https
> package is removed.
>
> This ensures that (a) we get proper testing and (b) users
> have a workaround if something fails in that testing period.
>
> Implementation
> ==============
> I so far implemented basic https support using GnuTLS, including
> SNI and certificate validation, and one (!) local CA file (as our
> tests need that). The code is incredibly hacky right now. And
> https->http redirects don't work yet.
>
> Alternatives would be to use libnss or openssl. In the latter
> case, we'd have to build a separate helper binary that does not
> link to the GPLed code, and just unwraps a TLS connection into
> a pipe (similar to stunnel) - we could also use a helper generally,
> it would allow us to run the TLS stack as nobody (!!!) [OK,
> we have to open the socket in the parent process and pass it
> down to the TLS stack, so _apt opens the connection for firewalls].
>
> The existing shitty proof of concept is available on GitHub:
>
> https://github.com/Debian/apt/compare/master...julian-klode:feature/http-https?expand=1
>
> But as I said it's ugly. It also does not yet link the http
> binary to the https binary.
>
This may not be the place or time to ask this but will https work with
apt-cacher-ng? Most caches just pass the data through them and can't store the
original files like apt-cacher-ng can. Would the local machines connect to
ap-acacher-ng over http and apt-cacher-ng connect to the debian mirrors using
https? Or could the apt-cacher-ng install generate a local certificate that the
local machines could be set to accept as a valid debian cache/mirror and have
apt-cacher-ng use https to the debian mirrors?
...Bob
Reply to: