search

meejah / txtorcon

Twisted-based asynchronous Tor control protocol implementation. Includes unit-tests, examples, state-tracking code and configuration abstraction.
http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/
MIT License
250 stars 72 forks source link

Tor client endpoint should be able to use UNIX domain sockets for it's SOCKS connection #181

Closed david415 closed 8 years ago

david415 commented 8 years ago

Ideally the tor client endpoint should be able to connect to a UNIX domain socket if that's tor's SOCKS port. I'm actually not so concerned about how the endpoint parser will deal with this... because for the tahoe tor integration use case we really do not need to use the endpoint parser; we just need an api that works.

meejah commented 8 years ago

The release-1.x branch is probably the best place to start -- as I'm moving away from txsocksx ("because Python3") anyway and have a SOCKS implementation in that branch that also supports the two Tor custom opcodes. I'm not sure if txsocksx supports Unix domain sockets anyway.

warner commented 8 years ago

Foolscap#265 is where we need this. It looked like there might be a way to hack this into txtorcon.TorClientEndpoint (by abusing the private _proxy_endpoint_generator=), but I don't want to do something so obviously fragile as that.

Maybe a TorClientEndpoint constructor that just takes an endpoint for the SOCKS port as an argument? I don't remember how reusable endpoints are.. if for some reason it's not legal to call .connect() multiple times, then we could pass in a no-argument function that returns endpoints on demand..

david415 commented 8 years ago

@warner we worked on it here: https://github.com/meejah/txtorcon/pull/182

meejah commented 8 years ago

Also, FWIW, the API in #182 is (now) the same as currently exists in release-1.x (where this already works).

meejah commented 8 years ago

See https://github.com/meejah/txtorcon/pull/183

meejah commented 8 years ago

in 0.16.1