In the spec, we have: > `directory-signature \[Algorithm] identity signing-key-digest .. ... > “sha1” is the default, if no Algorithm is given The hash includes the whole of that line (which is a layering violation, torspec#405, and different to ED certs, torspec#322). Although the line in a consensus is supposed to be deterministically formatted (no extra whitespace etc.), and presuming we don't add additional arguments, it is still possible for there to be signatures both with `sha1` explicitly stated, and with it omitted and inferred. This means that there are (at least) *two* SHA1 hashes of the consensus: with and without the `sha1` in the signature item line. But the (old, pre-parse2) code in `arti.git/crates/tor-netdoc` that processes a consensus has only `sha1` and `sha256` entries in what is currently `SignatureGroup`. This means that if the signatures disagree about whether to write `sha1`, only one set can be used. The others will fail verification. Both of these are legitimate hashes of a semantically identical document, so there is no security problem. In practice presumably this is not a real problem, since all the authorities are running roughly the same software and make the same choice. I have not attempted to construct a repro and I do not propose that we try to fix this bug. I am mostly filing this ticket to have something to refer to next to a TODO comment. IMO that we can have such a bizarre and confusing bug demonstrates how very bad this signature hashing scheme is.