[tor-bugs] #2841 [Tor Bridge]: Implementing the pluggable-transport spec

[Tor Bug Tracker & Wiki]

#2841: Implementing the pluggable-transport spec
------------------------+---------------------------------------------------
 Reporter:  asn         |          Owner:  asn               
     Type:  task        |         Status:  needs_review      
 Priority:  normal      |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor Bridge  |        Version:                    
 Keywords:              |         Parent:                    
   Points:              |   Actualpoints:                    
------------------------+---------------------------------------------------

Comment(by rransom):

 Replying to [comment:10 asn]:
 > Replying to [comment:9 nickm]:
 > > First thoughts:

 > > * I don't think it should be an error to have a bridge listed with a
 corresponding transport configured: it makes the bridge unusable, sure,
 but we can still use the other bridges.
 > >
 > > * Why give a warning and reject the configuration if we have
 transports configured without corresponding bridges?  That seems
 acceptable to me: just because I know about a transport doesn't mean I
 should have to use it.
 > >
 > > * Having bridge_info_t keep a pointer to the transport_(info_)t seems
 potentially risky if there's a chance we'll free the transport before we
 free the bridge.  Even if that can't happen now, it seems needlessly
 fragile.

 > Alright I'll handle these three comments together.
 >
 > I removed the transport_t pointer from the bridge_info_t. I'm now using
 transport_get_by_name() to get the bridge's transport instead of using
 bridge->transport.
 >
 > This change though, essentially makes match_bridges_with_transports()
 semi-useless. Do you think we should still keep
 match_bridges_with_transports() around so that it warns the user of
 configuration anomalies (like the ones you mentioned in those two comments
 above)?

 `ClientTransportPlugin` lines that are not used by any `Bridge` will be
 quite normal -- bundles will ship with multiple protocol obfuscators pre-
 configured in their torrcs, but with no pre-configured bridges.

 `Bridge` lines that specify an unavailable `ClientTransportPlugin` are
 bad, and the user should be warned about them.

 > I'm not sure what the correct course of action is, when the user gives
 Bridge lines with methods without corresponding ClientTransportPlugin
 lines (or the opposite.).
 > I was thinking that it would probably be user misconfiguration (typo or
 forgetting to add a line) and that's why I was erroring out.
 >
 > I don't have too strong feelings about this, but there are some small
 things we should take care off if we don't error out.
 > For example with the current code, if the user gives a Bridge line with
 a method without a ClientTransportPlugin line, tor attempts to connect to
 the Bridge addrport directly thinking that there is no pluggable transport
 for this bridge.
 > This happens because find_transport_by_bridge_addrport() returns either
 the transport or NULL, and would return NULL on the above case. Do you
 think this is a case we should be handling with something more than a
 warning?

 This is bad.  Fix it.


 > Your right! Done!

 s/Your/You're/

 > > In config.c:
 > >
 > > * In options_act(), it looks like we only call clear_transport_list()
 if ClientTransportPlugin is set.  Consider what this will do if we have
 some transports configured, and then we remove all the configured
 transports.  It seems that all the old transports will remain configured.

 > Oh you are right! Shouldn't we do the same thing for Bridges?
 (mark_bridge_list() and sweep_bridge_list() are only called if Bridges is
 set)

 We should.  But this doesn't matter for bridges, because we require that
 at least one `Bridge` line be set whenever `UseBridges` is on, and we
 ignore `bridge_list` when `UseBridges` is off.  It does matter for
 transport plugins.

 > > * Do we want to actually have ClientTransportPlugin exclusive with all
 other proxy settings?

 > I'm not sure. The current code won't work if ClientTransportPlugin is
 not exclusive with all other proxy settings, and I was considering that a
 feature.
 > If you think that it shouldn't be exclusive, we should change that.

 `ClientTransportPlugin` shouldn't be exclusive with all other proxy
 settings, because a user may need to use pluggable transports ''because''
 his/her/its only Internet access is through a fascist censoring HTTP
 proxy.  But Tor can't tell the transport plugin to use a proxy.  Hmm...

 Best to make `ClientTransportPlugin` explicitly exclusive with all other
 proxy settings for now, but this is a bug that we ''will'' need to fix
 ASAP.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2841#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online