[tor-dev] TorPylle: a Python/Scapy TOR protocol implementation

Damian Johnson atagar at torproject.org
Thu Jul 25 15:23:55 UTC 2013


> This part isn't actually true. We review each other's code, and don't
> merge stuff without reviewing it.  Further, Andrea is full-time on the
> tor codebase, just like me.  The code review slows us down a fair bit,
> but we do do it.

My bad then. From interactions on tickets and commit history it simply
seemed like you are far and most the primary person engaged with the
codebase...

atagar at odin:~/Desktop/tor/tor$ git log HEAD~200.. | grep "^Author:" |
sort | uniq -c | sort -rn
    404 Author: Nick Mathewson <nickm at torproject.org>
     40 Author: Andrea Shepard <andrea at torproject.org>
     25 Author: Roger Dingledine <arma at torproject.org>
     20 Author: Mike Perry <mikeperry-git at fscked.org>
     12 Author: Karsten Loesing <karsten.loesing at gmx.net>
     ...

Of course commits are roughly as meaningful as lines of code for
involvement (which is to say, they're meaningless). Just the stat I
had handy. Besides that Andrea hasn't sent a status report since March
so I haven't a clue what she's up to.

> Actually, I think we have a path to get to a less-pure-C Tor
> implementation.  For sandboxing reasons, we'll want to move Tor to
> work as a set of multiple processes that communicate over well-defined
> IPC interfaces via a master process.  Once we get there, it's no
> longer too much to think about doing some of those processes in a
> language other than C.

Neat! I didn't know we had plans around this. Is this on the horizon
or off in unscheduled wishlist territory? If this starts with
descriptor or controller functionality then I'd be interested in
helping.

> (What I'm *not* thrilled about is the idea of using an embedded
> interpreter for this kind of stuff, or embarking on any direction that
> requires us to rewrite too much of the program at once.  That way, in
> my opinion, lies long-term destabilization.)

Understandable, though doesn't avoiding an interpreter drop most
modern languages from consideration (and any sandboxing an interpreter
would provide)? What did you have in mind instead?

Cheers! -Damian


More information about the tor-dev mailing list