[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Tor as a sort of "library/dependancy" for third party software



On Wed, Sep 28, 2011 at 3:41 PM, Jacob Appelbaum <jacob@xxxxxxxxxxxxx> wrote:
>> p.s. The alternative to provide the same degree of security/usability is
>> to use a Java Applet with file upload+file encryption+silvertunnel as a
>> Tor Client layer.
>
> I don't think silvertunnel is a good idea - the code is based on
> OnionCoffee which has major problems. I would suggest JTor but only
> after a careful audit and some serious work ensuring that it's safe.

Actually, fwiw, when I looked at the silvertunnel code it seemed that
they'd fixed a bunch of the onioncoffee issues.  Your comments still
apply though: both codebases need a lot more auditing before I'd be
comfortable recommending them for the kind of use that Fabio has in
mind.

On the original question: we do not currently support having the Tor
client run in the same address space as another application, nor do we
plan to.  If you've absolutely got to have it be a single executable,
your best option is to link everything except tor_main.c, then have
your program fork and call tor_main().  Don't call any other function:
there is no guaranteed-stable in-process API.

It's an ugly hack, but less ugly than running other stuff in the same
process with Tor.

cheers,
-- 
Nick
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk