After another look at the spec, I still believe the descriptor I'm publishing conforms, as was my intention. Sorry to have caused all these problems :(
Heads up that there's another (nascent) tor relay implementation in the works. I reached out to them to see if they were interested in collaborating, but I didn't get a response. It's unclear to me what their plans are. However Filippo Valsorda has a strong reputation so it's worth keeping an eye on.MikeOn Thu, Oct 26, 2017 at 12:07 AM, Karsten Loesing <karsten@xxxxxxxxxxxxxx> wrote:______________________________On 2017-10-26 00:09, teor wrote:
> On 26 Oct 2017, at 06:58, Michael McLoughlin <mmcloughlin@xxxxxxxxx
> <mailto:mmcloughlin@xxxxxxxxx>> wrote: Agreed. FWIW, the descriptor published by this relay confused Metrics
>> I can easily change the descriptor if necessary?
>
> As long as it conforms to the spec, it's fine.
quite a bit. But that's okay, we'll just make Metrics more robust. The
good news is that we didn't lose any data in the process.
> We should really fuzz descriptor parsers better.
> But that's not an appropriate thing to do on the live network, and some
> parser code only runs on descriptors on the live network.
If somebody wants to generate a bunch of fuzzed descriptors that conform
to the spec, I'll happily throw them into a local Metrics instance to
see if anything else breaks. I could imagine that Damian would do the
same with stem and Philipp with zoossh.
All the best,
Karsten
_________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxg
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-re lays
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays