[tor-dev] Embedding tor in an application and using tor without opening a port
waldoalvarez00 at yahoo.com
Wed Apr 3 05:49:49 UTC 2013
On Wed, Apr 3, 2013 00:38 EDT Navin Francis wrote:
>It seems like like we are trying to do almost exactly the same thing :)
>You also mentioned that you got Tor working as a visual studio project. I
>was trying to do this myself, but its really a PITA since the Tor
>configuration does not generate a visual studio project and the VC++
>libraries don't play well with the cygwin libraries (I thought that Tor
>only supports cygwin on windows). If your code compiles, I would really
>appreciate it if you can upload it somewhere.
Sure. I did it with visual studio 2010 since cygwin weights a lot and I am over dialup. So just used resources available ;). The solutions + project + instructions will serve to you? I attached the solutions + project. I am looking to upload the rest once I am done. I tested writing and works like a charm but I am using the same thread. Requested www.torproject.org webpage using Tor :). Still gotta make things reentrant. Maybe someone wants to join.
You need to place the files inside the folder win32 and drop the files there. I named it tor-windows-vs2010 but you likely can choose whatever you want for the name.
You will have to change libraries location and header files since I didn't set them relative.
I built all the libraries from source. OpenSSL, libevent and zlib with visual studio as well with nmake using the visual studio console. For OpenSSL you need Perl. Not sure if zlib is ok since I had to try several for gzip support and picked an old one.
If you need help building the libraries just let me know.
Ahh and I had to move some files around. At least curve25519-donna.c I placed it in win 32 directory for Tor 0.2.4.
That should do, but if you hit something just let me know.
>On Mon, Apr 1, 2013 at 9:20 PM, wac <waldoalvarez00 at yahoo.com> wrote:
> Hi Nick:
> > * Using process isolation to isolate Tor from its controllers makes it
> > easier to tell Tor bugs from controller bugs....
> > * 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.
> This is a point I think is valid to consider. Thanks for pointing it.
> However a library is not equal to lack of process isolation. I could have
> the application (for instance the browser) launch a process being a thin
> layer around the library and exchange data using some IPC mechanism. That
> could be a future step.
> >plus maybe another library that would find a running Tor or launch one as
> Is there a standard way of doing this? If not maybe would be good idea to
> define it. A way to know if Tor is running and the listening
> interfaces/ports. Authenticating it if possible, I would not like to have
> malware pretending to be Tor and have it easily steal all my network
> traffic because of this. Perhaps finding the binary somehow and check the
> hash? And avoid malware using Tor as a presentation key to then shut it
> down and replace it. Good questions I think. Maybe this should be just
> configurable by end user instead of doing it automatically until they are
> If platform dependent I think could be defined for each platform.
> > That way we wouldn't have a huge pile of apps all stuck downloading
> their own directory
> I have no intentions to drop cached information, I actually pretend to
> share it as much as possible. Ok is not a perfect world, some will happen.
> Maybe this could be defined as well to allow diverging implementations
> filling other niches than Tor, share already downloaded data or refresh it
> in a cooperative way.
> > Nonetheless, people keep wanting to do it the way you suggest, and it's
> free software, so do what you like.
> Correct, freedom of choice ;). Other ppl is not able to decide what's best
> for me! Anyways recommendations are always welcome.
> tor-dev mailing list
> tor-dev at lists.torproject.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5583 bytes
Desc: not available
More information about the tor-dev