...
In testing it took a little bit of finagling to get chutney to accept a non-Tor "platform" item in the descriptor. Turned out adding a "proto" line as well is enough.
I think this is a feature of the tor directory authority implementation, not chutney.
(Chutney doesn't do anything with platform or proto lines.)
Directory authorities will only synthesise a proto line for platforms that claim to be
Tor, because they can't be sure what features non-Tor platforms support.
But it did occur to me that other code may assume the "platform" line takes a certain form.
It shouldn't, that's what protocol lines are for.
But any alternate implementation will never be used as a v3 HSDir, because it
would need to claim to be Tor 0.3.0.8 or later for v3 onion services to use it. This
is a poor design decision on our part: just like consensus methods, when we break
a protocol version, we should allocate a new number, and check it.
(Or we should exclude broken versions from the consensus.)
I've opened this ticket to fix that:
I can easily change the descriptor if necessary?
As long as it conforms to the spec, it's fine.
We should really fuzz descriptor parsers better.
parser code only runs on descriptors on the live network.