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 _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
