On Tue, 17 Feb 2015 02:22:54 +0400 meejah <meejah@xxxxxxxxx> 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. -- Yawning Angel [0]: The first HS I ever set up was when I finished my first pass implementation, and got the code to a working state.
Attachment:
pgpt3zFSvjn6U.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev