[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Mergeback of apt-transport-tor into apt?


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

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:

Attachment: signature.asc
Description: PGP signature

Reply to: