
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">On 26 Oct 2017, at 06:58, Michael McLoughlin <<a href="mailto:mmcloughlin@gmail.com">mmcloughlin@gmail.com</a>> wrote:<br><br></span></font></div><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">...</span></font><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></font></div><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">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.</span></font></div></blockquote><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">I think this is a feature of the tor directory authority implementation, not chutney.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">(Chutney doesn't do anything with platform or proto lines.)</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Directory authorities will only synthesise a proto line for platforms that claim to </span><span style="background-color: rgba(255, 255, 255, 0);">be</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Tor, because they can't be sure what features non-Tor platforms support.</span></div><div><br></div><blockquote type="cite"><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">But it did occur to me that other code may assume the "platform" line takes a certain form.</span></font></div></blockquote><div><br></div><div>It shouldn't, that's what protocol lines are for.</div><div><br></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">But any alternate implementation will never be used as a v3 HSDir, because it</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">would need to claim to be Tor 0.3.0.8 or later for v3 onion services to use it. This</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">is a poor design decision on our part: just like consensus methods, when we break</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">a protocol version, we should allocate a new number, and check it.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">(Or we should exclude broken versions from the consensus.)</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">I've opened this ticket to fix that:</span></div><div><a href="https://trac.torproject.org/projects/tor/ticket/23998" style="background-color: rgba(255, 255, 255, 0);"><font color="#000000">https://trac.torproject.org/projects/tor/ticket/23998</font></a></div></div><br><blockquote type="cite"><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">I can easily change the descriptor if necessary?</span></font></div></blockquote><br></div><div>As long as it conforms to the spec, it's fine.</div><div><br></div><div>We should really fuzz descriptor parsers better.</div><div>But that's not an appropriate thing to do on the live network, and some</div><div>parser code only runs on descriptors on the live network.</div><div><br></div><div>T</div><div><br></div></body></html>