[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: When should we https our mirrors?



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.

Attachment: signature.asc
Description: PGP signature


Reply to: