Hi, On Wed, Nov 15, 2017 at 01:00:33PM +0100, Petter Reinholdtsen wrote: > What do you think of the idea? Would you like to maintain such script > as part of the apt-transport-tor package? I see a few independent tasks here, some of them for deity@, some we would likely need to discuss with a wider audience in case someone wants to work on them: 1. easy way of exchanging mirrors We talk about that in the apt context once in a while, there is probably a bugreport for it I can't find at the moment & I have thought a few times about it, but never really done anything about it yet. The general premise is that it isn't too unusual to want to switch mirrors (be it ftp → http, being somewhere else on earth for a while, …) which at the moment isn't very hard as you just have to edit (a few) files, but looses you all data you have already downloaded for the old mirror which could have been reused instead of discarded (not just for saving on bandwidth, but some security features [obviously] only work if you have data for that repository already). 2. identifying which mirror is which repository It is relatively clear that a primary is a debian mirror, but what about secondary (and further) mirrors? Ideally you should be able to say: Change all Debian (optionally: stable main arm64) mirrors to X. We have the data in the Release files and apt 1.5 is complaining about changes there so we can actually end up relying on them for pinning and stuff. There are other things where it would make sense to be able to define a mirror by the data served rather than the url it has, so ideally it can be reused and hence that is mostly an interface designing job. 3. have a way of read, modify and write .list and .sources files We have some very brittle parts here e.g. for cdrom://-using sources, but nothing which could really convert between the two formats or do modifications without potentially removing comments or the like. (In the example from above, if you have a mirror for i386 and arm64 at the moment, but only want to switch the arm64 to something else tooling needs to "duplicate" the entry first before it can be changed – but that might be something better left for v2 and the better example for v1 might just be: change all stretch to buster). 4. Have an authoritative way of non-onion to onion URI (and back) onion.debian.org is authoritative for Debian mirrors I guess, but while I have no problem parsing an online source for my own silly experiments [0] I have my doubts its a clever idea to do that for everyone (even if we ignore for a moment that https isn't perfect & assuming we have access to a more stable list than parsing HTML). The README lists a few onions to give users pointers, but I am not sure I (or the rest of the apt team) want to be the authority on which onion mirrors to use. And then there is the "simple" problem of which services to include: Debian: yes, TorProject: yes, 200 different derivatives: okay?, hundreds of 3rd party repositories: maybe, the odd controversial ones where usage might be illegal in some jurisdictions or a flamewar-rage-fork-of-the-day: uhm… can we let the DPL decide by fair dice roll? Changes in this also tend to be outside of a stable release schedule so that would require regular stable updates/backports… The solution might be that any repository contains a list of all known mirrors of itself (solving 2 + 4). That could also turn out useful if a user runs into a stall/broken mirror and we can just suggest a (random) alternative rather than say: "That one is broken. Please query your preferred search engine for an alternative." It is at least something I am toying around in my head at the moment to solve some slightly related issues. So yes, I am in general very interested in making using apt + TOR easier, but I would like to avoid 'quick' "hacks" here as those tend to bite us back rather regular in apt. Armed with (some of) the above we could roll a script and even do some debconf questioning on install without turning into a central onion-service authority with high maintainance attached. If someone wants to work on any of this feel free to talk to us (before splitting the bug up, a bit more thought would need to be put in & the bugreport as is has a name good enough to catch the attention of anyone remotely interested I would hope). Best regards David Kalnischkies [0] https://github.com/DonKult/fixTheInternet/blob/master/background.in/onion.debian.org.sh
Attachment:
signature.asc
Description: PGP signature