Re: [tor-dev] Potential projects for SponsorR (Hidden Services)

[meejah <meejah@xxxxxxxxx>]

Nick Mathewson <nickm@xxxxxxxxxxxxxx> writes:
> On Mon, Oct 20, 2014 at 9:37 AM, George Kadianakis <desnacked@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev