[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 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.
> Does that make sense? If it does, I'll add changes file etc to the
branches above, and also make further backport branches.
>
> Thanks for the help Tim :]
No worries. Consensus methods are fun :-)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24456#comment:8>
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