[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #11512 [Tor Launcher]: Tor Launcher should set ClientTransportPlugin according to the bridge list

#11512: Tor Launcher should set ClientTransportPlugin according to the bridge list
------------------------------+-------------------
     Reporter:  anonym        |      Owner:  brade
         Type:  defect        |     Status:  new
     Priority:  normal        |  Milestone:
    Component:  Tor Launcher  |    Version:
   Resolution:                |   Keywords:
Actual Points:                |  Parent ID:
       Points:                |
------------------------------+-------------------

Comment (by anonym):

 Replying to [comment:6 mcs]:
 > Kathy Brade and I did some evaluation of this issue.  We would prefer to
 have Tor Launcher know as little as possible about the
 ClientTransportPlugin configuration, especially since this issue should
 disappear when #8402 is completed.
 >
 > Our proposal is to store the ClientTransportPlugin values as hidden
 preferences, like so:
 > {{{
 > pref("extensions.torlauncher.transport_plugin.fte",
 >   "fte exec ${TORPATH}/PluggableTransports/fteproxy --managed");
 > pref("extensions.torlauncher.transport_plugin.obfs2,obfs3",
 >   "obfs2,obfs3 exec ${TORPATH}/PluggableTransports/obfsproxy.bin
 managed");
 > pref("extensions.torlauncher.transport_plugin.flashproxy",
 >   "flashproxy exec ${TORPATH}/PluggableTransports/flashproxy-client
 --register :0 :9000");
 > }}}
 >
 > Tor Launcher would simply replace ${TORPATH} and use the resulting
 string for the SETCONF ClientTransportPlugin commands.

 This looks good enough for me (and Tails). It will add a slight
 maintenance burden for us but it may actually be good that we're forced to
 pay attention to which transports we pull in via `obfsproxy` etc.

 Note that even when we have #8402, my (more complex) approach would
 actually add some value since there would be no need to configure
 `ClientTransportPlugin` lines in `torrc`. However, I do not mind scrapping
 it in favour of your simpler approach. KISS.

 > Also, we can avoid the IPv6 issue if we assume that the first token in
 the bridge configuration may be a transport type; if it happens to be an
 IPv4 or IPv6 address, it won't match any known types so it will be
 ignored.  The only downside we see for this simple approach is that Tor
 Launcher will not be able to display a warning for unknown types.  A
 slightly smarter approach might be to check that the first token consists
 entirely of 0-9, A-F, ":" and "." (in which case it should be an IPv4 or
 IPv6 address with optional :port and not a transport type).

 Then I should reconsider the name of my "DEADBEEF" transport plugin.
 </joke>

 Seriously, doesn't xulrunner provide libraries? Interfaces to internal
 Firefox functions, where an IP validator certainly must exist?

 > For the UI, we will need to think more about how to handle the fact that
 the proxy and bridge options are mutually exclusive.

 Right, but I suppose that actually is a separate issue deserving a new
 ticket.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11512#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs