I2P client endpoint parameter concaternator

[dawuud]

note: this ticket description is inspired by str4d's commit here: ​https://github.com/david415/tahoe-lafs/commit/21cc326f6bd8aedbb3d9478c8591234c3c0b08a0

As discussed on IRC with str4d... the client side of the native I2P integration for Tahoe-LAFS would need a way to pass the I2P endpoint object some private client parameters. str4d proposes a solution: transform the endpoint string before passing it to clientFromString.

That very transpormation should take place in Tahoe-LAFS and it should append the user specified parameters to the Twisted endpoint string.

Clients may need to extend client side Twisted endpoint strings. This seems like a reasonable feature for several Twisted endpoint types.

tcp:example.org:1337:timeout=60
ssl:example.org:443:caCertsDir=/etc/ssl/certs
i2p:longstring.b32.i2p:tunnelNick=tahoe:inport=10000

These should be set in tahoe.cfg like this:

[node]
clientEndpointParams = tcp:timeout=60,ssl:caCertsDir=/etc/ssl/certs,i2p:tunnelNick=tahoe:inport=10000

str4d wrote:

Tahoe parses, keeps an internal map, applies the relevant params to a client endpoint string before connecting

• Client endpoint string whitelisting
  • Server publishes an endpoint string for a client to connect to
  • A malicious server could publish strings containing client-specific parameters that compromise the user
    • Unsure what parameters could actually be used maliciously on their own, but definitely possible in concert with other attacks.
  • The client should not accept strings that contain client-specific parameters
    • How to tell the difference? Tahoe can't keep a list of everything that is safe.
    • Maybe an endpoint API method that takes a client endpoint string and returns a safe one.