Interesting choice to treat panics as worse bugs than misinterpreting the data. I generally like adding assertions to my code, in order to turn bugs where I mishandle the data into exceptions/panics.
> All engineers used fuzzing to test for panic safety, and as a result, no Rust implementation has a red mark.
I'm curious how they decided whether an implementation had a vulnerability. Did they use formal methods to test for the absence of panics (maybe something like Kani)? Or was it manual code inspection and/or fuzzing? If the latter, this comparison is unfair in that the developers got to test their code on its evaluation criteria before it was evaluated and correct their mistakes (similar to training an ML model on the test set).
It’s easy to say this, but see the note underneath it: “(The above routine is actually inspired by the DNS decoding routine from Nut/OS”… Clearly, this stuff gets written and shipped to production. Maybe it is time to admit that in 2025 it is not a good idea to have C code anywhere near untrusted input?
Interesting choice to treat panics as worse bugs than misinterpreting the data. I generally like adding assertions to my code, in order to turn bugs where I mishandle the data into exceptions/panics.
They are right. In real life triggering a panic means your service stops, which could mean just a dns resolver or a big part of the system.
So yeah it should return whatever it can (or an error code) without crashing
> All engineers used fuzzing to test for panic safety, and as a result, no Rust implementation has a red mark.
I'm curious how they decided whether an implementation had a vulnerability. Did they use formal methods to test for the absence of panics (maybe something like Kani)? Or was it manual code inspection and/or fuzzing? If the latter, this comparison is unfair in that the developers got to test their code on its evaluation criteria before it was evaluated and correct their mistakes (similar to training an ML model on the test set).
Whoever wrote that `unpack_dns` C snippet needs to have their keyboard taken away.
It’s easy to say this, but see the note underneath it: “(The above routine is actually inspired by the DNS decoding routine from Nut/OS”… Clearly, this stuff gets written and shipped to production. Maybe it is time to admit that in 2025 it is not a good idea to have C code anywhere near untrusted input?
this is typical K&R style C. The rabbit hole of unsafety in C is very deep