Any Twisted application written in a network endpoint agnostic manner may be used with the txtorcon hidden service endpoint... For instance serving files from a Tor hidden service can be done with Meejah's one-liner: pip install txtorcon && twistd -n web --port "onion:80" --path ~/public_html
However I see the current txtorcon design (without 12911 resolved) as lacking security isolation since tor is launched as the same user as the python process. Using the control port to create hidden services seems like the obviously better way to do this.
Currently Tahoe-LAFS is used with torsocks and manually configured Tor hidden services in order to hide the the identity of the tahoe client and server operators. We'd like for Tahoe-LAFS to have native Tor integration... Using the txtorcon endpoint would greatly simplify deployment for Tahoe-LAFS storage operators wishing to hide their identity/location.
David
On Tue, Oct 28, 2014 at 10:40 PM, meejah meejah@meejah.ca wrote:
Nick Mathewson nickm@torproject.org writes:
On Mon, Oct 20, 2014 at 9:37 AM, George Kadianakis desnacked@riseup.net wrote:
this is an attempt to collect tasks that should be done for SponsorR. You can find the SponsorR page here: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR
I see that #11291 is not on that list. I think it should be.
- Get somebody who wants to access hidden services over the controller
API to explain what they want to build. Then design an API as needed to support it.
Currently, at least the way Tor is deployed on Debian, you cannot add a new hidden-service to a running Tor if you're "just" in the right group (in this case, debian-tor). #11291 would fix this, and is pretty close; dawuud has a branch that's got more utests etc (*not* asking for more review yet ;) )
- Look at what somebody might want to do with hidden services via the
controller API; then design an API to expose that.
One issue with hidden services and the overall controller API, is that they are the only "special" thing that has multi-line configuration where order matters. So controllers have to do "non-trivial" things to make hidden serivces "go".
Unfortunately, I don't have a concrete suggestion here, beyond "take a ground-up look at the controller API", which I'm guessing is out-of-scope? Basically, something more structured might make sense? *However* since hidden services are the only thing that actually makes order important (as far as I recall), perhaps re-thinking those alone within the existing framework would be much less disruptive *and* simplify controller logic (i.e. eliminate the "order is important" bit).
The only concrete use-case I can offer is carml's "pastebin" command, which would like to add and delete hidden services from a running Tor. Currently, it always launches a new Tor instance (so "add" is launch, and "delete" is kill). Perhaps this is the best way anway, separation-wise...?
I can imagine that adding the equivalent of add/delete for authorize-client lines would be a Good Thing, too.
Just brainstorming here, but could both the above be accomplished with some sort of "change configuration" command? That is, instead of forcing controllers to remember enough to make a SETCONF work, the opportunity to add or delete things exists? (And perhaps only for hidden services, since they're the only "special" things currently anyway?) This probably implies an ID for each hidden service...
This also would map fairly well to most UIs, which then just have to remember what the user did (e.g. "clicked delete on the 3rd line, then clicked add with options X, Y, and Z").
-- meejah _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev