[tor-dev] RFC: Ephemeral Hidden Services via the Control Port

[Yawning Angel]

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 at time.to.get.psyced.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150225/1ef3951f/attachment.sig>