On Tue, 17 Feb 2015 02:22:54 +0400 meejah meejah@meejah.ca wrote:
From my perspective, the entire point of this feature is to allow applications to use "the system Tor" (or, at least "some already-running tor") to put their hidden services on.
The design the way it is with more isolation than usual also allows for people that use the tails/whonix/or my control port tinfoil hat filter to potentially whitelist the commands as well, since there isn't any information disclosure (unless I screwed up the implementation).
Modifying the filters is left up to the implementors (and I probably won't change or-ctl-filter to allow them since I don't use HSes[0]), but I view it as a step forward for including/using applications that use HSes into such environments.
(Or, looking at it another way, if you don't want to share a tor instance with other applications, you can do that easily today -- you start up a tor, and can use __OwningControllerProcess as you see fit).
The *only* reason that txtorcon by default launches a new tor process for the "onion:" endpoints is because nothing else will work reliably.
I'd very much like the default to be that it adds a new onion using Yawning's API. This will still fall back to "launch a new tor process", but if you know what you're doing you can have a system (or personal) Tor instance running (with cookie authentication) that can have hidden services added and removed from it.
Obviously, this will be a lot faster than launching a new Tor (and less load or DirAuths). As a bonus, Yawning's API is nice and simple (versus SETCONF, which makes it super easy to nuke all the *other* hidden services you configured).
What I would expect of people using this feature is that the process that's "adding the hidden service" is the very same one that's "providing the service"...
(If you're doing something with a separate nginx or whatever process running your hidden-service, than you should know enough to be able to add a couple lines to your torrc and make a normal, "permanent" hidden-service).
Or write a trivial script that prompts for a password, decrypts a HS key, and loads it into a tor instance over the control port. I assume if/when my branch gets merged into mainline tor that the controler APIs will support it in a easy to use manner.
So, in that context, if your application code isn't perfect and might sometimes crash, definitely the right thing is to nuke the hidden service. If the app didn't even save its private keys before that happened, well, too bad.
I guess to put another way: I can't see a use-case to keep the hidden- service around if the application that added it went away.
It seems a lose consensus is reached here that this is ok, so I'm going to leave the design as is and write the control-spec.txt patch.