[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2293: I2P client endpoint parameter concatenator

[Tahoe-LAFS]

#2293: I2P client endpoint parameter concatenator
------------------------------+----------------------------------
     Reporter:  dawuud        |      Owner:  dawuud
         Type:  enhancement   |     Status:  new
     Priority:  normal        |  Milestone:  undecided
    Component:  code-network  |    Version:  1.10.0
   Resolution:                |   Keywords:  i2p endpoint twisted
Launchpad Bug:                |
------------------------------+----------------------------------

Old description:

> 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.

New description:

 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

--

Comment (by str4d):

 Removed the client endpoint string whitelisting comments from the
 description, I have opened a Twisted ticket for that:

 https://twistedmatrix.com/trac/ticket/7632

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