[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
On Sun, Jan 22, 2012 at 04:11:03PM -0500, Catalin Patulea wrote:
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.
Great to see that you're still around; and I'm happy to see that torcap2 has a license now!
(The correspondence in 2006 was me sending one mail and not getting (or seeing) a response. No worries.)
--Roger
On 1/22/12 10:11 PM, Catalin Patulea wrote:
[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.
Cool, do you have your own github account where to drop-it off?
Otherwise we can import on github and try to engage interested developers in making some modifications?
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..
That's true, even if the main issue may arise when you start using several framework and/or libraries that use their lookup system.
As a couple of additional point: - if you make a mistake, due to a programming error, there's the risk that something get out un-torrified. - if someone is able to break into your web-application force it to run custom python code it would be able to get out un-torrified
The only way to prevent last point is to apply firewall rules, that are still something to be done at low level and may have a lot of different conditions.
So the basic idea is to have a sort of "supervisor" that wrap Python directly, so that all the "Operating Environment" is Tor-Safe and there's no way to exit from it, even in case of compromise.
That way the Python code would be untouched and it would be possible to use: - torsocks on OSX/Linux - TorCap2 on Windows
only doing "system integration" of the tool, that's cheaper than coding modifications and maintaining different customized python lib.
Thanks again for your code, it's precious!
-naif
On Thu, Jan 26, 2012 at 1:07 PM, Fabio Pietrosanti (naif) lists@infosecurity.ch wrote:
Cool, do you have your own github account where to drop-it off?
Sorry for the delay, here it is: https://github.com/cpatulea/TorCap2
Pull requests are most welcome!
-
Catalin Patulea -
Fabio Pietrosanti (naif) -
Roger Dingledine