3 ms·

Adding more and better fuzzing instead of trying to fix the issue (potentially malicious user input inside a C library) seems like the wrong way to address the

Adding more and better fuzzing instead of trying to fix the issue (potentially malicious user input inside a C library) seems like the wrong way to address the problem. Buffer overruns just shouldn’t be a concern of the developer or test suite but of the compiler or language runtime.

DistractionRect 4y ago
There are two problems. The CVE, and the fact that the current fuzzing harness does did not find it. The CVE is getting fixed, but obviously the fuzzer needs work too because it exists to find these kinds of issues before they get used in the wild. It's being handled how it should be. This happened, let's handle it, and how can we work to better address future problems.
artariel 4y ago
Trusting the fuzzer and not examining its coverage seem to be main problem here. I fail to see what is problematic about giving the control over the entire flow of the program to the developer. Quite the contrary, I am more concerned about the paradigm shift towards higher level system programming languages that hide more and more control from the developer while putting more burden on the perfectness of optimizer.
- alkonaut 4y ago
  Absent a high performing systems language that still offers some safety guarantees, the right call should be to use whatever the second best is. It could be a higher level language with runtime overhead, sandboxing, formal verification etc. In some cases constraints won’t allow this, and obviously replacing even parts of infrastructure code is never easy. Nor should the perfect be the enemy of the good - adding better testing doesn’t sound like a bad idea even for a piece of code being sunset. What I’m objecting against is the (apparent, or my perceived!) idea that “if only the fuzzing was good enough, this code would be acceptable for use forever.
- saagarjha 4y ago
  The average developer is typically more error prone than their compilers is.

DistractionRect 4y ago

There are two problems. The CVE, and the fact that the current fuzzing harness does did not find it. The CVE is getting fixed, but obviously the fuzzer needs work too because it exists to find these kinds of issues before they get used in the wild. It's being handled how it should be. This happened, let's handle it, and how can we work to better address future problems.

artariel 4y ago

Trusting the fuzzer and not examining its coverage seem to be main problem here. I fail to see what is problematic about giving the control over the entire flow of the program to the developer. Quite the contrary, I am more concerned about the paradigm shift towards higher level system programming languages that hide more and more control from the developer while putting more burden on the perfectness of optimizer.

alkonaut 4y ago
Absent a high performing systems language that still offers some safety guarantees, the right call should be to use whatever the second best is. It could be a higher level language with runtime overhead, sandboxing, formal verification etc. In some cases constraints won’t allow this, and obviously replacing even parts of infrastructure code is never easy. Nor should the perfect be the enemy of the good - adding better testing doesn’t sound like a bad idea even for a piece of code being sunset. What I’m objecting against is the (apparent, or my perceived!) idea that “if only the fuzzing was good enough, this code would be acceptable for use forever.
saagarjha 4y ago
The average developer is typically more error prone than their compilers is.