[tor-bugs] #13239 [Tor]: Maybe we want three preemptive internal circs for hidden services?

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat Apr 9 12:06:53 UTC 2016


#13239: Maybe we want three preemptive internal circs for hidden services?
-------------------------------------------------+-------------------------
 Reporter:  arma                                 |          Owner:
     Type:  defect                               |         Status:
 Priority:  Medium                               |  needs_revision
Component:  Tor                                  |      Milestone:  Tor:
 Severity:  Normal                               |  0.2.9.x-final
 Keywords:  tor-client, tor-hs,                  |        Version:
  TorCoreTeam201604                              |     Resolution:
Parent ID:  #5271                                |  Actual Points:
 Reviewer:  asn                                  |         Points:  small
                                                 |        Sponsor:
                                                 |  SponsorR-can
-------------------------------------------------+-------------------------
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:3 sysrqb]:
 >
 > Branch bug13239 pushed. It also tries to make the logic a little more
 readable.

 I have mixed feelings about this branch. I think the function it tries to
 change really needs some love, but I'm not sure if the patch goes deep
 enough. It tries to make the function more readable by adding comments and
 macros but without changing any of its logic. Unfortunately, the logic of
 that function is so complex, that this is not an easy task.

 For starters, I'm not sure if it keeps the same functionality as the old
 code. Specifically, the patch adds this code:
 {{{
     if (!(flags & CIRCLAUNCH_IS_INTERNAL))
       return;
 }}}
 where the function will exit if some checks above don't return True. IIUC
 that was not the case  previously, where the function would just proceed
 to the next block of code if those checks did not come true. I don't see
 an explanation for changing this logic, and I'm not sure if it's correct.
 How do we reach the final block of code now?

 Also the code introduces some lower-case macros that are never undefined.
 Is that OK?

 Finally, I'm not sure if the refactoring introduced is worth it. It took
 me like an hour just to understand the changes and the function is still
 majorly messed up. I couldn't make sense of the comments added either, but
 that's mainly because the logic of the function is so wicked.

 I feel that the right refactoring here would take in account the whole
 function and not just those two code blocks. There are some log messages
 and checks (like `router_have_consensus_path() != CONSENSUS_PATH_UNKNOWN`)
 that happen in every codeblock and can be simplified.

 I kinda feel that till a proper refactoring happens, it's easier to just
 change the constants '2' to '3' for the purposes of this ticket, instead
 of trying to semi-refactor it.

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


More information about the tor-bugs mailing list