[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2490: anonymous friendly tahoe create-node/create-client

[Tahoe-LAFS]

#2490: anonymous friendly tahoe create-node/create-client
--------------------------------+-------------------------------
     Reporter:  dawuud          |      Owner:  warner
         Type:  defect          |     Status:  assigned
     Priority:  normal          |  Milestone:  1.12.0
    Component:  code-nodeadmin  |    Version:  1.10.1
   Resolution:                  |   Keywords:  tor i2p anonymous
Launchpad Bug:                  |
--------------------------------+-------------------------------

Comment (by warner):

 New idea. There are two objects involved:

 The first object is the "creator". It's actually just a function that
 returns a Deferred. It's invoked with the `twisted.python.usage.Usage`
 "options" object (which records the `--listen=tor`, `--tor-launch`, and
 other CLI argument flags). Its job is:

 * parse the options, figure out if we need to launch tor, or if we've been
 given a control port
 * if we're launch tor: allocate a control port (maybe unix-domain?),
 launch tor, wait for it to start, build the control-port endpoint
 * if not: build the control-port endpoint
 * use txtorcon to build the control protocol from the control-port
 endpoint
 * allocate a local port (maybe unix-domain?), build an entry for
 `tub.port`
 * pick an external port (doesn't matter)
 * use the control protocol to allocate an onion address. retrieve the
 private key and the .onion hostname
 * build an entry for `tub.location` from the .onion hostname and the
 external port
 * write the private key to `BASEDIR/private/tor-onion.privkey`
 * return `tub.port`, `tub.location`, and a dictionary of key/values for
 the `[tor]` section of tahoe.cfg
 * (maybe shut down the launched tor now? and/or delete the ephemeral onion
 service when using a pre-existing tor control port? in general it won't
 matter, the `tahoe create-node` process will terminate a moment later, but
 it might make a difference for tests, and we need to make sure the pre-
 existing tor won't get confused if we temporarily start the onion during
 create-node and then start it a second time at runtime)

 The second object is the "provider". It's created with a synchronous
 function that's called with the `[tor]` portion of tahoe.cfg (not sure of
 the best way to manage this, maybe just give it a reference to
 `Node.get_config`, or maybe the whole Node). Its job:

 * first, it has a synchronous function which returns a Foolscap connection
 handler (or None if tor/txtorcon is unavailable or disabled). This is
 called at node startup, inside `Node.init_connections()`, and subsumes
 `Node._make_tor_handler`. It needs to parse the tahoe.cfg data and decide
 if we're launching or control-port-ing or socks-port-ing. For control.port
 and socks.port, it can return a foolscap-provided handler. For "launch",
 it needs to prepare to launch Tor (but *not* actually launch it yet, since
 we're still in synchronous startup land). It will use the new
 `foolscap.connections.tor.control_endpoint_maker()` to build a handler
 that will launch tor on demand, and it will share that launched Tor with
 the onion listener.
 * second, it is a `MultiService`, and when `startService` happens, *if*
 tahoe.cfg says to start an onion listener, it needs to launch Tor (if not
 already launched by the connection handler, probably because the
 `IntroducerClient` FURL was processed), wait for it to start, establish
 the control protocol, then use the control protocol to start the onion
 service that was allocated by the creator.
 * note that `tub.port` and `tub.location` are *not* controlled by the
 provider. These values are written into `tahoe.cfg` like the user-provided
 `--port=` and `--location=` values. That means we're allocating the local
 port at create-node time, and making Tor re-use that same local port at
 runtime.

 The last part (starting the onion service) might require something unusual
 from txtorcon.

 All the information about the onion service to be started will be recorded
 in tahoe.cfg. We'll document the keys it uses, but mark them as normally
 generated by create-node, and thus not really intended for user
 modification.

 I'm sketching this out in my github `2490-tor` branch, in case anyone
 wants to take a look.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2490#comment:13>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage