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.
What is useful here is if I can use existing $app with existing tor router and just have a shell script drop the glue instructions into the tor unix socket. This allows to configure hidden services without editing neither torrc nor the code of the $app. A bit like Vidalia does it, but without messing with the torrc and without being Vidalia.
Also, would you entrust your hidden service keys to a system-wide tor process? :-)
It's like asking if I trust my bank to keep my money. If you don't trust your Tor process, try not using a computer. If you don't trust your cheap server hosting provider, don't put hidden services on cheap rented servers or virtual machines. But if you don't trust your OS, there is no place where you can hide your hidden service keys.