Hello, Not sure about the renaming thing. I'm open to doing so, but a lot of the user facing stuff (the torrc configuration variables etc) use the HS terminology, so I'm not sure if being inconsistent is good. On Wed, 25 Feb 2015 13:51:59 +0100 carlo von lynX <lynX@xxxxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, Feb 25, 2015 at 07:41:01AM +0100, Andreas Krey wrote: > > The AF_TOR listener would go away with closing the listener socket > > as well (and thus is bound to the lifetime of the process); so > > binding a hidden service to the control connection is the obvious > > analogy. > > Yes, but as it stands AF_TOR is not the #1 API deployed in network > applications. The majority of hidden services are $whatever configured > to listen on port localhost:something and zero awareness of any tor > router doing the rest of the work. Having to change hundreds of > existing apps so that they can work with tor without having to edit > torrc is a worse tradeoff than having to edit torrc. So, write a python script that pulls in txtorcon or stem, does the appropriate controller goo, and subprocess.call()s $whatever. Anyway now that master is 0.2.7.x, I'm looking to revisit this in the form of: * Renaming the commands if necessary. * Minor code cleanups (that occurred to me after I let it sit for a while). * Adding an argument to `ADD_EPH_HS` to suppress the private key being returned over the control port, when the caller requests that tor generate the keypair (for cases where the HS is truely oneshot and the user does not wish to preserve it). * Documentation. Regards, -- Yawning Angel
Attachment:
pgpGpDEjVdX0z.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev