[tor-bugs] #24456 [Core Tor/Tor]: Figure out what to do with the guardfraction feature

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Jan 8 15:37:00 UTC 2018


#24456: Figure out what to do with the guardfraction feature
------------------------------------+------------------------------------
 Reporter:  asn                     |          Owner:  (none)
     Type:  defect                  |         Status:  needs_revision
 Priority:  Medium                  |      Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor            |        Version:
 Severity:  Normal                  |     Resolution:
 Keywords:  tor-dirauth, tor-guard  |  Actual Points:
Parent ID:                          |         Points:  2
 Reviewer:                          |        Sponsor:
------------------------------------+------------------------------------
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:2 asn]:
 > OK I did it! I ripped off the code from the codebase. Here are the
 rewards:
 > {{{
 > 19 files changed, 11 insertions(+), 1063 deletions(-)
 > }}}
 >
 > Please see branch `ticket24456` in my repo for this.

 Quick structural review:

 We don't delete options, we OBSOLETE() them.

 We can't just delete code from networkstatus_compute_consensus() and any
 the functions it calls. Instead, we add a new consensus method, and only
 run the old code when the consensus method is old enough. For
 guardfraction, there will be a range of consensus methods that run the
 guardfraction code.

 Votes are different: we can make authorities stop voting guardfraction
 without needing a new consensus method.

 How buggy is guardfraction?
 Does it work?
 Does it cause consensus failures when it's turned on?
 Should we backport the "don't vote guardfraction" part of this patch to
 0.3.1 and 0.3.2?
 (The minimal patch obsoletes the options, but leaves them in or_options_t.
 This works because zero means off.)

 > Tests pass and `make test-network-all` pass. The diff is pretty simple.

 This needs to pass the "mixed" chutney test, which is only run if you have
 a binary called "tor-stable" in your path.
 I usually make this happen by doing "ln -s /usr/bin/tor /usr/local/bin
 /tor-stable".

 Also, the mixed network needs to pass with guardfraction enabled on the
 stable authorities.

 > Rationale for the removal is cited in the commit msg.

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


More information about the tor-bugs mailing list