Hacker News new | ask | show | jobs
by lmm 1846 days ago
> Assuming your 52% figure is accurate (and I’m happy to take your word on that) that still means that roughly half of all vulnerabilities are not memory safety.

Sure, but that half is every other category of bug put together. I guess if your model is that every other class of bug will be significantly increased by a rewrite then maybe that logic makes sense, but that seems unlikely to me.

1 comments

You’re making strawman arguments. None of the points you’re proving are anything I’ve disagreed with.

Try reading the thread again

You said "Half those applications are going to have other classes of new bugs simply because it’s new code and they’ve had less people audit the code", and when I pointed out that such bugs would most likely not be security bugs you responded by saying that many security bugs aren't memory safety bugs. You may not have intended to say what you said, but what I'm disagreeing with is what you said, not a strawman, and even if you were right your condescension would still be unwarranted.
Firstly, I’ve not been condensing.

And yes, I did say that at the start of the conversation. Sorry I’d forgotten about that part because this conversation had taken a tangent on discussing other specifics in security.

I do stand by my comments, a rewrite does introduce new bugs and not all security bugs are buffer overflows. Rust doesn’t protect you against bugs like Shellshock. They protect against bugs like Heartbleed. But people frequently forget about the former when focusing on the latter. So absolutely we need to be considered when replacing battle tested software with an entirely new code. It’s not an unfair meme when people state this. If it were an easy and risk free upgrade then we’d have already done so in one of the other safer languages that predate Rust. A lot of what’s changed between then and now isn’t that languages have gotten better, it’s simply that Rust is trendier than any of the safer languages before them. And that’s a pretty awful reason to reason to rush a complete rewrite of the entire stack.

Source: I’m an old fart who’s been writing safe code in safe languages for 30+ years.

> Firstly, I’ve not been condensing.

"Try reading the thread again" is extremely condescending.

> Rust doesn’t protect you against bugs like Shellshock. They protect against bugs like Heartbleed. But people frequently forget about the former when focusing on the latter. So absolutely we need to be considered when replacing battle tested software with an entirely new code. It’s not an unfair meme when people state this.

Like I said, over half of security bugs are the kind of bug that Rust protects you against, whereas the other half (apparently more like a quarter, per side thread) is every other category of bug put together. So unless your model is that every other category of bug will be significantly increased by a rewrite, the rewrite wins out on net.

> If it were an easy and risk free upgrade then we’d have already done so in one of the other safer languages that predate Rust. A lot of what’s changed between then and now isn’t that languages have gotten better, it’s simply that Rust is trendier than any of the safer languages before them.

Per another side thread, I do agree that the reason people are rewriting in Rust now when they weren't rewriting in OCaml 10 years ago is mostly trendiness. But I disagree about which of those two decisions is the mistake.

> Like I said, over half of security bugs are the kind of bug that Rust protects you against, whereas the other half (apparently more like a quarter, per side thread) is every other category of bug put together. So unless your model is that every other category of bug will be significantly increased by a rewrite, the rewrite wins out on net.

Rewrite does increase other types of bugs though. But the more specific point I’m making is that the domain matters massively here. A buffer overflow bug in ‘cat’ isn’t equivalent to a buffer overflow bug in ‘openssh’. If you’re worried about RCEs in ‘cat’ then the fix isn’t to rewrite ‘cat’, it’s to fix the calling pipeline. Eg is the containerisation service secure? Using Rust as a blunt hammer to fix all security bugs demonstrates a real lack understanding about how to build hardened systems in the first place.

This is the point I’m making. Not that Rust shouldn’t be used as part of the solution but rather that people need to stop bleating on about Rust being “the” solution. People love to quote vulnerabilities in Chrome and OpenSSL as a reason everything should be rewritten in Rust but fail to understand that coreutils are called in entitled different circumstances and thus have an entirely different security model.

By the way, your blog link needs updating in your HN profile (to github.io). Some really interesting content on there and I really enjoyed your writing style too. Thanks for publishing your thoughts :)