Re: [tor-dev] Embedding tor in an application and using tor without opening a port

["Fabio Pietrosanti (naif)" <lists@xxxxxxxxxxxxxxx>]

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