On Mon, Oct 24, 2016 at 07:26:37PM +0200, Tollef Fog Heen wrote: > ]] Paul Tagliamonte > > On Mon, Oct 24, 2016 at 04:00:39PM +0100, Ian Jackson wrote: > > > It is also evident that there are some challenges for deploying TLS on > > > a mirror network and/or CDN. I don't think anyone is suggesting > > > tearing down our existing mirror network. > > > > https://deb.debian.org/ is now set up (thanks, folks!), so my attention > > is now shifted away from the push to https all the things (not everyone > > will, so I just want a stable well-used domain that could be a sensable > > default, and let those who don't want to move forward stay in the past) > > and on to considering the apt https transport and thoughts on how this > > could become part of the base install. > > Note that the performance of HTTPS there is worse than for HTTP due to a > lack of SRV support in apt-transport-https, though, which means it falls > back to doing HTTP redirects.
(as apt-transport-https is mentioned I have to comment again…) It should be only one redirect with apt >= stretch for indexes. For the *.debs its a redirect each. APT doesn't store redirects between runs as its hard to keep that current and authoritative (obvious for http, slightly less obvious for https perhaps). The SRV support needs to be implemented in (lib)curl as I wouldn't feel to comfortable working around this [0]. Or, well, implement TLS in apt directly, but I already mentioned how likely I think that is, but if anyone wants to try… And as already mentioned pipeline support in a-t-https would be nice if someone feels like implementing it via curls multi-interface. If someone is exceptionally bored we could implement an opportunistic use of https if a-t-https is installed and "_https._tcp." srv-lookups get a favorable response by letting http ask for that first and internally redirect in that case. So, you see, as usually, there isn't a shortage on ideas. If someone wants to work on any feel free to join deity@ and/or #debian-apt. Best regards David Kalnischkies [0] which isn't exactly easy and could only be considered a hack as you can't take over resolving for curl, you could just misuse a facility for DNS caching to feed it an IP, but you first need to establish that this IP and port can be connected to, disconnect and hope a "reconnect" in curl will be equally successful later on as making sense of error codes isn't exactly easy either…
signature.asc
Description: PGP signature
