Re: [tor-bugs] #1300 [Tor Relay]: Authority that doesn't make a consensus never fetches one from elsewhere

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#1300: Authority that doesn't make a consensus never fetches one from elsewhere
--------------------------------+-------------------------------------------
 Reporter:  arma                |         Type:  defect   
   Status:  needs_review        |     Priority:  normal   
Milestone:  Tor: 0.2.2.x-final  |    Component:  Tor Relay
  Version:  0.2.1.24            |   Resolution:  None     
 Keywords:  easy                |       Parent:           
--------------------------------+-------------------------------------------

Comment(by arma):

 To be clear, the logic is to stick with our current consensus if these are
 all true:

 {{{
   now >= current_consensus->valid_after
   now <= current_consensus->valid_until
   now < current_consensus->fresh_until + AUTHORITY_NS_DOWNLOAD_DELAY
 }}}

 Sounds plausible.

 We should be aware though that there's an interaction here with
 update_consensus_networkstatus_fetch_time(). Once we get a consensus, we
 set
 {{{
 time_to_download_next_consensus = start +
 crypto_rand_int((int)dl_interval);
 }}}
 where
 {{{
     start = c->fresh_until + min_sec_before_caching;
     interval = c->fresh_until - c->valid_after;
     dl_interval = interval/2;
 }}}
 So if we have a consensus, we won't even think about fetching one until a
 random time between :02 and :32 in the next period.

 That said, it looks like we try once per minute to get a new consensus,
 once both a) we're past that random point between :02 and :32, and b)
 we're past :15.

 If I have my math right, for testing tor networks "b" trumps in all cases.

 All of this said, what's the reasoning for the "wait at least 15 minutes"
 part? If it is the next voting period and we don't have a consensus, we're
 not going to suddenly retroactively compute one. And there's currently no
 other way for us to learn one besides fetching it -- that's what this bug
 is about. So the only merit I can see is that we spent at least 1/4 of the
 next period giving out our old consensus. That seems like unnecessary
 complexity, especially if (and we should check this) we reject the new
 consensus we've fetched if we don't like its signatures.

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