Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Replacements for existing software written in Rust

github.com

Post reply on HN
Print view View original

221–229 of 229 posts

Re: Replacements for existing software written in Rust

#221

Post by lmm »

laumars wrote: post #219
lmm wrote: post #217

Earlier quoted context omitted.

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

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.

Re: Replacements for existing software written in Rust

#222

Post by laumars »

lmm wrote: post #221
laumars wrote: post #219

Earlier quoted context omitted.

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…

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.

Re: Replacements for existing software written in Rust

#223

Post by wtetzner »

de_keyboard wrote: post #5

Am I the only one who doesn't care what a tool / software package is written in, provided it does the job? If a Rust port is superior then sure, I'll use it, but I won't use it because it was written in Rust.

I guess it depends on whether or not you want to work on the code of the tools, vs just use them.

Re: Replacements for existing software written in Rust

#224

Post by zurn »

laumars wrote: post #156
zurn wrote: post #91

Earlier quoted context omitted.

Are you implying that Rust is only / mostly used as a replacement for unsafe C/C++, and Rust programs should always be evaluated in the context of this choice?

No, I’m arguing against that mindset. The git repository is what raises the “Replaced It In Rust” argument.

The safety issue or comparison against C/C++ was not mentioned in the submission. So I don't follow why the protest against replacements for Haskell programs, based on a safety argument.

Re: Replacements for existing software written in Rust

#225

Post by lmm »

laumars wrote: post #222
lmm wrote: post #221

Earlier quoted context omitted.

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…

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 Heartbl…

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

Re: Replacements for existing software written in Rust

#226

Post by laumars »

lmm wrote: post #225
laumars wrote: post #222

Earlier quoted context omitted.

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 Heartbl…

> 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 thi…

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

Re: Replacements for existing software written in Rust

#227

Post by clappski »

pdimitar wrote: post #177
burntsushi wrote: post #145

Earlier quoted context omitted.

The GP is either being incorrectly absolutist, or left out an important qualifier: "In safe Rust, the chances of are zero." But that is also absolutist. Instead, you might say, "In safe Rust, the chances of are zero, modulo bugs in the compiler." But that's not quite the fully story either. So instead, you might say, "In safe Rust, the chances of are zero, modulo bugs in the compiler or any dependencies or any other…

What I simply meant was "it's quite hard to introduce memory non-safety in Rust in a normal everyday work". But your explanation is definitely much more precise.

I suppose that depends on your definition of normal everyday work though, if you're developing device drivers or something that needs to write into shared mmap'd memory or whatever `unsafe` is something you're going to need all the time (from my 0 rust experience understanding?)

Re: Replacements for existing software written in Rust

#228

Post by pdimitar »

clappski wrote: post #227
pdimitar wrote: post #177

Earlier quoted context omitted.

What I simply meant was "it's quite hard to introduce memory non-safety in Rust in a normal everyday work". But your explanation is definitely much more precise.

I suppose that depends on your definition of normal everyday work though, if you're developing device drivers or something that needs to write into shared mmap'd memory or whatever `unsafe` is something you're going to need all the time (from my 0 rust experience understanding?)

Agreed, that is true.

Nobody is saying Rust is completely bullet-proof: if anything, our current hardware doesn't allow for it.

But it gets very close.

Re: Replacements for existing software written in Rust

#229

Post by clappski »

burntsushi wrote: post #145
clappski wrote: post #141

Earlier quoted context omitted.

> the chances for triggering a buffer underflow / overflow exploit are zero Doesn't the mere existence of unsafe make this untrue? From a quick google I can see at least one[1] so the chances are definitely a lot higher than zero [1] https://github.com/servo/rust-smallvec/issues/252

The GP is either being incorrectly absolutist, or left out an important qualifier: "In safe Rust, the chances of are zero." But that is also absolutist. Instead, you might say, "In safe Rust, the chances of are zero, modulo bugs in the compiler." But that's not quite the fully story either. So instead, you might say, "In safe Rust, the chances of are zero, modulo bugs in the compiler or any dependencies or any other…

Thanks, that last bit clears it up for me. I've never touched Rust but write C++ everyday so don't really know much about what is guaranteed vs. what is less likely due to borrow checking/compiler verifaction
Post reply on HN