Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#20499: A running Tor won't update the microdesc consensus
--------------------------+------------------------------------
 Reporter:  rubiate       |          Owner:
     Type:  defect        |         Status:  needs_review
 Priority:  High          |      Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |        Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal        |     Resolution:
 Keywords:  regression    |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by teor):

 Code review of `20499_part1_029`:

 I'm surprised your compiler didn't warn about the assignment here:
 {{{
 if (dls->backoff = DL_SCHED_DETERMINISTIC)
 }}}

 Replying to [comment:21 arma]:
 > ...
 > It seems to me that any design that effectively has a "now you won't ask
 for the consensus anymore" possible outcome is a scary one here.

 We should think carefully about what we want the default maximum to be,
 and if we want it to be the same in every case:
 {{{
 *max = INT_MAX;
 }}}

 Perhaps the network could deal with slow zombies if they only retried
 every day/week/month. Or perhaps we really do want them to stop asking. Or
 perhaps we want clients to do one thing, and relays another.

 Currently, some schedules do have INT_MAX as their maximum, others have 2,
 12, or 73 hours.

 All the other commits look fine, but I'm not sure they're enough to solve
 this issue.

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