make tahoe Tor- and I2P-friendly #517
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
7 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#517
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Jake Appelbaum and I were talking at the last hackfest about what it would take to run Tahoe safely through the Tor (anonymizing onion-router) proxy.
I figured it wouldn't take much: just removing the automatically-added local IP addresses from the advertised FURLs. You'd treat the tubid as a pseudonym (i.e. never run this node without Tor). Listeners would be a complete loss (that is, other nodes would not be able to establish connections to yours, until 1: we get SOCKS4A client-side support into Twisted, 2: make sure Foolscap can use .onion names in connection hints, and 3: add a Foolscap Listener that establishes itself on a Tor hidden-service port).
But beyond that, it should just be a question of running Tahoe under 'tsocks', so that all of its outbound connections go through the socks proxy and then through Tor to the other servers.
So the task for this ticket: provide a configuration knob to override the default "find all my IP addresses and add them to the connection hints (via Tub.setLocation)" behavior, and instead provide a hard-coded list of hints instead.
fixed misspelling of Jake's name.. oops.
changeset:9976bd439ac50be5 adds "tub.location" to tahoe.cfg . I haven't tested it at all, but I think this ought to handle the main issue. I think all that's left is for someone Tor-knowledgeable to test it out and write up a short guide on running tahoe under tsocks.
To close this ticket write up documentation of how to use Tahoe-LAFS with Tor. Also use Tahoe-LAFS with Tor and make sure that it works. :-)
See the docs about
tub.locationin [configuration.txt]source:browser/docs/configuration.txt@4187#L80.Should the Tor documentation show how to run Tahoe transparently? Should it be for a Tahoe storage node? For a Tahoe client connecting to the test grid?
What would be useful?
It seems like we have a few possible interesting use cases:
I think that 1 is currently possible with tsocks and a functional Tor client. 2 seems to be easy enough to do with the tub.location patch and iptables wizardry. 3 seems likely best solved with transparent Tor proxying and manual tub.location stuffing.
As a side note, it's probably the case that Tahoe should weight reconstruction and not use blocks from .onions as their first choice for streaming data.
Is there anything else that's missing? What other ways should we use Tor and Tahoe together?
Maybe an initial setup could be a tahoe running machine transparent proxied through Tor, just to see if it work.
make tahoe Tor-friendlyto make tahoe Tor- and I2P-friendlyRunning a grid on Tor hidden services works for me (by setting
tub.locationto an onion address and running tahoe under usewithtor), but I've noticed two IP address leaks so far (#1942 and #1947).Currently Tahoe is usable with tor via the usewithtor/torsocks LD_PRELOAD tool, but it would be nice to have less hacky proxy support built-in.
Over at http://foolscap.lothar.com/trac/ticket/217 david415 is working on adding twisted endpoint support to foolscap. Once that is done, I was initially thinking that Tahoe should load (as yet unwritten) twisted plugins which register the txsocksx library as endpoints called "socks" and "tor" (the latter of which would automatically use the tor socks port 9050, and perhaps also fall back to the other common tor port 9150). After simply loading these plugins, we could use furls in the form of "tor:foo.onion:nnnn" or "socks:example.com:nnnn:sockshost=127.0.0.1:socksport=9050". However, there are two problems with this approach:
So, endpoint support alone is not enough to make Tahoe tor-friendly. But, I still think adding endpoints to foolscap seems like the correct thing to do.
My current thought is that Tahoe should have an "always_use_tor" option which causes all furls to be rewritten as tor: endpoints before being passed to foolscap. If this option is not enabled, tor connections will be made if a tor endpoint is used, but not otherwise. So, users of mixed tor/non-tor grids can leave it disabled if they prefer faster connections to non-tor nodes.
This is almost enough, but still leaves a problem for users who want to connect via Tor to all storage nodes except for their own. I think the solution here is to use david415's introducerless branch (cf. #467) and add a new per-server option to make exceptions to the always_use_tor directive.
Related ticket: #1942 (replace google chart in wui with d3.js: it leaks information)
I've stopped commenting in foolscap trac ticket #217 because I think that we can simply convert old connection hints into twisted connection endpoints. It should be obvious from Leif's comment ( (@@https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517#comment:67826@@) ) that we should not construct endpoint descriptors from location hint 3-tuples (type, host, port).
I have commented on some issues with getting twisted endpoints to work in the client side of foolscap here
in foolscap trac ticket #203:
(@@http://foolscap.lothar.com/trac/ticket/203#comment:-1@@)
(@@http://foolscap.lothar.com/trac/ticket/203#comment:-1@@)
zooko, warner and I (and others who I unfortunately don't know handles for) had a lengthy discussion about this at RWC. Proper notes to follow, either here or on http://foolscap.lothar.com/trac/ticket/203
Greetings!
I have written Tor client and server endpoint parsers...
Here's the tor client endpoint I wrote... based on txsocksx.
It has retry logic for guessing the system tor socks port:
https://github.com/david415/txsocksx/tree/endpoint_parsers_retry_socks
should we instead use txtorcon to launch a new tor proc with which
to speak socks to instead of trying to connect to the system tor
proc?
or maybe if it fails to socks connect to all the tor ports in it's
list... it fails-back to launching it's own tor proc with txtorcon
Here's the tor server endpoint I rewrote to launch tor in it's
listenmethod... so that it remains compatible with TwistedIStreamServerEndpoint interface... also I wrote a parser for it :
https://github.com/david415/txtorcon/tree/endpoint_parser_plugin-rewrite3
of the system tor proc to create Tor Hidden Services :
hidden service? I think perhaps as a fallback to first attempting
to use the system tor controlPort to create the hidden service.
I've made lots of progress in the past few months.
Meejah and I released the new Tor Hidden Service endpoint and parser:
https://github.com/meejah/txtorcon
The Tor client endpoint is also in a working state:
https://github.com/david415/txsocksx
I have written a 100% backwards compatible fork of Foolscap which uses
Twisted endpoint descriptor strings for both the client and server
side:
https://github.com/david415/foolscap/tree/endpoint_descriptors_server-rewrite6
My original Tahoe-LAFS "Tor only mode" feature is here:
https://github.com/david415/tahoe-lafs/tree/ticket517
However my second rough draft is higher quality:
https://github.com/david415/tahoe-lafs/tree/david-truckee
I have tried out this branch of Tahoe-LAFS and found it functional for
the client side... The server side has not yet been tested and I
believe there to be an issue:
Foolscap needs to become even more endpoint agnostic... in order for the server side of
Tahoe-LAFS to use Tor with the txtorcon endpoint... but to do this Twisted needs a
new plugin system to serialize IListeningPort objects into endpoint
descriptor strings. I will soon attempt to either discuss this on the
Twisted mailing list or open a Twisted trac ticket.
This trac ticket requires that Tahoe trac ticket #1010 also be resolved;
It will benefit both Tor and I2p users.
Specifically the design specified in comment 37 by Zooko:
comment:37:ticket:1010
We need to also resolve this sub-ticket which is concerned with randomizing client IDs:
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2384
I recently opened this related txtorcon ticket:
fire endpoint listen deferred when HS desc is desseminated
https://github.com/meejah/txtorcon/issues/107
here's the related tor trac ticket:
https://trac.torproject.org/projects/tor/ticket/3523
FYI, http://foolscap.lothar.com/trac/ticket/236 is a plan that dawuud and I came up with for making Foolscap handle Tor/i2p Listeners and connection-hints cleanly.
I attended the Tahoe-LAFS nuts and bolts meeting yesterday and Daira suggested for the Tahoe-LAFS portion of this integration project we should write documentation first. Zooko and I worked on this last year... here it is:
https://github.com/david415/tahoe-lafs/blob/tor-i2p-documentation/docs/anonymity-configuration.rst
Perhaps this document needs some review and corrections.
What's the next step for the Tahoe-LAFS portion of the integration? Implement some of the features as specified in the above documentation?
Maybe this ticket should be resolved first?
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1010
Ahh furthermore we may have to fix up some changes in txtorcon for this project... such as:
https://github.com/meejah/txtorcon/issues/123
Rebased docs to master: https://github.com/tahoe-lafs/tahoe-lafs/commits/517.tor-i2p-documentation.0
From today's meeting, we're aiming for a static approach, in which all allocation (of hidden services and regular TCP ports) takes place during the execution of
tahoe create-node, and the runtime code (tahoe start) just has to follow the instructions left behind intahoe.cfg.This would simplify Tahoe's main
allmydata.node.Nodeconstructor to be completely synchronous, removing the awkward code that waits for the Tub to start running before it can register FURLs for whatever services are being exposed.It would force server operators to choose a TCP port and a connect-hint hostname (or IP address) when they create the server (or modify the config file). New nodes would no longer use IP-address autodetection (but old ones would continue to work).
The necessary tasks (many of which can be parallelized) are:
Tub.setLocationAutomatically()(in the keyserver and stats-gatherer) with something elsetub.location=AUTOwith a synchronous form (using stdlib'ssubprocessmodule). Move this call fromNode._setup_tubintoNode.create_tub, which runs during the constructor. Move theTub.setLocationup there too. Replacewhen_tub_ready()with synchronous calls, and remove the whole async_startServicemethod.tahoe create-clientto make a tahoe.cfg that doesn't listen on anythingWe also need to figure out the override-specific-servers mechanism (to use TCP for some whitelisted servers, even though we're using Tor for everything else). I think this will involve a Foolscap plugin that can either use Tor or TCP for TCP hints, depending upon some lookup function that it calls at runtime.
track progress of tahoe CLI changes here:
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2490
tracking progress of synchronous node startup here:
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2491
Replying to warner:
I'm concerned that this will be a significant usability regression.
Replying to warner:
This all fits well with I2P too. Like dawuud has said elsewhere, it's easy to have a static HS / Destination, and let Tor / I2P handle the network side. An I2P Destination can be set up automatically in the same way that a Tor HS now also can be, although right now
txi2passumes a running router. It wouldn't be hard to implement an auto-start feature for a configured router location, but this is usability semantics that is irrelevant to the current approach.I'm ambivalent on this, so whatever makes it easier for you. I tend to think that servers aren't really going to be moving around too much, and it's obvious enough to the sysop when they do and this breaks, and simple enough to fix.
The mailing list post referred to a bunch of Tor-specific arguments. Functionally, I assume the Tor-specific arguments will be passed to the Tor plugin, the I2P-specific arguments will be passed to I2P, etc.
I think from a usability perspective we need to make sure it is obvious to the user which arguments do what (the
--tor-*arguments definitely achieve this), but also we don't want to overwhelm the user with configuration options. I can see at least the following distinct setups being viable:and potentially:
The
--tor-onlyand--listen-on-tor-style arguments IMHO aren't going to scale nicely. I don't expect more than Tor and I2P realistically (in the near future), but if each combination is being given its own flag... Maybe instead there could be a single--listen-on=argument that takes a comma-separated list of plugin identifiers, ie.--listen-on=tcp,tor,i2p. This would also then simplify the logic for plugin-specific arguments:--PLUGINIDENTIFIER-*gets passed directly toPLUGIN.Again, this needs to be planned to handle more than just Tor.
From today's meeting, folks seemed comfortable with the following tahoe.cfg syntax to configure the client side:
The presence of
connectionstor.socks-proxy=will cause Tahoe to install a Foolscap connection plugin that handles FURL connection-hints which begin withtor:by sending them to the given SOCKS5 proxy. The presence oftcp.socks-proxy=makes it remove all plugins and then install a similar plugin that handlestcp:connection hints. And the i2p plugin is similar, but uses an HTTP "CONNECT" proxy instead of SOCKS, since apparently that's how the I2P client does it.If
nodeanonymousis true, we'll enforce two things, as per #1010:nodetub.locationdoes not contain "AUTO"connectionstcp.socks-proxyis set(We could make this stronger: require tub.location to only contain
tor:ori2p:hints, require the hostnames in tub.location to end in.onionor.i2p, and maybe require the tcp.socks-proxy to point at 127.0.0.1 instead of some potentially-exterior host. But for now I think these two are sufficient)We'd like to allow tub.location to be empty. We need to make sure Foolscap can handle that (on both server and client sides), and then eventually we want
tahoe create-clientto leave tub.location and tub.port empty (meaning "don't listen at all"). Note that this will be spelledtub.location=(empty string), and not#tub.location=(missing key), because the latter triggers the current default of "AUTO".For this first step, we'll just do the client side, and only in tahoe.cfg. This should be enough to:
tor:ori2p:connection hints (viatub.listen)tor:andi2p:connection hints from othersIn a second phase, we'll use the
tor.(otherstuff)fields (which might not want to live inconnections, I dunno) to launch a Tor daemon at node startup (maybe using a pre-configured base directory under~/.tahoe/, maybe with a config file that's built from the tahoe.cfg options). Then in the third phase, we make changes to thetahoe create-client/tahoe create-nodearguments, to configure that Tor daemon (and allocate onion servers, etc).But for now, I think these tahoe.cfg changes will enable manual Tor/I2P setup without needing to figure out the
--tor-only/--listen-on-tor/ etc arguments just yet.Or, for history, one syntax which got a -0 (for being kinda YAGNI) was to declare that any
connectionskey that matched(\w+)\.socks-proxywould cause a Foolscap plugin to get installed that routes$1-type connection hints to the given SOCKS proxy (and a similar thing for CONNECT proxies). Then Tahoe wouldn't know anything special about Tor or I2P, it'd just be the names of the tahoe.cfg keys that mattered. That would let users add new connection types in the future without changing the Tahoe code. We felt that people aren't adding new anonymous-router systems very often (for good reasons), and there are other Tor/I2P-specific things that probably will require special handling (like launching a Tor daemon when Tahoe starts up), so the benefit wouldn't really be worth it.Replying to warner:
That is how I2P does it now, using duck's HTTP proxy patch. But that was only because it was the simplest patch; as I believe was raised in that ticket's thread, Tahoe / Foolscap isn't really an HTTP protocol. And I2P could just as easily use a SOCKS proxy. But this is only useful for clients.
This line of discussion raises the question: for this initial client-only phase, is the intention to just use plain SOCKS (via
txsocksx) and HTTP (via something like duck's I2P patch) proxies, rather thantxtorconandtxi2p?If
txi2pis going to be used, then the option needs to bei2p.sam-api=. I assume thattor.socks-proxyandi2p.sam-apiwould be allowed to be empty, which would mean "use the default value".Should this be "one of
tcp.socks-proxy,tor.socks-proxy, ori2p.sam-api"?I assume that
tub.locationis meant, which would be empty for clients. And while only the SOCKS/HTTP proxy side is implemented, then withnodeanonymous = True,tub.listenwould be empty because there would be no way to create a Tor HS or I2P Destination.+1.
Replying to warner:
I definitely feel like I'm missing something here. If old nodes continue to work --with AUTO meaning to autodetect at node startup-- how can the Node constructor be completely synchronous and
tahoe startjust have to follow the instructions left behind intahoe.cfg?It's because we can get our IP address synchronously, via blocking
subprocess.check_output(["ifconfig"]). We'll do this before Twisted has taken over the SIGCHLD handler (which happens in a reactor "during-startup" event trigger, so after reactor.run, so afterallmydata.node.Nodeis constructed).We can also allocate a port synchronously. I just landed some code in Foolscap to do this (in
foolscap/util.py):(mind you, I'd like to confirm that function works correctly on windows.. if you've got a windows box handy, could you run Foolscap's current trunk unit tests and see if
test_util.AllocatePortpasses?)Although as I think we talked about before, we probably don't need to use
allocate_tcp_port()in tahoe's startup code: the only case where a node starts up withtub.port = tcp:0and doesn't have aNODEDIR/client.portfile is if you created the node with the older version oftahoe create-node, but never actually started it with that version, and now you're trying to start it with the newer version.The newer version of
tahoe create-nodewill allocate the port before writing outtahoe.cfg, so the runtime will never see atcp:0anywhere.Replying to warner:
Okay, but aren't these changes independent of the other Tor/I2P changes? I don't see how they motivate the potential breakage of backward compatibility in making AUTO no longer be the default (for non-anonymous nodes that listen at all).
Replying to [str4d]comment:36:
Ah, great, if I2P can do SOCKS instead, that will make the plugin much easier to write. I don't know much about I2P :).
I figured that the Foolscap plugin would be implemented by using
txsocksx. For just client connectivity, we don't need full control of the Tor/I2P node yet.Later, to set up a server, we'll certainly want to use
txtorconandtxi2p.It'd need to be
tcp.something, because that's what will control what happens when the Tub connects with a TCP hint.tor.socks-proxycontrols what happens when it connects to a Tor hint, andi2p.*will control I2P hints. The anonymity safety flag must limit TCP.. it doesn't care so much about what happens with hints that have to use a safe connection mode anyways.Updates from today's meeting:
connectionsentries to tahoe.cfg (and installingtxsocksxand/ortxi2p), Tahoe clients will become capable of connecting to Tor/I2P servers. Additionalconnectionsentries will make it use Tor for normal servers too.tub.location=will make the client not advertise a listening port.nodeanonymous = truewill enforce all this.tub.port=tcp:12345:interface="127.0.0.1"andtub.location=tor:abc123.onion:80(or I2P equivalent) to offer hidden storage service. These hidden servers will only be useful to clients who have made the other phase1 changes, to enable tor/i2p connectionstub.port=will make the client not even open a listening port. The logport/controlport will be moved off to a separate Tub (which defaults to listening on 127.0.0.1, but can be configured otherwise), so it will listen even though the main Tub does not.nodeanonymousmight enforce this.tahoe create-clientandtahoe create-nodeto add the rightconnectionssettings. Maybetor.socks-proxy=?tahoe create-nodethat mean "please do whatever is necessary to listen on Tor, and/or I2P, and/or disable normal TCP listening". This will allocate services (keys, descriptors, etc) during create-node, then write whatever decisions have been made into tahoe.cfg. The implementation will not impose any new runtime requirements on the post-reactor-startup phase of node startup (i.e. the onion address must be determined bycreate-nodeand written into tahoe.cfg, so it will be available whentahoe runfirst constructs the Node object).Also, str4d cleared up my confusion about how I2P connections are made. str4d is completely right, the Foolscap plugin for "i2p:" hints should just ask
txi2pto create an Endpoint that does whatever I2P-specific handshaking is necessary, then turns into a regular TCP socket (which means it should handle .startTLS too). There's no need for HTTP CONNECT proxies or SOCKS proxies,txi2phas its own protocol for talking to the I2P daemon, and knows what needs to be done.txi2pwill also be used in phase 4 to allocate the i2p address:tahoe create-nodewill create an I2P listening endpoint (storing key material into a NODEDIR/private/ directory), tell it to start listening, use.getHost()to learn the .i2p address, then shuts it all down. The address is used to write the correct connection hint into tahoe.cfgtub.location, and the key material directory is used to create a server endpoint string to write intotub.port. As long as the i2p server-endpoint-parser plugin is available at node startup, Foolscap will just ask Twisted to parsetub.port, and that should create the right i2p server endpoint.I mentioned that, instead, it'd also be ok (in fact it might be faster) to have
tahoe create-nodecall atxi2pconvenience function that allocates the address without actually creating an endpoint. The normal endpoint.listen() process creates a tunnel, which involves a lot of network traffic. At create-node time, all we really need to do is generate the keys: we can put off creating the real Endpoint until the node is launched.Dear Brian: Great! The plan in comment:67850 seems like a good plan, and I'm excited about us having consensus and a clear plan with reasonably-sized steps that we can chew. ☺
One detail:
Could we please spell this as
tub.location=AUTODETECTinstead oftub.location=? That's what I asked for in comment:40:ticket:1010, and I think str4d already implemented something like it (perhaps spelledAUTOinstead ofAUTODETECT), according to his comment in comment:43:ticket:1010.The current trunk behavior (established in 1.10.1 from 15-Jun-2015) looks like:
#tub.location=: same astub.location = AUTO. This is thecreate-nodedefault.tub.locationin the config file at all: same as abovetub.location = AUTO: use just the autodetected addresstub.location = hint1,AUTO,hint2: use three hints, replace AUTO with autodetected addresstub.location = hint1: use an explicit hint, disable autodetectiontub.location =: use no connection hints at allDoes that change your question? I was claiming that
tub.location=will disable autodetect, and your question sounded like you wanted it to enable autodetect. Are you maybe looking for atub.location = DON'T LISTEN ON ANYTHINGsort of explicit flag, to avoid the subtle confusion betweentub.location=and#tub.location=?To avoid breaking existing nodes, we're stuck with
#tub.location=meaning autodetect. Currently,tahoe create-clientandcreate-nodewrite#tub.location=into the new tahoe.cfg file, but we can change that without impacting compatibility.I'm cool with making don't-listen the default. I'm slightly less cool with adding an explicit don't-listen token (but not totally against it), because then we'd be scanning the config file for two different special values, increasing potential problems for things like "what if my actual hostname matches the special value", etc. But maybe an explicit negative token is clearest / most-usable option.
Replying to warner:
I have added an API method that takes a reactor and a path to a keyfile, saves a new Destination to the keyfile, and returns an
IAddresscontaining the information required to connect to that Destination (the sameI2PAddressthat.getHost()returns). It only requires that the SAM API be accessible.I've written a simple I2P plugin implementing
IConnectionHintHandler, and with a trivial 3-line diff I have successfully run the foolscap calculator example over I2P (manually running a server Destination for the server side, as is done now with the I2P-specific Tahoe build). So I can confirm that foolscap trunk is ready for use in implementing comment:67850.I've rebased a bunch of anon-config documentation commits here:
https://github.com/tahoe-lafs/tahoe-lafs/pull/189
Some of the content (both in my PR and the document in general) needs revision in light of recent developments above, but I want to get my year-old improvements in first :)
str4d: that's great! Are there any changes you'd like to see to the foolscap (client-side) API before I make a new release? Barring any, I plan to cut it later today, so we can make progress on the Tahoe side in tomorrow's meeting.
Replying to warner:
For the in-client API, I think it is great. Once I remembered that only the client side was implemented :P it was a trivial patch (see above).
For the plugin API, I have a few thoughts:
All three points would be "solved" by having a hint-parsing method that turns hints into groups, looking up an
IConnectionHintHandlercorresponding to the parsed hint type (via a dict that is filled whenaddConnectionHintHandler()is called), and passing the parsed groups tohint_to_endpoint()as kwargs. But this is basically re-implementing the Twisted endpoint string API. Is this worth the effort? Or am I over-engineering?Yeah, the intention is that the plugin should make its decision based solely upon the "type", defined as "everything before the first colon". And everything after the first colon is up for grabs by the type: in particular, ipv6 raw addresses will look like
tcp:fe80::1234:5678:80, so the type parser won't necessarily just split on colons. That rules out a signature ofhint_to_endpoint(pieces, reactor). The best we could probably do ishint_to_endpoint(everything_after_the_colon, reactor), which then feels weird because we're no longer passing full hints around.Even if we continue passing full hints into the plugins, we might clean things up with the type-to-plugin dictionary you described. I'm not super happy about having the plugin return "None" to mean "decline to handle this hint". Let's see, that would obligate us to properly move the legacy "host:port" handling up out of the
DefaultTCPplugin (since there'd be no way to register a hint type that would match it), but that's a good idea anyways. It makes it slightly more work to make a plugin that handles multiple types (like a combined "tor:/tcp:"-over-tor plugin), but really you just have to register a single plugin multiple times, no big deal.I was originally thinking
tub.register(plugin)and thenplugin.hint_typewould be a statically-defined string, but now I'm in favor oftub.register(hint_type, plugin).So that would change the
hint_to_pluginimplementation: no more fallback, and if the regexp fails then the hint was invalid and can be ignored (which is distinct from the previous "I don't claim this one, let some other plugin give it a try"). Ah, so we also need an "invalid hint" error which the TubConnector can catch/log/ignore.I'll see if I can implement the latter before making the release. Thanks for the feedback!
Further notes in http://foolscap.lothar.com/trac/ticket/236#comment:16
Replying to warner:
Fair enough. I guess then we just have to clearly document that plugins will definitely get "type:" at the start of the string, but everything else is allowed to be flexible.
The idea I had is that the plugin must have a
typeattribute, like Twisted endpoint plugins have theprefixattribute used to identify them. If we wanted to support handlers with multiple types, then allowprefixto be either a string or a list of strings, and then add the handler to the dict in multiple places. Alternatively, havingtub.register(hint_type, plugin)means that the user can optionally use a handler to handle only one or a few of the types it supports.This raises another point: if moving to the dict-style configuration, how do we handle the case where two plugins are registered handling the same type? Twisted simply uses the first plugin it finds that matches, ignoring others. The current setup does the same thing - the first plugin to match is used. But in a dict-style system, I expect it would be the last foolscap plugin added that is used, because it would replace existing ones. The alternative would be that once a handler for a type is added, subsequent adds are ignored until
tub.removeAllConnectionHandlers()is called.Sounds good.
Having
typeattributes would also make it easier for these to be proper plugins: that is, some sort of scan-your-filesystem thing happens at startup, without an application being aware of it, and every plugin that's found gets registered automatically. It's harder to do that when the registration function must be told the type to use. Automatic registration is handy for deployment, sometimes, but it's also slightly creepy, and in this instance I think I'd feel more comfortable with non-expliclt registration (especially because we have an immediate use case in which two different plugins, tor and tcp, both want to be registered for the "tcp:" type).I ended up going with last-one-wins for the dict. I'd be ok with "second registration throws error" too, which we could add to a subsequent release without much kerfluffle. I'd be nervous about "second registration is silently ignored".
Changes are landed, tests and docs are done.. starting the release process now. Thanks!
Attachment calculator-test.patch (1956 bytes) added
Example I2P client plugin, and patches to use it for foolscap calculator example
Reviewed https://github.com/tahoe-lafs/tahoe-lafs/pull/189.
Notes from today's meeting:
tub.locationneeds to have actual pre-generated .onion addressestub.registerServerPlugin("foo", plugin)means thattub.listenOn("foo:stuff")will useendpoint = plugin.make_endpoint("foo:stuff"). If there's no plugin, the Tub will always fall back to Twisted's server-endpoint parser. This plugin will have the opportunity to add arguments to the endpoint being created.connectionssection to control how a tor/i2p daemon is configured. Some potential values:tub.location, calltub.setLocation(), register FURLsconnections, launch tor/i2p daemon if necessary, build and install the foolscap client and server plugins.tub.port, calltub.listenOn(), start the tubtub.portcan beonion:privkey=$KEYMATERIAL, or maybe privkey=private/onion.key(to keep secrets out of tahoe.cfg). Duringtahoe create-nodewe generate the key, store the private key into that file, store the public .onion address intub.location. i2p private keys are roughly 900 base64 characters, we don't know how large tor keys are (only relevant if we store them directly in tahoe.cfg).We might do verification: parse
tub.locationto find the .onion address, read the private key, compute the associated public address, make sure they match. It's an open question as to how much damage the tahoe config directory can tolerate before we can't recover usefully. It'd be nice if a deleted private key could be regenerated, at least manually. OTOH tahoe can be much more agnostic abouttub.portandtub.locationif we don't do this verification.An externally-managed tor daemon will use
tub.port = tcp:12345:interface=127.0.0.1andtub.location = tor:foo.onion:80. An automatically-managed tor daemon will usetub.port = onion:privkey=..andtub.location = tor:foo.onion:80, and insidetub.listenOn(), the txtorcon server endpoint parser will do some setup work (maybe launch tor, ask it to register the pre-configured onion service), then return a tcp/localhost endpoint for Foolscap to listen on.One concern that should be noted in the docs: even if you don't advertise a real IP address, your node might be listening on something which could be probed externally, for a confirmation attack. Like if you use
tub.port = tcp:12345(without theinterface=127.0.0.1), and configure tor to forward foo.onion to that, then someone might scan the entire internet for ports that react the same way as foo.onion, and find yours. The attack is made harder by NAT, also by restricting the socket to the local interface, but the only real defense would be for tor/i2p to learn to send some kind of secret handshake at the beginning of the connection, and for the local TCP endpoint to check the handshake before passing the socket up to Foolscap.txtorconhas a useful "global" feature, where it remembers a process-wide singleton object that can be used for all connections. So if tahoe tells txtorcon to create this during startup phase 1, then it will be used for the server endpoint in phase 3 (without any extra work, and more importantly without additional config strings intub.port). I2P doesn't have a corresponding feature, so the foolscap server plugin for i2p will need to add the extra arguments when building the server endpoint.Foolscap server plugins are in foolscap#243.
rough draft SOCKS client and Tor client plugins here in my dev branch:
https://github.com/david415/foolscap/tree/tor-plugin.0
These plugins are untested... although the Tor client endpoint code was mostly copy pasted from my old txtorsocksx github repo: https://github.com/david415/txtorsocksx/blob/master/txtorsocksx/endpoints.py
I'd like to test this plugin with foolscap and tahoe-lafs... by connecting to the onion grid.
warner made a proper client-side foolscap plugin here:
https://github.com/warner/foolscap/tree/tor
so the next step is to get Tahoe-LAFS to load foolscap plugins on startup?
i made a simple txsocksx based tor client here:
https://github.com/david415/foolscap/tree/tor-client-plugin.0
http://foolscap.lothar.com/trac/ticket/242
i'd like to test it with tahoe but i'm not sure how since tahoe currently does not work with foolscap-0.9.1 and later...
what's the next step?
how can i use tahoe with the latest foolscap?
1.10.2.post21 [b5222e36798086567efca6b0b436976c6b8598fe]master: definitely passes tests (on Linux) with foolscap 0.9.1.
ah ok thanks daira.
i've fixed my build system's problems.
since then i've gotten some work done:
i used that testing branch of foolscap with Tahoe-LAFS and successfully connected
to an onion grid.
Next I would like to add a tahoe.cfg configuration section for loading foolscap transport client plugins and specifying options; specifically socks host and port for the tor plugin.
After that we can iterate on the Tor plugin until we've got several with different properties... such as launching tor and saving tor state to a private/ directory... etc.
i've now gotten my socks client foolscap transport plugin to work with my tahoe dev branch using these configuration settings:
this is my dev branch:
https://github.com/david415/tahoe-lafs/tree/517.add-client-plugin-config.0
i've also added unit tests... to make sure the socks plugin is loaded correctly
and that the port is converted from str to int etc.
my foolscap socks client plugin is in my dev branch here:
https://github.com/david415/foolscap/tree/tor-client-plugin.0
please review.
Thanks, David! It looks like the foolscap side has a usable SOCKS plugin now, and the other plugins should be relatively easy to write!
On the Tahoe side, though, I think that it would be better to avoid requiring that Tahoe explicitly support specific foolscap plugins and their options (even if it does learn about some of them later to implement the anonymity options discussed in #1010).
I can think of at least 5 or 6 possible client-side plugins so far; TCP (default), SOCKS, Tor (socks w/ automatic port selection: SocksSocket (unix domain socket), 9050, 9150, or discovered-via-control-port), HTTP Proxy, I2P (HTTP proxy with automatic port selection?), and perhaps UNIX domain sockets or other twisted endpoints - and I would like to be able to use any combination of them simultaneously.
I'm not sure if I'd prefer that Tahoe specify (via a tahoe.cfg option) which plugins to load or if they should be loaded automatically like Twisted plugins, but in either case I think that Tahoe shouldn't need plugin-specific code.
As previously discussed, using options obtained from connection hints would be dangerous when we are receiving the hints from announcements on the network. But, it is also a convenient way to communicate arbitrary options to the plugin when the hints are coming from a local config file.
So, I think we should allow arbitary options in connection hint strings (eg, a proxy servers's host, port, username, password, etc) but we should sanitize the hints we receive from announcements: only the type, host, and port are ever used from announcements.
I propose eventually allowing per-server plugin configuration using my and David's "introducerless" branch (based on warner's work) discussed in ticket #68 which I hope to have rebased to master soon.
Without that branch merged, we can implement less flexible plugin support (without per-server local configuration overrides) by mapping announcements' connection hint types to known plugins as discussed previously in this ticket. This would even allow connecting to mixed tcp, tor, and i2p networks IFF the servers are announcing new-style connection hints with types, as the tor and i2p plugins should work with only a host and port.
To enable connecting to an existing all-tor or all-i2p grids where some servers have not been upgraded, and also to provide the mode that connects to both onion and non-onion addresses over tor, and also to provide the ability to use arbitary socks or HTTP proxies with whatever options are desired, I propose an "announcement_rewrite" option which can accept a value like
tor:%h:%porsocks5:%h:%p:socksserver=127.0.0.1:socksport=1080ori2p:%hor evenfoo:%h:%p:origtype=%t.So, to recap:
Without the introducerless branch, it will be possible to (a) connect to heterogeneous grids of new servers, or (b) connect to homogeneous grids of old-and-new servers and route all connections over a specific proxy.
With the introducerless branch, it is possible to disregard announcements and specify unique connection plugin options for specific servers. (While still having a rewrite rule to coerce newly-announced servers to some default proxy connection.)
We agreed in today's Nuts & Bolts meeting to bump better Tor/I2P support out to 1.11.0.
Yesterday in our pairing session Daira code reviewed my Foolscap and Tahoe-LAFS changes specified in the above comment:
(@@https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517#comment:67870@@)
Daira added a small code change to make the
connectionconfiguration section oftahoe.cfgmore flexible. I fixed a minor bug where we were failing to catch the exception of theconnectionsconfiguration section does not exist... this caused many unit tests to fail.Latest Foolscap and Tahoe-LAFS Tor integration development branches, here:
https://github.com/david415/tahoe-lafs/tree/517.add-client-plugin-config.1
and here:
https://github.com/david415/foolscap/tree/tor-client-plugin.1
Latest branches at:
Milestone renamed
Latest branches at:
Code review needed.
Replying to dawuud:
Cool, glad to see this is progressing!
The design as implemented above allows for some flexibility but not enough in my opinion.
It does allow multiple proxies named
fooandbarto be configured by implicitly defining new connection hint typesfooandbarwith{foo,bar}.socks_{host,port}in Tahoe'sconnectionsconfiguration section; those types could then be used from locally-specified connection hints via the #467 introless branch, or could even be used in announcements if there is coordination between servers and clients as to what the names of the proxies are.But what is unfortunately not yet possible (except perhaps with the hacky solution below) is the use case I keep coming back to: I want to connect to announced servers over tor by default (which, in the most recent branch means setting
tcp.socks_{host,port}) but I want to use the introless config in #467 to specify somehow that I want to connect to certain servers directly (perhaps because they are on my LAN or a VPN).There is a hacky way that this could technically be possible using dawuud's latest branches: I could run a local socks server to facilitate non-Tor connections. But, I'd have to give it some name, and if the introducer (or any server connecting to the introducer) guessed the name they could send me connection hints using that name (which would cause me to make non-tor connections to them).
I still like my connection-hint-rewriting plan I described in a previous comment, which would allow Tahoe to not have any knowledge of various foolscap plugins (in its code - it would in its config). Perhaps there is a better solution, but it seems to me that blindly passing connection hints from announcements into foolscap is at odds with my desire to both (a) default to tor (read: not let malicious servers cause me to make non-tor connections) and (b) have the ability to make non-tor connections to servers of my choosing.
During the last Nuts and Bolts meeting I came to realize that my connection-hint-rewriting plan was a lousy idea (with implementation pitfalls leading to potential security bugs, even), and we've now arrived at what I think is a quite good design which Brian has written up in #2759 and which dawuud is presently implementing (on top of the introless-multiintro branch from #68 and #467).
I tried running with the two branches above but either get import errors (during unit-tests) like:
...which leads me to believe it's picking up the wrong foolscap. But if I
pip install -e src/foolscapwhich is attor-client-plugin.3then I get version errors fromtahoelike:Do I have the wrong branches checked out?
(Got it, I either I was using the wrong remote or it was a bit out of date). But ... works now (or at least, the import error is gone).
Meejah let's discuss this in #2759
#2788 is our latest ticket describing our Tor integration design
moving most tickets from 1.12 to 1.13 so we can release 1.12 with magic-folders
Meejah and I were just working out what the tahoe.cfg syntax ought to be for controlling how Tor gets started (especially on the client side). Here's our current idea:
tahoe.cfgacquires atorsection, with the following keys (and their defaults):enable = truesocks.port =(empty)control.port =(empty, but usesunix:/var/run/tor/controliflaunchis false)launch = falsetor.executable =(empty)data.directory =(empty, or a subdir of tahoe's NODEDIR)The highest-priority setting is
enable. Ifenableis false, all other settings are ignored, and nothing uses Tor.The next-highest priority is
socks.port. If set, the client attempts to importtxsocksxat startup, and if that is successful, it installs a Foolscap connection handler fortor:hints which route them to a SOCKS handler with the given port. (note thattxtorcondepends ontxsocksx)The lowest-priority settings are
control.portandlaunch(tor.executableanddata.directoryare only used iflaunch = true).If
control.portis set, andlaunchis false, the client will attempt to importtxtorconat startup, and if that is successful, installs a connection handler that:txtorconto connect to the pre-running Tor process via the control porttor:hint through the SOCKS portIf
control.portis empty andlaunchis false, the client usescontrol.port = unix:/var/run/tor/control. This will Just Work (opportunistically) for debian/fedora systems where thetorpackage has been installed and the user is a member of the appropriate unix system group (e.g.debian-tor).If
control.portis empty andlaunchis true, the client usestxtorconto start a new Tor process and allocate a suitable control port. Connections are made through the new Tor's SOCKS port as above.tor.executablecan be used to specify the exact Tor binary to run (if empty, the default behavior is to search $PATH fortor).data.directory=can be used to provide a persistent datadir, which reduces startup time (from tens of seconds to a few seconds).If
control.portis set andlaunchis true,txtorconis asked to launch a Tor process as above, but the process is told to usecontrol.portfor it's control port, instead of allocating a new one.(we haven't decided what
data.directoryshould default to: maybe a subdirectory of the Tahoe node directory? or maybe a new temp directory?)So, as far as use cases go:
torpackage is installed (and thus a Tor process is running),txtorconis installed, and the user is in the right unix groupsocks.port=to use it, and install at leasttxsocksx. Use this if you want more control over the Tor config.launch = true, and maybetor.executable=if your Tor lives in an unusual placeenable = false.We'll need an additional flag to say "use Tor for TCP hints too", which is checked by the
anonymous = truesafety flag.On the server side, #2773 describes the CLI options for
tahoe create-node. You'd provide--locationand--portto use a pre-configured Tor hidden service (and would probably want to setsocks.port=to point at the same Tor, for outbound connections, along with the "use Tor for TCP too" andanonymousflags). Or providing--listen-torwould telltahoe create-nodeto get a Tor control port and create any necessary hidden-service keys, and write the--locationand--port(and other how-to-start-Tor reminders) into tahoe.cfg. We might need CLI options for all of thetorcontrols listed above, since we'll have to start a Tor duringcreate-node, before the user has a chance to edit their tahoe.cfg.In talking with Leif and David today, we found out that they're discouraging the use of the
debian-torunix group (and of opening the Tor control port to non-admin users in general). They're concerned that it exposes to much authority to programs that don't really need it.Instead, they recommended that we just try SOCKS on both localhost port 9050 (which is where a system Tor usually listens) and port 9150 (where the Tor Browser Bundle listens). Not coincidentally, this is exactly what
txtorcon.endpoints.TorClientEndpointdoes by default. We had previously worried that this would enable some other local user to camp out on these ports and intercept the connections (whereas they couldn't camp out on a unix socket that lives in /var/run without being root). But Leif pointed out that if somebody malicious is already running enough code on your box to listen on a local socket, then you've already lost (for example they could make their own outbound connection and leak your IP address) (note that Foolscap is still encrypting the connection and verifying the TLS cert, so this local attacker couldn't violate your confidentiality, but the one thing they can violate is your anonymity)So the new "Hopefully Just Works" default will be to use SOCKS on 9050/9150, rather than to use a control port to discover a SOCKS port. That changes the above plan as follows:
enable = truesocks.port =(empty, but uses 9050/9150 ifcontrol.portis empty andlaunchis false)control.port =(empty)launch = falsetor.executable =(empty)data.directory =(empty, or a subdir of tahoe's NODEDIR)The highest-priority setting is
enable. Ifenableis false, all other settings are ignored, and nothing uses Tor.The next-highest priority is
socks.port. If set, the client attempts to importfoolscap.handlers.socks(which needstxsocksx) at startup, and if that is successful, it installs a Foolscap connection handler fortor:hints which route them to a SOCKS handler with the given port (note thattxtorcondepends ontxsocksx). This doesn't enable the use of multiple SOCKS port: thesocks.portvalue is a twisted client endpoint descriptor, which only permits specifying a single SOCKS port. The 9050/9150 fallback behavior is buried insideTorClientEndpointand not exposed in the API (in fact,TorClientEndpointdoesn't accept an arbitrary endpoint for the SOCKS port: just a hostname and integer portnum, so we may need to definesocks.portto be strictlytcp:HOST:PORT).(if
control.portorlaunchare set too, we'll still launch a new Tor, but outbound Tor connections will usesocks.portrather than anything involving the new Tor instance. However we might use the new Tor for listening purposes)If
socks.portis not set, butcontrol.portis empty and andlaunchis false, then we'll useTorClientEndpoint's default behavior (use SOCKS on 9050, if that fails fall back to 9150).If
socks.portis not set andcontrol.portis set, then the client attempts to importfoolscap.handlers.tor(which needstxtorcon), and if that is successful, installs a connection handler that:txtorconto connect to a Tor process via the control porttor:hint through the SOCKS portIf
launchis true, the client usestxtorconto start a new Tor process. Ifcontrol.portis empty, it asks Tor to allocate a suitable control port, otherwise it tells Tor to use the specified port. Connections are made through the new Tor's SOCKS port as above.tor.executablecan be used to specify the exact Tor binary to run (if empty, the default behavior is to search $PATH fortor).data.directory=can be used to provide a persistent datadir, which reduces startup time (from tens of seconds to a few seconds).enablesocks.portcontrol.portlaunchNote that all of this merely controls how we use Tor, not when we use it. By default (unless
enable = false), Tor-based connection hints (for external servers, which we learn through the Introducer) will use Tor, as specified by this config. To make regular TCP hints use Tor too, see theconnections.yaml"Connection Policy" in #2788. To make the local storage server listen on a Tor hidden service, we'll use something else (#2733). To make the connection to the introducer(s) use Tor, see something in #2788.So, as far as use cases go:
tor:hints should connect) when:torpackage is installed (and thus a Tor process is running), or the Tor Browser Bundle is runningtxsocksxis installedsocks.port=to use it, and install at leasttxsocksx. Use this if you want more control over the Tor config.launch = true, and maybetor.executable=if your Tor lives in an unusual placeenable = false.Note that this work depends upon a new Foolscap release which provides the socks/tor connection handlers in the right place. foolscap#242 and foolscap#246 are tracking these.
For the server side, we're still looking at
tahoe create-server --tor(which is mutually-exclusive with--location/--port/--hostnamefrom #2773), but with enough CLI arguments to let you set thesetahoe.cfgvalues right away, becausecreate-server --torwill need to usetxtorconto spin up a hidden service (using some "file system onion service" class it does/will provide), extract the private key and onion address, then write both into some as-yet-undefinedtahoe.cfgfields, where they can be read again attahoe runtime to re-create the server endpoint.Note that the above will not be an issue with I2P / txi2p, because the SAM API only allows the creation and control of tunnels, and only those created by that specific client. The primary issue will be that currently SAM is not enabled by default, but we may change that in a future release. The secondary issue is the lack of auto-launch capability in txi2p, which I will probably have to get around to adding at some point.
I will parse the above and figure out the equivalent setup for I2P this weekend.
I have made foolscap#261 to track the needed I2P connection handler in Foolscap.
The tor SOCKS port and control port should both be accessible via UNIX domain socket, tor currently supports this usage. Ideally tor onion services wouldn't even run with the privilege to use an IP stack... only UNIX domain sockets.
I'm starting to sketch out the foolscap-side Tor connection handler, and I'm thinking that we should simply reject all the weird combinations of these arguments. What do you think about using this table instead?:
enablesocks.portcontrol.portlaunchThat'd give us 5 cases. Case 5 uses the
txsocksx-based handler. Case 2+3+4 use thetxtorconone (with case 2 using the default behavior). Only cases 3 and 4 enable automatically-configured hidden-service listeners (2+5 can do outbound, but don't have a control port so they don't have a way to ask Tor to create a new onion service).Can anyone think of a good reason to use the other combinations? I'm especially looking to avoid parsing
control.portto figure out how to tell a launched Tor to listen on it.Oh, and we should make
socks.portbe an endpoint descriptor, instead ofHOST:PORT, right? To enable unix-domain socks ports? Sotcp:localhost:9050instead of justlocalhost:9050.+1 on simplifying the combinations. Regarding the currently-INVALID combinations:
control.port+launchorsocks.port+launchbeing used as an indicator to try to launch an existing Tor in case it isn't already running, but then the semantics are slightly different, because the other usages oflaunchimply a new Tor process (which is reasonable given that the process is client-only).launchfor it would mean try to launch an existing I2P installation if it isn't already running.socks.port+control.portwould be if the user wanted to use separate tor processes for outgoing and incoming connections, which I can't see a decent justification for. Thelaunchflag is irrelevant here.I'd certainly recommend making
socks.portan endpoint descriptor from the start, but given that it was mentioned above thatTorClientEndpointdoesn't accept an arbitrary endpoint for the SOCKS port (just a hostname and integer portnum), you'd have to parse it regardless.Here is my equivalent to the above for I2P.
tahoe.cfgacquires ani2psection, with the following keys (and their defaults):enable = truesam.port =(empty, usestcp:127.0.0.1:7656by default)launch = falsei2p.executable =(empty, looks for common installation locations by default)i2p.configdir =(empty, looks for common config directories by default)The highest-priority setting is
enable. Ifenableis false, all other settings are ignored, and nothing uses I2P. Ifenableis true, the client attempts to importfoolscap.handlers.i2p(which needstxi2p) at startup, and if that is successful, it installs a Foolscap connection handler fori2p:hints that route them to aSAMI2PStreamClientEndpoint.The next-highest priority is
sam.port. Thesam.portvalue is a Twisted client endpoint descriptor, pointing to a SAM API. Ifsam.portis not set, then we'll usetcp:127.0.0.1:7656. Thetcp:127.0.0.1:7656fallback behavior is part of thetxi2pclient and server endpoint string syntax, but is not part of theSAMI2PStreamClientEndpointandSAMI2PStreamServerEndpointAPIs (which require that the caller pass in anIStreamClientEndpointthat will connect to the SAM API).If
launchis true, the client usestxi2pto start the given existing I2P installation if it is not already running. Connections are made through the I2P installation's SAM port as above.i2p.executablecan be used to specify the exact I2P binary to run (if empty, the default behavior is to search$PATHand common installation locations fori2prouter).If
i2p.configdiris set, the configuration files within will be parsed to obtain the current SAM port.enablesam.portlaunchi2p.configdirpath/to/.i2ppath/to/.i2ptcp:HOST:PORTtcp:HOST:PORTNote that all of this merely controls how we use I2P, not when we use it. By default (unless
enable = false), I2P-based connection hints (for external servers, which we learn through the Introducer) will use I2P, as specified by this config. To make the local storage server listen on the I2P destination (most likely the same one outgoing connections are made on), we'll use something else (#2773, although we can reuse at least part of this config, because listening happens through the same SAM API). To make the connection to the introducer(s) use I2P, see something in #2788.So, as far as use cases go:
i2p:hints should connect) when:txi2pis installedsam.port=to use it, and install at leasttxi2p. Use this if you want to leverage a 24/7 router on another machine (with the SAM port either port-forwarded, or directly-accessible and protected with SSL and authentication).launch = true, and maybei2p.executable=if your I2P lives in an unusual place.txi2pinstalled, but for whatever reason (company policy?) do not want to use I2P, setenable = false.Note that
txi2pcurrently does not have the functionality to implementlaunch,i2p.executableori2p.configdir. Until that is implemented, only cases 1, 2 and 6 will work. I'm also not entirely sure about cases 3 and 4 yet; that will crystallize after implementation.In 73d5376b/trunk:
In 0951201/trunk:
With the landing of #2788 yesterday, I think we've finished most of the work of this ticket. I've re-read the history, and I think this is the set of related tickets (not all of which need to be finished to declare success, but they should all be examined to be sure):
anonymous=truesafety flag)Remaining work that should be done before the 1.12.0 release:
tub.locationcan be empty, and maketub.port= (empty)mean "don't listen". This is for clients. Maybe make thetahoe create-clientinitialtahoe.cfgfile usetub.port=(empty).anonymous=truedisable that chart (stop serving the IMG tag that renders it)anonymous=truesafety flag, specifically how much it ought to constrain, and whether it should allow running a server or not. For sure it should require:nodetub.location=does not contain AUTO (even by default)connectionstcp=toris settub.locationto advertise an .onion/.i2p hint, to protect a user against accidentally manually typing their real IP address into thattor.socks_portto point at localhosttub.port=is empty? for clients this is what you want, but for servers that run behind Tor,tub.port=will listen on localhost, and that's fineIn cb35473/trunk:
Ticket/dependency updates:
The chart in #1942 has been removed (the ticket remains open to track a new implementation, but it is no longer privacy-relevant). We added
node reveal-IP-address = falseto #1010 (instead ofanonymous = true. We aren't worried about randomizing tubids (since we don't share tubs anymore, and scaled back "anonymous" to be just "hide the IP address"), and added a--hide-ipCLI arg totahoe create-node.We're working on #2773 (which I want in this release, because I think --location/--port/--hostname is an important server-setup step, and it makes manual setup of a Tor-based server easier). I think we can use #2490 to track
--listen=tor, for the automatic server setup, but I'm not concerned about getting that part into 1.12.#68 is probably a good nice-to-have, and I haven't yet figured out how this should interact with #467 and/or #573 (the two "static server selection" tickets), but I don't think either are necessary to declare our tor/i2p support complete.
So I'm gonna says that 1.12 is blocked on #2773, but not on #2490. And this ticket (#517) can be closed when:
create-node --location/--port/--hostname, for manual server config)create-node --listen=tor, for automatic server config)looks like we'll be able to do this in 1.12
In 5a195e2/trunk:
Str4d's I2P work has landed too (#2838), so I think we can close this now. yay!