[tor-dev] Torsocks reengineered

[David Goulet]

Hi everyone,

About a week ago I've sent an email to the Torsocks maintainers to
address some concerns I had about important issues of the current code
base. For the reasons found below, I proposed a rewrite that I am
willing to do and submit it to the community once I feel ok with it.

After some back and forth, the consensus was that I should go ahead and
do it. Best case scenario, I come up with a tested library that has a
smaller set of problems (hopefully) and could eventually be considered
to replace the current version. Worst case, I lose my time :).

Now, I'm not looking to do that alone in my corner or anything, what I
want is this effort to be as open as possible for everyone that want to
help, contribute or/and follow it. Some help would be really appreciated
for the compat. part (Windows, OS X, BSD, etc...).

Here is the repository I've created and started working on the rewrite.
It has been branched from upstream master at commit
e0bf65b5d3ca0e28b827c08d80b0fe1841d5a149

	https://github.com/dgoulet/torsocks/tree/rewrite

There might be some rebasing going on in that branch in the next weeks
so please don't consider it right now as "git stable" since I'm in the
heavy part of getting everything together before starting a "normally
growing" master branch. If you like to contribute or help, let me know
and we'll make something work.

Big thanks to nickm, ioerror and sysrqb for their help on all this.

Cheers!
David

Torsocks rewrite reasons:
---------------

(You can see that as either we put in 2000 lines of code to fix it in a
~3000 lines repository or we start fresh with some key aspect,
maintainability and security in mind.)

Code and Maintenance Issues:

1) The code needs to be easier to maintain, so that it isn't
sporadically maintained. Considering the number of issues (see below),
it needs more love on a regular basis right now.

2) It has never been safe from the start so a rewrite will NOT impact
the current state of security. There is not much tests right now.

3) Small code base. Fix it clean before it gets too big.

4) One of the biggest technical issues is that it's not thread safe and
fixing it right now would add an important impact on performance adding
locks to multiple global data structures. A clean rewrite would allow to
take into account this *very* important feature from the start without
any ugly hacks in the current code base.

5) This is a very, and I can't stress this enough, _VERY_ intrusive
library so extra care MUST be put in making it bullet proof in terms of
error handling. Right now, there is multiple call sites that can fail on
error.

6) There is not even close to enough tests, thus not loosing that stable
portion of a project.

7) No compatibility layer is present for multiple OS and architecture.

8) FD passing through Unix socket support.
* Should at least be detected and notify the user or even deny execution
since the process receiving the socket is not under torsocks control.

9) Symbol name space polluted. (should all be prefixed).

10) Libc hijacked calls of torsocks don't return correct values in error
path.
* This is bad because for instance the caller expect errno to be set and
makes decision upon that value that MUST be right once returned. There
is multiple call sites that are problematic.

11) IPv6 support.
----------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130603/70f65cd6/attachment.pgp>