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

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

#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 nickm):

 So sorry for the long delay. I'll try to finish review by end of year.

 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.

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

 QUick notes:
   * In get_interface_address6(), we used to never return internal
 addresses, but it looks like that code got removed?
   * In get_interface_address6(), are there still any leaks of addr?  For
 example, in the case where we return NULL instead of goto err?
   * In get_stable_interface_address6(), do we leak 'list' ?
   * 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.
   * get_interface_address -- is it still necessary?
   * Why is find_good_addr_from_list IPv4-only?  IT seems that having it
 take a tor_addr_t would make it more robust.

 I will try to find more stuff later.  I need to remember that just because
 a patch is long doesn't mean that I can't usefully review part of it. :/

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9729#comment:19>
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