[tor-bugs] #9729 [Tor]: Make bridges publish additional ORPort addresses in their descriptor

[Tor Bug Tracker & Wiki]

#9729: Make bridges publish additional ORPort addresses in their descriptor
----------------------------+----------------------------------------------
     Reporter:  sqrt2       |      Owner:
         Type:              |     Status:  needs_revision
  enhancement               |  Milestone:
     Priority:  normal      |    Version:  Tor: 0.2.5.1-alpha
    Component:  Tor         |   Keywords:  ORPort bridge multiple addresses
   Resolution:              |  Parent ID:
Actual Points:              |
       Points:              |
----------------------------+----------------------------------------------

Comment (by sqrt2):

 Also sorry for the delay, unfortunately I didn't get to do any coding at
 30c3 :(

 Replying to [comment:19 nickm]:
 > In the meantime, the most useful thing to add here would be unit tests
 for all the new code, to whatever extent is possible.  (The new mocking
 code in 0.2.5 should make it possible to test stuff that might not have
 been very testable before.

 I assume you're talking about the MOCK* macros from test/testsupport.h. I
 will take a look at this.

 > Can you describe in detail how you've tested this ?  (Apologies if
 you've already said; just link if so.)

 I haven't done any rigorous testing. What I've done is (making use of a
 number of globally routable addresses I have) built a small network with a
 bridge directory server and a bridge with AlternateBridgeAuthority, adding
 addresses to the the local interface and configuring some of them/all of
 them/none of them as ORPorts, then observing that the bridge detects its
 proper addresses and that the directory authority learns of the bridge and
 its addresses.

 So far, I've tested this with IPv4 only.

 >   * In get_interface_address6(), we used to never return internal
 addresses, but it looks like that code got removed?

 In resolve_my_address(), we want to allow explicitly configured internal
 addresses (except if we are a DirAuth, step three).
 get_interface_address6() now also returns internal addresses so
 find_good_addr_from_list(allow_internal=1) can match these to any
 explicitly configured addresses.

 >   * In get_interface_address6(), are there still any leaks of addr?  For
 example, in the case where we return NULL instead of goto err?

 Yes, fixed.

 >   * In get_stable_interface_address6(), do we leak 'list' ?

 Fixed.

 >   * All of the functions that allocate a new thing for their return
 value should document "returns a newly allocated copy of".  Example:
 get_first_address_by_af.  Or perhaps it should take a const smartlist_t *
 and return a reference to the appropriate element.

 Fixed.

 >   * get_interface_address -- is it still necessary?

 I don't think so. I've removed it now.

 >   * Why is find_good_addr_from_list IPv4-only?  IT seems that having it
 take a tor_addr_t would make it more robust.

 Fixed.

 I have also added some code to handle the case where we guess a hostname,
 but the resolved address is not actually one of the configured ORPorts.

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