On Mon, Oct 17, 2016 at 08:48:57PM +0200, Cyril Brulebois wrote: > should revisit this setup when I find more time. There's also Pipeline- > Depth option's being advertised as not supported for https, too.
Yes. apt-transport-https is on a pretty low priority maintainership wise which if combined with a cronically understaffed APT team isn't the best setup for major development work as the scare resources could be better invested in transports which are actually used… The missing pipelining is due to our use of the simple API. We would need to switch to the multi API with its added complexity. Note that the apt acquire system itself deals with most of what is done by "multi" (as in parallel connection to different hosts and such) so I guess a non-trivial amount of code would be dealing with 'reverting' the multiness of libcurl so that it isn't interferring with apts or perhaps we already have that (as we take over redirect handling for example) – someone would need to investigate… Pipelining isn't the only missing feature through. curl does not support SRV records (like many other web clients) which is quite handy for deb.d.o and the mirror network in sofar as you can declare fallbacks a lot easier this way (as in you can have them always set instead of reacting to emergency calls). In case someone wonders why curl or why the -gnutls variant: APT code is GPL2+ and the current implementation is heavily intwined with many apt parts. At least one past contributor denied adding an OpenSSL exception back then that was the 'default' curl variant (and some more never replied to the private inquires), so don't even think about relicensing to gain access to other variants/libraries. Someone could of course do a clean-room implementation (even in whatever language you want) as apt uses a text protocol to talk to the transport processes. Some day I might implement a stunnel<->http-based https just for the lulz. How realistic it is that a clean-room implementation would be solving both the "bloat" and "maintainance" problem is left as an exercise to the reader. Best regards David Kalnischkies P.S.: There are various arguments why -https is in terms of mirrors – as their content is static and public knowledge – more an obfuscation rather than 'real' security/privacy enhancement. If you want more/better have a look at apt-transport-tor and onion mirrors. The setup is as painless as -https: Install the package and change sources.list.
signature.asc
Description: PGP signature
