Comment by crote
3 days ago
It isn't very extreme, in my opinion. I am only making one claim, and it's a rather modest one: Memory safety bugs aren't any different from other bugs.
The "you're holding it wrong" crowd has been claiming that memory safety bugs are a skill issue for ages now, and that the issue is overblown and can be solved by having programmers suck less.
Curl provides the counterexample to this. Its main developer seems to be quite skilled, as reiterated by the various AI audits it is a very solid codebase, yet it still suffers from memory safety vulnerabilities. If the "you're holding it wrong" crowd is right, we're faced with a contradiction. Is Curl secretly a poor-quality codebase which has managed to fool the community until now? Is Daniel Stenberg uniquely susceptible to writing memory safety bugs, negating his otherwise-seemingly-decent programming skills? Is he perhaps intentionally introducing memory safety bugs to make C look bad?
In other words: if memory safety bugs are indeed a different breed altogether and are completely avoidable if we try hard enough, why are they still hitting Curl?
I posit that they are not: if you are writing unsafe code, you will introduce memory safety bugs. You can avoid them altogether by switching to inherently-safe languages like Go or Kotlin, by catching them at compile time like Rust, or by catching them at runtime like Fil-C. Or you can ignore the problem altogether and keep writing C like we've been doing for decades, but that means you will keep shipping memory safety vulnerabilities - like we've been doing for decades.
> Memory safety bugs aren't any different from other bugs.
This is highly dependent on what kind of software you are writing.
On the one end, there's stuff like an image format parser in a browser -- a pure function from untrusted bytes to untrusted pixels. In a memory-safe language, it's pretty hard for such code to have vulnerabilities (other than DoS) in such code -- you'd have to explicitly go out of your way to do weird stuff (open unrelated files, start subprocesses, ...). Simple logic bugs can only lead the wrong pixels or panics. But when memory safety bugs are possible, remote code execution is common in such code. Memory-safe languages make a massive difference here!
On the other end, you have stuff like a javascript JIT compiler, which turns untrusted javascript into trusted machine code -- here pretty much any logic bug leading to "wrong output" can be turned into a remote code execution exploit. Memory safe languages are not very useful here.
I meant extreme as in "extremely-high-quality codebase", without which a single example of curl means little for your broader point.