mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-09-20 21:16:22 +02:00
fa07c60c67
I had a half-built mechanism to track, during the voting process, whether the Ed25519 value (or lack thereof) reflected a true consensus among the authorities. But we never actually inserted this field in the consensus. The key idea here is that we first attempt to match up votes by pairs of <Ed,RSA>, where <Ed> can be NULL if we're told that there is no Ed key. If this succeeds, then we can treat all those votes as 'a consensus for Ed'. And we can include all other votes with a matching RSA key and no statement about Ed keys as being "also about the same relay." After that, we look for RSA keys we haven't actually found an entry for yet, and see if there are enough votes for them, NOT considering Ed keys. If there are, we match them as before, but we treat them as "not a consensus about ed". When we include an entry in a consensus, if it does not reflect a consensus about ed keys, then we include a new NoEdConsensus flag on it. This is all only for consensus method 22 or later. Also see corresponding dir-spec patch.
6 lines
284 B
Plaintext
6 lines
284 B
Plaintext
o Major bugfixes (voting):
|
|
- When collating votes by Ed25519 identities, authorities now
|
|
include a "NoEdConsensus" flag if the ed25519 value (or lack thereof)
|
|
for a server does not reflect the majority consensus. Related to bug
|
|
17668; bugfix on 0.2.7.2-alpha.
|