Hi, 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. I would like to avoid that and hence spent some time on generalizing the https implementation enough to have it load and fallback its config based on the binary name(s) its called with which elimates the biggest churn the tor-copy had. I also implemented socks5h support[1] in our http method (https has it anyhow – if we would enable it…) so that at least tor+http could be supported out-of-the-box [it also brings features like HTTP pipelining, which we haven't managed https to perform yet – curl supports it with the proper multi-dance, it's just that nobody has done that yet]. Beside bugs which have surely sneaked in the diff[2] also contains: - 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-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. 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. So, long story short: What is the interweb thinking about this? Best regards David Kalnischkies [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. [1] basic. Doesn't implement the required GSSAPI auth method, but good enough to be used with Tor as that doesn't really need auth at all, so the implemented user&pass auth is already a bonus point. SOCKS4 support wouldn't really be hard I would just prefer patches to appear if that is really needed. [2] early post-PoC state with "takeover" commit I needed for testing, not intended to be part of a final patch series: https://git.kalnischkies.de/apt/log/?h=wip/tor
Attachment:
signature.asc
Description: PGP signature