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