[tor-bugs] #14957 [Tor]: Clients wait for an extra consensus before learning the correct UseGuardFraction value

[Tor Bug Tracker & Wiki]

#14957: Clients wait for an extra consensus before learning the correct
UseGuardFraction value
------------------------+-----------------------------------
     Reporter:  asn     |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-client, tor-guard
Actual Points:          |  Parent ID:
       Points:          |
------------------------+-----------------------------------
Description changed by asn:

Old description:

> When clients parse the consensus, they decide whether to register any
> guardfraction information included based on the value of the
> `UseGuardFraction` consensus parameter. The problem is that the decision
> is taken in the middle of consensus parsing,  but in
> `should_apply_guardfraction()` we wrongly use
> `networkstatus_get_param(NULL, "UseGuardFraction",..."` to decide whether
> the parameter is on or off. In that case `networkstatus_get_param()` will
> check the old consensus, and not the one that we are currently parsing
> and is still in unfinished state.
>
> ticket:9321:comment:52 includes some possible fixes.
>
> Another possible fix would be to always register guardfraction
> information found in the consensus. But instead check during path
> building time whether we should use it or not. So instead of having
> `should_apply_guardfraction()` we would have
> `should_consider_guardfraction()` or `should_use_guardfraction()`.

New description:

 When clients parse the consensus, they decide whether to register any
 guardfraction information included based on the value of the
 `UseGuardFraction` consensus parameter. The problem is that the decision
 is taken in the middle of consensus parsing,  but in
 `should_apply_guardfraction()` we wrongly use
 `networkstatus_get_param(NULL, "UseGuardFraction",..."` to decide whether
 the parameter is on or off. In that case `networkstatus_get_param()` will
 check the old consensus, and not the one that we are currently parsing and
 is still in unfinished state.

 comment:52:ticket:9321 includes some possible fixes.

 Another possible fix would be to always register guardfraction information
 found in the consensus. But instead check during path building time
 whether we should use it or not. So instead of having
 `should_apply_guardfraction()` we would have
 `should_consider_guardfraction()` or `should_use_guardfraction()`.

--

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