[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:  daira
         Type:  defect          |     Status:  new
     Priority:  normal          |  Milestone:  1.12.0
    Component:  code-nodeadmin  |    Version:  1.10.1
   Resolution:                  |   Keywords:  tor i2p anonymous
Launchpad Bug:                  |
--------------------------------+-------------------------------

Comment (by warner):

 From today's devchat:

 CLI arguments:

 * `tahoe create-node --listen=tor` will try to connect to the default
 control port (9051, 9151, or `unix:/var/run/tor/control`)
   * if that fails, it will try to launch tor
   * if that fails, the command fails
 * the way we connect to tor can be overridden:
   * `tahoe create-node --listen=tor --tor-control-port=ENDPOINT`
   * `tahoe create-node --listen=tor --launch-tor` (or maybe `--tor-launch`
 to make all tor-related arguments start with the same prefix?)
 * whatever technique succeeded will be written into tahoe.cfg for runtime:
 `[tor] control.port=` or (`[tor] launch=` and `[tor] tor.executable=`)

 Then create-node will:
 * allocate an external "port" number (which goes into the hint, not a real
 TCP port)
 * use txtorcon to allocate an "ephemeral" onion service
 * retrieve the .onion address and private key
 * write the private key into `NODEDIR/private/tor-onion-private-key`
 (TODO: is there a special file suffix we should use?)
 * write the following into tahoe.cfg:
   * `tub.location = tor:XYZ.onion:EXTPORT`
   * `tub.port = disabled`
   * `[tor] control.port=` or `launch=` / `tor.executable=`
   * `[tor] onion.privatekeyfile = NODEDIR/private/tor-onion-private-key`
   * `[tor] onion.external-port = EXTPORT`
 * both of the `onion.*` keys must be present, or neither, but not one
 without the other

 And at runtime (`tahoe start` / `Client.__init__`), if the `onion.*` keys
 are present, we do the following:
 * use the `control.port`/etc keys to tell txtorcon how we want to access
 Tor
 * read the private key material from the named file
 * `ep = txtorcon.TorHiddenServiceEndpoint(key-material)`
 * `tub.listenOn(ep)`

 This means we're adding an additional listener (using whatever localhost
 or unix-domain socket that txtorcon picked for its endpoint), on top of
 whatever `tcp.port=` specified (which is usually none, leaving us with
 just the one onion listener). It also means we don't need to commit to the
 local socket at create-node time, nor mention it in the config file.

 We record EXTPORT separately in the config file do avoid needing to parse
 `tub.location` for it at startup time, which might be confused by
 manually-added hints.

 We have `tahoe.cfg` record the private key as a filename, rather than
 putting the (moderately-sized RSA) key bytes inline inside the config
 file. We're trying to stick to a policy of not adding new secrets to
 `tahoe.cfg`.

 TODO: currently tahoe.cfg must either have both `tub.location` and
 `tub.port`, or neither, so the `tub.port = disabled` above won't work. We
 need to decide on a fix for that.

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