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

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Sat Jul 31 19:51:12 UTC 2010


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

  * keywords:  => easy


Old description:

> If moria1 fails to participate in making the consensus (e.g. it's down,
> or
> it doesn't support the consensus method that is chosen for the
> consensus),
> then it doesn't have a consensus for that period. It should realize it
> doesn't
> have the newest consensus, and try to fetch one from the other
> authorities.
>
> This bug is especially relevant while we have authorities that don't like
> the consensus method in use -- currently dizum and dannenberg haven't
> upgraded,
> so they never sign the consensus, so any clients (or relays!) who ask
> them for
> a consensus have to retry elsewhere. I imagine the bug slows down
> bootstrapping
> too.
>
> [Automatically added by flyspray2trac: Operating System: All]

New description:

 If moria1 fails to participate in making the consensus (e.g. it's down, or
 it doesn't support the consensus method that is chosen for the consensus),
 then it doesn't have a consensus for that period. It should realize it
 doesn't
 have the newest consensus, and try to fetch one from the other
 authorities.

 This bug is especially relevant while we have authorities that don't like
 the consensus method in use -- currently dizum and dannenberg haven't
 upgraded,
 so they never sign the consensus, so any clients (or relays!) who ask them
 for
 a consensus have to retry elsewhere. I imagine the bug slows down
 bootstrapping
 too.

 [Automatically added by flyspray2trac: Operating System: All]

--

Comment:

 This could be as easy as just removing the
 {{{
   if (authdir_mode_v3(options))
     return; /* Authorities never fetch a consensus */
 }}}

 from update_consensus_networkstatus_downloads().  But maybe instead we
 should bulletproof it a little more and only fetch a consensus if either
 we have no consensus at all, or a certain minimum time has passed since
 our old one expired?  Or is that unnecessary?  Code investigation will be
 needed.

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


More information about the tor-bugs mailing list