[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



#24456: Figure out what to do with the guardfraction feature
------------------------------------+------------------------------------
 Reporter:  asn                     |          Owner:  (none)
     Type:  defect                  |         Status:  needs_review
 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:
------------------------------------+------------------------------------

Comment (by asn):

 Replying to [comment:8 teor]:
 > Replying to [comment:6 asn]:
 > > OK let's recap here because these backward compatibility stuff confuse
 me!
 > >
 > > For 033 master we need a patch that obsoletes the config options (also
 removes all the config option-relevant code), and also kills the
 guardfraction voting feature. See my branch `bug24456_033` for this.
 >
 > This is ok. Refusing to vote guardfraction is compatible with any
 consensus method.
 >
 > > For 029 and later, we just need a patch that obsoletes the config
 options. See my branch `bug24456_029` for this.
 >
 > This is ok. Refusing to vote guardfraction is compatible with any
 consensus method.
 >
 > > Then later in the future, when most dirauths use tor versions with
 obsolete config options, we can completely kill the rest of the code
 (vote/consensus guardfraction parsing, consensus voting code, client code,
 etc.).
 >
 > One minor tweak:
 >
 > Clients can ignore guardfraction in 033 or 034 if we want. Clients do
 not have to use consensus features.
 >
 > And here is how we remove code that depends on consensus method 20 (the
 guardfraction method):
 >
 > 1. Create a new consensus method that ignores guardfraction votes. This
 new method can go in 033 or 034.
 > 2. Change all the code that says ">= MIN METHOD FOR GUARDFRACTION" to
 say ">= MIN METHOD FOR GUARDFRACTION and < MIN METHOD TO IGNORE
 GUARDFRACTION" (the new method). This disables guardfraction when the new
 method or any later method is used. See consensus method 28 for an example
 of the code and spec that we need to remove a consensus feature.
 > 3. When we will never revert to a lower consensus method (two releases
 later, 035 or 036), stop authorities voting for the buggy methods 20-28,
 and remove a whole bunch of old code, including all the guardfraction
 code.
 > 4. At that time, we might want to remove all the methods lower than 20,
 too. See #24378.
 >

 Hmm, let's do all this stuff in 034 I think. Also separating client
 guardfraction functionality from dirauth-guardfraction functionality is
 not so easy, since they both use the same funcs, but the latter also uses
 it for consensus making. So perhaps we can roll with the branches I posted
 above for now, and build on top of them for 034.

 I'll make `bug24456_030`, `bug24456_031` and `bug24456_032` asap.

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