Dir auths could withhold HSIntro 4 in their votes if the relay would be a buggy v3 intro point
In #27841 (moved) we learned that some old relays have a buggy implementation when they're used as a new-style intro point, which is causing misery -- both inconsistent reachability for v3 onion services and extra load on the network.
In https://trac.torproject.org/projects/tor/ticket/27841#comment:33 we thought that withholding the HSIntro 4 vote for buggy relays would require a new consensus method, but I don't think that is so: in networkstatus_compute_consensus() when we're crafting the consensus out of the votes, we do
smartlist_sort_strings(protocols);
chosen_protocol_list = get_most_frequent_member(protocols);So all we need to do is change authorities to vote different protovers for those relays in their votes, and once a majority of them are voting the new protovers, that's it.
Mind you, the implementation looks a bit tricky at first, because right now the vote is simply created by passing through the protovers volunteered in the relay descriptor: see routerstatus_format_entry()'s
if (protocols) {
smartlist_add_asprintf(chunks, "pr %s\n", protocols);
}but we could avoid all the parsing mess by some simpler logic like "if it's a bad version, and it's claiming the expected full protover string x, use the full string y instead".
I'm waiting to hear from dgoulet what versions remain buggy with the HSIntro protocol 4. It might be that we have nothing to fix here, once we've bumped out all the obsolete relays from the network, and instead we should just keep in mind for the future that this situation is what protovers were meant for.