Package: apt-transport-tor Version: 0.2.1-1 Severity: important Tags: sid stretch X-Debbugs-CC: deity@lists.debian.org Hi, as stated earlier this month in: https://lists.debian.org/deity/2016/08/msg00012.html I would like to discuss the future of apt-transport-tor, rational: On Thu, Aug 04, 2016 at 06:08:26PM +0200, David Kalnischkies wrote: > back in 2014 then apt-transport-tor was introduced it started as > a pretty straight copy of apt-transport-https with the reasoning of > being able to backport it (#745259). > > It is two years later now with an eye on the upcoming stretch, so > backporting shouldn't be an argument much longer, which raises the > question if we need to carry a by now two years old copy[0] of apts > https method into the stretch release. […] > [0] no security bugs per-se, but even https gets bugfixes/features. The > method is e.g. run as root while our http/https runs as _apt nowadays. I have by now implemented and merged everything I "threated" to do into src:apt to allow the included 'http' and 'https' methods to be called 'tor+http' and 'tor+https' respectively and do the right thing. If you have apt (>= 1.3~rc1) and tor installed you can actually test this virtually adding the methods by creating a config file in /etc/apt/apt.conf.d/ containing: Dir::Bin::Methods::tor+http "http"; Dir::Bin::Methods::tor+https "https"; It is possible then to use tor+http: and tor+https: in your sources and apt will do the right thing™ talking via socks5h to the local tor instance. Beside bugs which have surely sneaked in the differences to a-t-t are: > - tor+https options consistently fall back to tor -> https -> http > - tor+http options consistently fall back to tor -> http > - socks5h isn't forced. It is just the default (and the only one which > will work with (tor+)http at the moment; any with tor+https) > - a tor-proxy having apt-transport-tor as username & no password > (default) will automatically pick a password based on the target > host to get you in a new circuit for each host. > - the User-Agent isn't forced to an all-tor-users-have-the-same value. > Especially with tor+http being our normal http I think its better to > "hide" between other http users than saying straight that you are > a tor user (even if the IP gives it away that you are). > - tor+https doesn't allow redirection to tor+http. We have this for > a while for https -> http already (-tor "broke" it). I think if a user > went as far as configuring a https source it should stay an https > source or fail. - http/https can be disabled to avoid accidentally adding such sources - http will not try to connect to .onion domains (RFC7687) and the error hints at using tor+http - and as already mentioned: the methods run as _apt instead of root Now that sounds like I would have the intention to shallow a-t-t as a whole, but I actually think it should remain a separate package (but perhaps under the APT team umbrella) because: > So, assuming we can agree on that this is in general a good idea, this > would leave apt-transport-tor relatively empty (expect three symlinks, > a depends on apt and a recommends on -https & tor) but perhaps this > frees resources for a-t-t to gain an option to turn all sources into > tor+http(s) [with debconf] or even .onion addresses, additional > documentation… instead of diverting energy into maintaining an -https > fork. I haven't got a whole lot of feedback on this, but so far no NACKs so by recording this in a bugreport I hope to reach (again) out to people who might have different ideas on how to solve what basically is a modified embedded codecopy (of a Debian native tool none the less) which in terms of stretch should be considered release-critical as that codecopy is running with root rights and talking to the internet – I don't intend to escalate it to RC just yet through as its summer/holiday season, but just so we have a rough timeframe: I am going to in a months time if noone is stopping me… Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature