On Fri, Sep 03, 2021 at 02:42:29AM +0000, Paul Wise wrote: > httpredir.d.o was an alternative CDN-like thing that was based on HTTP > redirects to the mirror network. It had lots of problems, but now that > we have a mirror checker and zzz-dists, perhaps it could work better. > The mirror:// method in apt has probably improved since then too. If you wanted to bring back a httpredir-like¹ you are better of to combine both approaches as in: Have apt request a list of mirrors to use via mirror(+https) and have the server generate that list based on the requester as that gives you the "regional" mirrors as did httpredir while solving the major grip it had by having a list of mirrors to use, rather than one potentially non-working slightly outdated partial mirror (and the httpredir service is contacted by each client once rather than for each individual file to then be redirected elsewhere). Obviously, that approach is only workable if you are actually using libapt tools. Most debootstrap implementations couldn't really use that which might or might not be a problem for a given use case. Such a service would also have a hard time to 'redirect' you to a local mirror in your network (compared to an 'official' region one). So that isn't really what seems to be the main worry here: https prevents MitM attacks including the friendly MitM ones like the local network at home/at DebConf telling my laptop that there is an on-site mirror or not telling at all and just proxy transparently the entire network. The later seems done for in a https-world, but the former might be somewhat salvageable: We will have to get the Release² file(s) from the repo defined in the sources, but the index files and debs after that are a fairer game to get from elsewhere as they are either identical with what the defined source would have provided or a hard error. That still violates the privacy guarantees https has (assuming it does), so that would still need to be opt-in/out, but that is a one time choice per machine and could be similar in style to auto-apt-proxy. Anyway, implementation wise apt could tell $MAGIC which repo it is interested in (by Origin & Label) and would in return get a list of mirrors as apt-transport-mirror would. apt would then add the original source as least priority fallback and proceed with that list for this source. I say $MAGIC as I don't want apt to hard code the specifics of how to get the list, similar to how it is agnostic to how a proxy is currently picked up, as I could envision different implementations depending on use cases. That is different to just using apt-transport-mirror directly in the sources in so far as the provider of the list remains untrusted (beside that nobody is constantly editing their sources to adapt to the local network the machine currently resides in). Relatively quickly thought up, probably full of holes and not implemented at all in apt so far, but if someone thinks that might work feel free to report as a feature request against apt and I will see what I can do from the apt side. It at least seems slightly more workable than hoping to prevent https – which might have just as dubious a chance to succeed as https has to factually improve security in terms of apt. 😜 > Maybe http redirects to local mirrors could be feasible again, but it > would take a lot of work. fwiw: apt does not allow https to http redirects (some https repos ran into this in the past like those hosted on sourceforge until they fixed their https 'everywhere' configuration). In this regard apt is stricter than a normal webbrowser (a mirror list acquired via https can redirect to http mirrors though, but see the man pages for details). Best regards David Kalnischkies ¹ which deb.d.o sort of is just that it is nowadays done via SRV instead of an explicit HTTP redirect – and that only one mirror is in the list rather than multiple httpredir had picked one to redirect to. ² The main security benefit of https for apt is that you can't fiddle with the Release file, mostly in terms of sending an older one (in the limits of Valid-Until if used). It is also minor in size compared to the indexes and especially the debs, so caching them is not much of a concern (if a cacher was even doing it, it probably shouldn't).
Attachment:
signature.asc
Description: PGP signature