[tor-bugs] #4865 [Tor Bridge]: managed obfsproxy cannot talk to tor on other than 127.0.0.1

[Tor Bug Tracker & Wiki]

#4865: managed obfsproxy cannot talk to tor on other than 127.0.0.1
------------------------+---------------------------------------------------
 Reporter:  wwaites     |          Owner:  asn               
     Type:  defect      |         Status:  needs_review      
 Priority:  normal      |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor Bridge  |        Version:                    
 Keywords:              |         Parent:                    
   Points:              |   Actualpoints:                    
------------------------+---------------------------------------------------
Changes (by asn):

  * status:  needs_revision => needs_review


Comment:

 Replying to [comment:11 nickm]:
 > The fmt_addr and fmt_addr_decorate macros need to be documented.  Also,
 standard C best practices suggest enclosing macro arguments in
 parenthesis, as in
 > {{{
 > #define fmt_addr(a) fmt_addr_iml((a), 0)
 > }}}
 >

 I once read
 https://www.securecoding.cert.org/confluence/display/seccode/PRE01-C.+Use+parentheses+within+macros+around+parameter+names
 (see `PRE01-EX1`) and that's why I did not put any parenthesis there. In
 any case, fixed.

 > I think router_get_active_listener_port_by_type is probably a
 questionable interface.  It can't work predictably with multiple
 listeners, and it can't help you if the address being listened on isn't
 the one you expected.  It looks like we're already making that mistake
 with CFG_AUTO_PORT handling elsewhere, though, so maybe only an XXXX
 comment is in order.
 >

 I agree. I added an XXX.

 > When iterating over configured_ports, you've got to skip the nolisten
 ones, I think.  Also, we could run into trouble if we call
 "get_first_listener_addrport_for_pt" before the listeners are started.  Is
 this possible?  Also, that function should check for failure from
 router_get_active_listener_port_by_type.
 >

 Fixed.
 I don't '''think''' it's possible to get there before the listeners are
 started. Listeners are started in `options_act_reversible()` (even before
 privsep). OTOH, `create_managed_proxy_environment` is called after parsing
 all transport lines and after a couple of `run_scheduled_events()` ticks.
 My tests agree to this assumption.

 > "get_first_listener_addrport_for_pt" is not a great name; we generally
 name functions based on what they do, not who uses them.
 >

 Fixed.

 > Other than that, it seems plausible.
 >

 Pushed new stuff to `bug4865_take2`.

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