On 4/2/13 12:09 AM, Nick Mathewson wrote:
My preferred approach for applications that want to include their own Tor would be to have a library (perhaps based on Torsocks) that handles making connections over Tor, plus maybe another library that would find a running Tor or launch one as needed. That way we wouldn't have a huge pile of apps all stuck downloading their own directory information, and we wouldn't wind up with a bunch of forked Tor versions all diverging independently.
Nonetheless, people keep wanting to do it the way you suggest, and it's free software, so do what you like.
While i understand that you do not like this solution we should also acknowledge that there are several condition where "running an independent process" is just not an option and, not having a Tor as a library, represent a limitation.
By design it's required/better to have tor built as a part of the application in the following conditions for example: - if you need to deploy a "Single executable" - if, for security reason, you need a unique application update system - if your application can't startup other applications (for example on App Stores) - If your application have strict signing requirements (for example on App Stores) - if you need a forensically proof application (not writing file around, not being able to use kernel-level disk encryption) - If you can't open listening port on the specific system due to permissions - if you need to do filesystem i/o only on a single application's database file (like a sqlite)
If we would have Tor also workable as a library, IMHO we would have a clean-by-design-from-software-engineering-point-of-view way to use Tor.
Fabio