correction... I meant #11291.
On Wed, Oct 29, 2014 at 1:04 AM, David Stainton <[email protected]> wrote: > 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 <[email protected]> wrote: >> Nick Mathewson <[email protected]> writes: >>> On Mon, Oct 20, 2014 at 9:37 AM, George Kadianakis <[email protected]> >>> 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 >> [email protected] >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
