removing IP-address autodetection, Tor integration

[meejah]

David Stainton <dstainton415 at gmail.com> writes:

> I think Tahoe-LAFS "default Tor quickstart" settings would include
> configuration parameters specifying to use a txtorcon launched tor
> process. More advanced users may specify tahoe.cfg parameters to
> utilize the tor control port of an existing tor process.

>From txtorcon's perspective, my goal is to make it easy to get a
*working* Tor connection (client or server) with sane and documented
defaults. This means, worst-case, launching our own Tor process
(client-side or server-side).

Advanced users (of txtorcon) can choose explicitly (e.g. if system-tor
fails, just fail).

> If the Tahoe-LAFS storage operator uses an existing tor process via
> the control port then does the txtorcon remove existing Tor hidden
> services when it adds it's own new hidden service? The old control
> port API is terrible and hard to use... does txtorcon use the new
> ephemeral hidden service control port API?

Currently, it does not use the new API yet out-of-the-box for onion: or
tor: endpoints. However, it will -- that will be the default:

1. try system tor (with ephemeral API)
2. if that fails, launch our own tor
3. if that fails, fail.

Step 2 above uses a private tempdir (honouring TMPDIR) which goes away
when txtorcon shuts down (via reactor hooks), including any key material
generated -- with the caveat that of course it was on whatever
filesystem TMPDIR pointed to...

> I believe there was some discussion on the tor-dev mailing list about
> that a while back and someone mentioned sending key material through
> the control port for a given onion service.

So, there are some nice features of the "ephemeral" API: 

1. if your control connection goes away, the onion key material vanishes
2. you can retrieve and/or set the private key (i.e. you can use the
   "ephemeral" API to make a permamnent service -- but then you get to do
   key management).

Therefore you can imagine the "ephemeral onion API" more like "client
controls the key material" where one of the choices is "this is
temporary, make it go away when the control connection closes".

So, for example, it would be possible for Tahoe to manage the onion
private keys -- ultimately any API in txtorcon for ephemeral onions will
support passing in the private key. The wisdom of this is left as an
exercise for the reader ;) the main use-case I guess being using a
non-filesystem storage mechanism (since Tor only uses the filesystem to
manage keys).

-- 
meejah