tahoe-lafs/trac

anonymous friendly tahoe create-node/create-client #2490

New issue

Closed

opened 2015-08-29 11:29:21 +00:00 by david415 · 15 comments

david415 commented

2015-08-29 11:29:21 +00:00

subset of tasks from https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517#comment:29

change tahoe create-client to make a tahoe.cfg that doesn't listen on anything
change "tahoe create-node" to require --listen and --location
change "tahoe create-node" to handle the new Tor/I2P arguments, once we figure out how they should be spelled

subset of tasks from <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517#comment:29> - change tahoe create-client to make a tahoe.cfg that doesn't listen on anything - change "tahoe create-node" to require --listen and --location - change "tahoe create-node" to handle the new Tor/I2P arguments, once we figure out how they should be spelled

david415 added the

labels 2015-08-29 11:29:21 +00:00

david415 added this to the undecided milestone 2015-08-29 11:29:21 +00:00

daira was assigned by david415

2015-08-29 11:29:21 +00:00

david415 commented

2015-08-29 12:09:50 +00:00

Author

rough sketch of create-node cli here:
https://github.com/david415/tahoe-lafs/tree/2490.anonymous-create-node-client.0

[user@tahoe-dev1 tahoe-lafs]$ ./bin/tahoe create-node -h

Usage: tahoe [global-options] create-node --listen=... --location=... [options] [NODEDIR]
(use 'tahoe --help' to view global options)

Options:
      --no-storage   Do not offer storage service to other nodes.
  -C, --basedir=     Specify which Tahoe base directory should be used. This has
                     the same effect as the global --node-directory option.
                     [default: '/home/user/.tahoe']
  -n, --nickname=    Specify the nickname for this node.
  -i, --introducer=  Specify the introducer FURL to use.
  -p, --webport=     Specify which TCP port to run the HTTP interface on. Use
                     'none' to disable. [default: tcp:3456:interface=127.0.0.1]
      --listen=      Specify a Twisted server endpoint descriptor string to be
                     used for our storage service listener.
      --location=    Specify a foolscap client connection hint string to
                     advertise as our storage service.
      --version      
      --help         Display this help and exit.

Create a full Tahoe-LAFS node (client+server).

/home/user/tahoe-lafs/support/bin/tahoe:  option -h not recognized

[user@tahoe-dev1 tahoe-lafs]$

rough sketch of create-node cli here: <https://github.com/david415/tahoe-lafs/tree/2490.anonymous-create-node-client.0> ``` [user@tahoe-dev1 tahoe-lafs]$ ./bin/tahoe create-node -h Usage: tahoe [global-options] create-node --listen=... --location=... [options] [NODEDIR] (use 'tahoe --help' to view global options) Options: --no-storage Do not offer storage service to other nodes. -C, --basedir= Specify which Tahoe base directory should be used. This has the same effect as the global --node-directory option. [default: '/home/user/.tahoe'] -n, --nickname= Specify the nickname for this node. -i, --introducer= Specify the introducer FURL to use. -p, --webport= Specify which TCP port to run the HTTP interface on. Use 'none' to disable. [default: tcp:3456:interface=127.0.0.1] --listen= Specify a Twisted server endpoint descriptor string to be used for our storage service listener. --location= Specify a foolscap client connection hint string to advertise as our storage service. --version --help Display this help and exit. Create a full Tahoe-LAFS node (client+server). /home/user/tahoe-lafs/support/bin/tahoe: option -h not recognized [user@tahoe-dev1 tahoe-lafs]$ ```

str4d commented

2015-09-04 02:58:13 +00:00

--listen and --location docs should be at the top of the list if they are required (since the list has no defined ordering at present). They should probably be above the Options section to emphasize this, although that would likely require more backend changes to the config flag handling code.

I agree with daira's comments on the commit - the distinction between the two arguments is unclear. Examples for each would help, as well as something to clarify the difference between them, or connecting them to the corresponding tahoe.cfg variables. Again, maybe a section above "Options" would help. (This is stepping into man-page territory though.) Alternatively, maybe --location could be renamed --advertize (or --broadcast for something with consistent spelling) to better convey its meaning.

warner's email mentioned additional arguments like --tor-only and --listen-on-tor. As I say in /tahoe-lafs/trac/issues/26461#comment:33, I don't think these scale. Additionally, they duplicate information from --listen:

--tor-only is equivalent to --listen=tor:foo.
--listen-on-tor is equivalent to --listen=tcp:0,tor:foo (or --listen=tcp:0 --listen=tor:foo, it's unclear which will be used).

If --listen is to be required and will be the authoritative source of what-to-listen-on information, then additional arguments for configuring the type of setup are IMHO unnecessary.

For arguments specific to configuring Tor/I2P/etc, I think --tor-*, --i2p-* etc. make the most sense. For clients, they can easily be collected and passed straight to the plugins; for servers, the relevant server code can just use them directly. I can't think of any arguments that a user might want to pass to both Tor and I2P.

`--listen` and `--location` docs should be at the top of the list if they are required (since the list has no defined ordering at present). They should probably be above the `Options` section to emphasize this, although that would likely require more backend changes to the config flag handling code. I agree with [daira's comments on the commit](https://github.com/david415/tahoe-lafs/commit/a360fea767e5db2a0c76d5c19f77b18ec8ca4b00) - the distinction between the two arguments is unclear. Examples for each would help, as well as something to clarify the difference between them, or connecting them to the corresponding `tahoe.cfg` variables. Again, maybe a section above "Options" would help. (This is stepping into man-page territory though.) Alternatively, maybe `--location` could be renamed `--advertize` (or `--broadcast` for something with consistent spelling) to better convey its meaning. [warner's email](https://tahoe-lafs.org/pipermail/tahoe-dev/2015-August/009569.html) mentioned additional arguments like `--tor-only` and `--listen-on-tor`. As I say in [/tahoe-lafs/trac/issues/26461](/tahoe-lafs/trac/issues/26461)#comment:33, I don't think these scale. Additionally, they duplicate information from `--listen`: * `--tor-only` is equivalent to `--listen=tor:foo`. * `--listen-on-tor` is equivalent to `--listen=tcp:0,tor:foo` (or `--listen=tcp:0 --listen=tor:foo`, it's unclear which will be used). If `--listen` is to be required and will be the authoritative source of what-to-listen-on information, then additional arguments for configuring the type of setup are IMHO unnecessary. For arguments specific to configuring Tor/I2P/etc, I think `--tor-*`, `--i2p-*` etc. make the most sense. For clients, they can easily be collected and passed straight to the plugins; for servers, the relevant server code can just use them directly. I can't think of any arguments that a user might want to pass to both Tor and I2P.

warner added

c/code-nodeadmin

and removed

c/unknown

labels 2016-08-07 22:41:26 +00:00

warner commented

2016-09-03 00:11:45 +00:00

#2773 may include --listen=tcp and/or --listen=none, but should not block on the async-ification of node creation, or on anything involving onion server creation. All those Tor/I2P pieces belong here in #2490.

#2773 will be in 1.12 . This ticket doesn't need to be, and I've currently scheduled it for 1.13, but if it gets done early, we'll change the target milestone.

Note: this ticket (#2490) is about --listen=tor/i2p and automatic server setup. #2773 is just about --port/--location/--hostname, the non-automatic setup (well, it's automatic for plain TCP listeners, if you use --hostname=, since it'll allocate a TCP port for you. But it won't do any automatic tor/i2p stuff). #2773 may include --listen=tcp and/or --listen=none, but should not block on the async-ification of node creation, or on anything involving onion server creation. All those Tor/I2P pieces belong here in #2490. #2773 will be in 1.12 . This ticket doesn't need to be, and I've currently scheduled it for 1.13, but if it gets done early, we'll change the target milestone.

warner modified the milestone from undecided to 1.13.0

2016-09-03 00:11:45 +00:00

warner commented

2016-09-13 19:45:21 +00:00

pulling this forward into 1.12, it's looking likely

warner modified the milestone from 1.13.0 to 1.12.0

2016-09-13 19:45:21 +00:00

warner commented

2016-09-13 20:05:13 +00:00

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:

assert that control.port/launch/tor.executable explicitly point to a Tor, and forbid the use of default search-for-tor behavior
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.

We forbid search-for-Tor in the onion case because we're going to be revealing the onion private key to whichever Tor we use, and I don't want to enable a different user (on the same box) from being able to camp out on 9150 and steal these keys. For the use-Tor-for-outbound case, this isn't as big a deal, because 1: Foolscap provides the crypto and authentication, and 2: such an attacker already knows your IP address. An attacker who camps out on 9150 early enough to catch your tahoe create-node interaction will be the one to provide you with the onion key in the first place. So I think the only threat is when you spoke with a real Tor at create-node time, but are talking to a spoofed Tor at start-node time, which is why I'm thinking that it's sufficient to just record how we contacted Tor the first time and do the same thing the second time.

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.

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: * assert that `control.port`/`launch`/`tor.executable` explicitly point to a Tor, and forbid the use of default search-for-tor behavior * 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`. We forbid search-for-Tor in the onion case because we're going to be revealing the onion private key to whichever Tor we use, and I don't want to enable a different user (on the same box) from being able to camp out on 9150 and steal these keys. For the use-Tor-for-outbound case, this isn't as big a deal, because 1: Foolscap provides the crypto and authentication, and 2: such an attacker already knows your IP address. An attacker who camps out on 9150 early enough to catch your `tahoe create-node` interaction will be the one to provide you with the onion key in the first place. So I think the only threat is when you spoke with a real Tor at create-node time, but are talking to a spoofed Tor at start-node time, which is why I'm thinking that it's sufficient to just record *how* we contacted Tor the first time and do the same thing the second time. 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.

daira was unassigned by warner

2016-09-13 20:05:31 +00:00

warner self-assigned this 2016-09-13 20:05:31 +00:00

warner commented

2016-09-13 20:16:08 +00:00

tahoe.cfg key names should probably be:

tor onion.external_port =
tor onion.private_key_file =

(since almost everything else is using underscores, not hyphens)

`tahoe.cfg` key names should probably be: * `tor onion.external_port =` * `tor onion.private_key_file =` (since almost everything else is using underscores, not hyphens)

warner commented

2016-09-16 20:37:33 +00:00

I think we'll need a Foolscap tor-connection-handler that takes a "call me to get a Tor control protocol object" function. Then tahoe-side code will be responsible for creating one (based upon it's config: either control.port= to use an existing one, or launch=true to spin up a new one). The function will remember the protocol object it created, so it will use the same one for both local onion-service listening and outbound connection-handling.

I've opened foolscap#270 for this.

I think we'll need a Foolscap tor-connection-handler that takes a "call me to get a Tor control protocol object" function. Then tahoe-side code will be responsible for creating one (based upon it's config: either `control.port=` to use an existing one, or `launch=true` to spin up a new one). The function will remember the protocol object it created, so it will use the same one for both local onion-service listening and outbound connection-handling. I've opened [foolscap#270](https://foolscap.lothar.com/trac/ticket/270) for this.

david415 commented

2016-09-17 12:17:38 +00:00

Author

I've written a TorProvider class, here:
https://github.com/david415/tahoe-lafs/tree/2490.tor_provider.0

However this is a work in progress because I've yet to actually put the TorProvider class to use... that is for node listen and client connect code paths.

I've written a [TorProvider](wiki/TorProvider) class, here: <https://github.com/david415/tahoe-lafs/tree/2490.tor_provider.0> However this is a work in progress because I've yet to actually put the [TorProvider](wiki/TorProvider) class to use... that is for node listen and client connect code paths.

warner commented

2016-09-21 01:13:08 +00:00

I'm working on a branch which changes dawuud's TorProvider to provide three methods:

allocate_onion() (run at create-node time, launches/connects-to Tor, creates onion service, listens long enough to get .onion address)
get_tub_handler() (run at start-node time): immediately returns a Tub handler for the configured tor-launch/connect method
get_tub_listener() (run at start-node time): immediately returns an Endpoint which the Tub should listen on

But now I'm wondering if we should commit to the local port at create-node time, and then write the matching listener endpoint spec into tub.port=. That would:

not require any changes to the "tub.port and tub.location must either both be provided, or both disabled" requirement
remove the magic "surprise extra listener" that doesn't appear in tub.port

It would also require that if we're doing an e.g. unix-domain listener, it gets put into tub.port as a string. It prevents the use of listeners that can't be represented as normal strings.

So I think we'd either need to pick a TCP/unix-domain listening port at allocate_onion() time, or use some fancy onion: server endpoint string with enough arguments to rebuild it at start-node time (hopefully putting the private key in a file, rather than in the endpoint string).

meejah: is txtorcon equipped to use pre-allocated keys/ports/onion-names? The TCPHiddenServiceEndpoint I'm looking at seems keen on generating all those values at construction time.

I'm working on a branch which changes dawuud's TorProvider to provide three methods: * `allocate_onion()` (run at create-node time, launches/connects-to Tor, creates onion service, listens long enough to get .onion address) * `get_tub_handler()` (run at start-node time): immediately returns a Tub handler for the configured tor-launch/connect method * `get_tub_listener()` (run at start-node time): immediately returns an Endpoint which the Tub should listen on But now I'm wondering if we should commit to the local port at create-node time, and then write the matching listener endpoint spec into `tub.port=`. That would: * not require any changes to the "`tub.port` and `tub.location` must either both be provided, or both disabled" requirement * remove the magic "surprise extra listener" that doesn't appear in `tub.port` It would also require that if we're doing an e.g. unix-domain listener, it gets put into tub.port as a string. It prevents the use of listeners that can't be represented as normal strings. So I think we'd either need to pick a TCP/unix-domain listening port at `allocate_onion()` time, or use some fancy `onion:` server endpoint string with enough arguments to rebuild it at start-node time (hopefully putting the private key in a file, rather than in the endpoint string). meejah: is txtorcon equipped to use pre-allocated keys/ports/onion-names? The `TCPHiddenServiceEndpoint` I'm looking at seems keen on generating all those values at construction time.

warner commented

2016-09-21 08:11:48 +00:00

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.

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.

warner commented

2016-09-29 16:54:30 +00:00

I'm making good progress on this in my 2490-tor branch: I think all the code is in place. I'm writing unit tests now, and will try to do real (manual) tests today.

I'm making good progress on this in my `2490-tor` branch: I think all the code is in place. I'm writing unit tests now, and will try to do real (manual) tests today.

meejah commented

2016-10-02 21:43:10 +00:00

warner: regarding handling pre-allocated keys, in 0.15.1 txtorcon only really handles "HiddenServiceDir"-based ones. Then, you pass hidden_service_dir= to any of .system_tor, .global_tor or .private_tor class-methods.

In the 1.0 branch, ephemeral services are supported, and TCPHiddenServiceEndpoint learns about ephemeral= and private_key= kwargs. See http://txtorcon.readthedocs.io/en/release-1.x/txtorcon-endpoints.html#txtorcon.TCPHiddenServiceEndpoint

You can also pass privateKey= in the endpoint strings.

There may still be changes to the details/terminology (and e.g. some things are called *Onion* because tor is trying to encourage use of "onion services" vs. "hidden services").

warner: regarding handling pre-allocated keys, in 0.15.1 txtorcon only really handles "`HiddenServiceDir`"-based ones. Then, you pass `hidden_service_dir=` to any of `.system_tor`, `.global_tor` or `.private_tor` class-methods. In the 1.0 branch, ephemeral services are supported, and `TCPHiddenServiceEndpoint` learns about `ephemeral=` and `private_key=` kwargs. See <http://txtorcon.readthedocs.io/en/release-1.x/txtorcon-endpoints.html#txtorcon.TCPHiddenServiceEndpoint> You can also pass `privateKey=` in the endpoint strings. There may still be changes to the details/terminology (and e.g. some things are called `*Onion*` because tor is trying to encourage use of "onion services" vs. "hidden services").

meejah commented

2016-10-03 23:28:37 +00:00

Okay, I made a PR to your branch fixing a few things, and have tested against a small grid with 2 tor-only servers (one launched, one on system tor) and everything appears to work. I haven't checked for "outside Tor" traffic leaks.

meejah commented

2016-10-03 23:33:37 +00:00

You'll need "master" branch from txtorcon for now, to get the Unix-socket ControlPort stuff to work properly.

You'll need "master" branch from txtorcon for now, to get the Unix-socket `ControlPort` stuff to work properly.

Brian Warner <warner@lothar.com> commented

2016-10-09 06:11:26 +00:00

Owner

In 5a195e2/trunk:

Merge branch '2490-tor-2'

This adds --listen=tor to create-node and create-server, along with
.onion-address allocation at creation time, and onion-service
starting (launching or connecting to tor as necessary) as node startup
time.

closes ticket:2490
refs ticket:2773
refs ticket:1010
refs ticket:517

In [5a195e2/trunk](/tahoe-lafs/trac/commit/5a195e23396a0bd73d42f4042605687d36d85090): ``` Merge branch '2490-tor-2' This adds --listen=tor to create-node and create-server, along with .onion-address allocation at creation time, and onion-service starting (launching or connecting to tor as necessary) as node startup time. closes ticket:2490 refs ticket:2773 refs ticket:1010 refs ticket:517 ```