add Tor client plugin

[dawuud]

Much like ticket #242, this ticket aims to create a foolscap client transport plugin. The Tor client plugin should be highly configurable yet work with a best effort if the user supplies zero parameters. It could potentially launch tor if a tor binary is present in the path... or use the system tor if a socks or control port is specified.

[dawuud]

Furthermore this plugin could eventually share state with a server plugin... so that the same tor process is used for both plugins.

[Brian Warner]

the logging fixes (#244) take priority, pushing this out a release

[Brian Warner]

Milestone renamed

[dawuud]

here's my latest dev branch containing a socks client plugin for foolscap: ​https://github.com/daira/foolscap/commits/tor-client-plugin.2

i've tested it with the corresponding dev branch in tahoe-lafs as documented in ​https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517#comment:68

daira has reviewed it... perhaps further review or merge?

[dawuud]

closing this ticket; use https://foolscap.lothar.com/trac/ticket/242 intead

[dawuud]

oh i see. more than just socks; we want detection of tor, auto-launch, best effort to find a socks or control port etc. sounds good to me. I guess we should do this after first getting a simple socks client plugin working in #242.

[Brian Warner]

BTW, I'm going to change the API of IConnectionHintHandler.hint_to_endpoint to allow it to return a Deferred (that fires with a tuple of (endpoint, host)) instead of requiring it to return synchronously, so this Tor handler can try to connect/launch Tor before returning the endpoint.

[Brian Warner]

Hey, could you take a look at ​https://github.com/warner/foolscap/pull/27 and see what you think? Probably not ready to merge, but maybe y'all can give me some hints.

[Brian Warner]

Moving these tickets from 0.12 to 0.13, since we need 0.12 out quickly to resolve #263

[Brian Warner]

The Tor branch is looking good: I've got manual tests working for all the expected use cases. I'm not certain about the API yet, but I think I'll land it tonight and then fix things up more before the release.

[Brian Warner]

Landed in [6e436b66f5e9b3e6327977765bdb754ceffda91c]

[Brian Warner]

I renamed the API functions a bit, to try for a bit more consistency. I'm still undecided about whether to ask for a 'reactor' argument in the handler functions.. we can't use it now, but things could be a bit cleaner if the internal function always set up the SOCKS proxy endpoint when the handler was first created, and then there are some functions (like default) which would really like to build that Endpoint before passing it into the common class, and *that* would need a reactor.

But, I think it'll work for now, so I'm going to close this.