On Fri, Nov 26, 2010 at 10:18 AM, Nathan Freitas <nat...@freitas.net> wrote: > > Any thoughts on running Tor as a shared library within Orbot/Android > versus the way we do it now (command line start/stop with control port)?
So, first off, the obligatory disclaimers apply: It's free software, not a dictatorship, so please don't feel bound by my opinions. :) That said, I don't generally think embedding Tor as a shared library is the best choice, for a few reasons. Here's a _nonexhaustive__ list: * Tor has absolutely zero promised-stable or supported internal APIs. There is no function that we guarantee will exist in the next version. The only interfaces to Tor that we try to keep stable between one interface and the next are the external ones, such as the command line, the torrc format, the control protocol, and so on. * Almost none of the functions that you'd want to call in Tor are documented as safe to call from another thread. So if you want to do most of what Tor controllers let you do, and you try to do it via function calls, you either need to hack up the Tor main loop to make it stop periodically so as to run nonblockingly, or you need to add locking to some admittedly complicated data structures, or you need to accept that sometimes you'll get weird crashes and other misbehavior. * Using process isolation to isolate Tor from its controllers makes it easier to tell Tor bugs from controller bugs. If they're both running in the same process space, and you have a problem with mysterious crashes, it's hard to tell whether the problem is in Tor, the controller, or in the interaction between the two. * Using process isolation to isolate Tor from its controllers can also make it easier to secure each of the two domains properly against bugs in the other, especially if you're using OS or VM sandboxing features. So in summary, the only interface that you've got a prayer of running safely via a JNI call without significant architectural changes is tor_main(int argc, char **argv). All this really gets you is that it makes it slightly easier for you to tell if Tor has exited normally via returning from tor_main... but it means that any Tor crashes, exits(), and assertion failures will crash your controller rather than just crashing Tor. That doesn't seem like a great trade to me. If there's a problem with thinking that Tor is running when it isn't, it's probably better to try to debug those (maybe by probing for process status more often or something) that than to change your architecture to one with new and more exciting issues. just my thoughts; feel free to do differently. peace, -- Nick Mathewson
