[tor-bugs] #5603 [Tor Client]: get_configured_bridge_by_addr_port_digest is not robust

[Tor Bug Tracker & Wiki]

#5603: get_configured_bridge_by_addr_port_digest is not robust
------------------------+---------------------------------------------------
 Reporter:  asn         |          Owner:                    
     Type:  defect      |         Status:  new               
 Priority:  major       |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor Client  |        Version:                    
 Keywords:              |         Parent:                    
   Points:              |   Actualpoints:                    
------------------------+---------------------------------------------------

Comment(by asn):

 Replying to [comment:3 nickm]:
 > I think that kind of change might not necessary; the
 bridge_add_from_config() code could just change instead.  That is, you
 could change the logic from:
 >
 > {{{
 >    if ((b = get_configured_bridge_by_addr_port_digest(...)) {
 >       b->marked_for_removal = 0;
 >       return;
 >    }
 > }}}
 >
 > to:
 >
 > {{{
 >    if ((b = get_configured_bridge_by_addr_port_digest(...)) &&
 >        addr matches && port matches && digest matches && transport
 matches..) {
 >       b->marked_for_removal = 0;
 >       return;
 >    }
 > }}}

 Hm, true. This sounds more sane.

 A complication that might occur is that we can end up having bridges with
 the same addr/port but with different digests/transports. This does not
 make much sense, and does not go well with the way that
 `find_transport_by_bridge_addrport()` works.

 Maybe we should start returning an `int` in `bridge_add_from_config()`,
 signal such conflicts by return `-1`, and then killing tor while it reads
 the config? I'm not sure how we should treat such conflicts otherwise
 (ignore the new bridge and warn the user?).

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