[laumars]

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.

[lmm]

> 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.

[laumars]

> 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 :)