Bug#745259: ITP: apt-transport-tor -- APT transport for anonymous package downloads via Tor

[Tim Retout <diocles@debian.org>]

On 22 April 2014 13:10, David Kalnischkies <david@kalnischkies.de> wrote:
> It is also such a trivial modification¹ that I wonder why a fork is
> needed as the required metadata will easily exceed the code changes.
> Just provide a patch which does those settings based on the name of
> the binary called, like apt is handling it for its gzip/bzip2/lzma/xz
> methods and be done with it forever instead of maintaining a fork.
> Or even better just add SOCKS proxy support to the existing methods…
>
>
> Where does it lead us to, when DDs prefer to do forks of Debian native
> packages? I am bit scared of the answer…
> (it explains though why my apt3 in brainfuck is going nowhere. ;) )

Hello. :)

I hope you are not too offended by my fork of this code, since you
gave me the idea last week!  ("Our acquire system is pluggable..." -
https://lists.debian.org/deity/2014/04/msg00075.html )

There are a few reasons I have not yet added SOCKS support to apt properly:

- I would like to backport this feature to wheezy, and I am not so
comfortable uploading a backport of all of apt.
- Adding SOCKS support to the http method means writing a SOCKS client
in C++.  I did spend two days looking at this option, but to be
honest, I'm not even that comfortable with apt having its own HTTP
parser, and would rather rely on libcurl.  I want to prototype a
libcurl-based HTTP acquire method (which should then make this package
more than a trivial modification).
- Even if we add SOCKS support to apt, I can foresee it being
difficult to configure it safely for use with Tor - you need to use:
    - socks5h, so that the proxy does the DNS lookups
    - a username/password, for stream isolation when using IsolateSOCKSAuth
    - probably a standard useragent string (i.e. not one that depends
on the version of apt being used) - I'm still looking at this
  It can be done, but it will be tricky for end users to get right.

So, I think a separate 'tor' method is the way to go for usability
reasons, regardless of whether SOCKS support is added to the other
methods.  I could turn this into a separate binary package built from
the apt source package?  But only if you think it is appropriate for
backporting to wheezy.

What do you think?  I would still like to experiment with a
libcurl-based HTTP method somewhere.

Kind regards,

-- 
Tim Retout <diocles@debian.org>