[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
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.
tor-talk mailing list