[resending after subscribing to list]
Hi Fabio,
On 1/22/12 11:28 AM, Roger Dingledine wrote:
See also TorCap2: http://www.virtualventures.ca/~cat/ but I've never succeeded at getting a license statement out of the author.
Roger, I'm sorry if I seemed uncooperative when you asked about the licensing terms of TorCap2. I can see a reference to a discussion with you back in 2006, but I no longer have copies of the actual correspondence, so I don't recall what happened.
Can you confirm whether the TorCap2 is licensed under BSD, GPL or other opensource license?
I have released TorCap2 under the LGPL 3.0 (I have updated the readme and included a license.txt in the zip files). You can use TorCap2 as-is in an application of any license. Any modifications to TorCap2 must be published under the LGPL.
at some Tor related Project we would like to use TorCap2 as a part of an OpenSource Project whose concept is described at https://piratenpad.de/p/AnonymousWebApplicationFramework .
On a technical note, I doubt that TorCap2 is the right approach here. If you can limit yourself to support Python-only applications to start, then a SOCKS client in Python that implements the same interface as the 'socket' module seems like a much cleaner solution to me. This is now platform-independent, less complex (easier to debug), and gives the Python code the *option* between native sockets and Tor-ified sockets, under the same interface. (maybe you want to check connectivity.. or find the hosts's external IP by fetching a URL.. or talk to hosts on the local network.. etc.)
Porting existing Python code would be a matter of search-replacing 'socket' with 'torsocket' (or even just 'import torsocket as socket'). Of course, with this design you would leak network traffic if you spawned a separate process, or if you used a Python native library that directly accesses the OS's socket API. But maybe it's good to start with supporting Python-only applications initially, given the complexity of Win32 API hooking..
Just my $0.02..
Catalin