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

Bug#835128: Mergeback of apt-transport-tor into apt?

Package: apt-transport-tor
Version: 0.2.1-1
Severity: important
Tags: sid stretch
X-Debbugs-CC: deity@lists.debian.org


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

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

Reply to: