[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