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.
When generating a vote, and we have two routerinfos with the same ed
key, omit the one published earlier.
This was supposed to have been solved by key pinning, but when I
made key pinning optional, I didn't realize that this would jump up
and bite us. It is part of bug 18318, and the root cause of 17668.
If we're a server with no address configured, resolve_my_hostname
will need this. But not otherwise. And the preseeding itself can
consume a few seconds if like tails we have no resolvers.
Fixes bug 18548.
Launching 7 descriptor fetches makes a connection to each HSDir that is 6
and the seventh one fails to pick an HSDir because they are all being used
already so it was killing all pending connections at once.
Fixes#15937
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
This simplifies relay behavior, because the relay offers the hsdir
functionality independent of whether the directory authorities have
decided this relay is suitable for clients to use yet.
Implements ticket 18332.
This is in accordance with our usual policy against freelists,
now that working allocators are everywhere.
It should also make memarea.c's coverage higher.
I also doubt that this code ever helped performance.
Short version: clang asan hates the glibc strcmp macro in
bits/string2.h if you are passing it a constant string argument of
length two or less. (I could be off by one here, but that's the
basic idea.)
Closes issue 14821.
