On 22 April 2014 13:10, David Kalnischkies <da...@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 <dioc...@debian.org>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/cadc0ge-aykarvqshibw36cbmejses_sfdfd-cvevtbiwxvt...@mail.gmail.com
