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

[Nick Mathewson]

On Thu, Jul 25, 2013 at 5:23 PM, Damian Johnson <atagar at torproject.org> wrote:
>> 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.

Somewhere in the middle.  The sandboxing is now; the partitioning is
"not too long I hope"; the multiprocess-transition is "after that, as
possible"; and the reimplementation of bits and pieces is "time
permitting, as relevant."

>> (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?

What Brandon said here, plus I'm not opposed to an interpreter, but an
_embedded_ interpreter (that is, one running in the same process space
as all the rest of the Tor code).

yrs,
-- 
Nick