Re: [tor-talk] torsocks is broken and unmaintained

[grarpamp <grarpamp@xxxxxxxxx>]

> On the other hand the "protocol audit" mess is even worse.

This 'mess' doesn't seem to have anything to do with Tor,
nor is it Torproject's responsibility to do any such audit
on any app other than Tor itself, or by extension those it
maintains or chooses to partner with.

As said before, torsocks/proxychains/etc are just hooks
invented to catch certain types of network system calls
so you don't have to go around patching a socks5 client
into thousands of apps that should have had it anyways
or deploying packet rules and jails.

Yes, it would be great if all apps supported an optional:
'./app --socks5=host:port' argument.

But if the app speaks anything other than TCP + UDP-DNS,
trying to get it to work with Tor is useless anyways. And
that's not Tor's problem either.

Yes, you can run Tor+ocat, or Phantom, or i2p+ocat. At which
point you give up exit functionality to gain a useful new
hidden world.

The solutions to this faux 'mess' are exactly what people
are doing today:
- Beg the app coders to put and maintain socks5 in the apps
that use just TCP + UDP-DNS. Also beg apps to be able
to bind to a specific address, not just '*'.
- Use packet filters and jails to redirect everything.
- Make sure preloads do something with all possible calls(2).

You don't need a 'Tor lib' because:
- All it would do is effectively what a preload does via socks5,
because you haven't cited an application use for any of the
native Tor functions such a lib would bring to an app.
- You can probably make do with the features Tor is growing
regarding multiple SocksPort's.
- You still need the app coders to code in the bits for
'./app --tor=host:port' and such enhanced functions anyways.
- You're still limited to TCP + UDP-DNS.
- And it makes no sense to have this Tor lib be full enough
to talk to Tornet without the separate Tor daemon, it's just
not efficient beyond one instance.

And that's just at the network layer. The payload layer address
gotchas (ie: FTP, torrent) aren't Tor's responsibility either.

>> I2P is a bit hard to use with your app of choice, even Tor is that
>> way in some cases.

> I suspect being based on Java is a major show stopper.

The problem is not Java. It's that with the sole (known?) exception
of Phantom and its native IPv6 interface, the rest of the entire
anonymous network space has not been designed (lack of thought
due to forebearing art?) to allow common apps to bind to and route
packets in and out of them. Nothing you can do in the long run but
redesign the front end those networks expose to the user. And to
further redesign their insides if you want exits and/or exit binds.
Because expecting the world (IETF, POSIX, etc) to change its
protocols for you and your secret internets just isn't going to
happen anytime soon :)

> There are actually more applications designed for i2p than
> designed for Tor.

I would question if it's not better to put those coding resources
towards making the above changes in anon networks and/or
towards spreading them across the already written popular apps
in order to make them work with the anon networks.

> Look into the TorifyHOWTO.
> https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO

I don't agree with telling everybody using Unix command line email
software is 'old advice' and that they should instead use webmail.
Of course if I thought said software was going to go down some
rare case code path and fire off a SOCK_RAW, it would be different.
But we know that's not the case with this class of software.
Only with your popular windows binary app of the day, and trojans,
for which Tor is again not responsible to check for.
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk