Re: Android: Tor shared library vs exec binary?

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Fri, Nov 26, 2010 at 10:18 AM, Nathan Freitas <nathan@xxxxxxxxxxx> 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