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").