Hacker News Reader

Comment by fch42 | Hacker News Reader

This is true - and also misses one of the points Herb Sutter's article is making. I don't disagree at all with what seems the general sentiment here about the importance of memory safety. I also, though, don't disagree with Herb Sutter that there are other safety-relevant aspects in both programming and software deployment which aren't helped/prevented "merely" by using memsafe languages.

Say, the "typical" rust laziness ... just unwrap() because well we know for sure it can't possibly be None, right ? Do that in a form of crit code path, and while that may not open you to an exploit, it'll still down your service and damn you to a crashloop.

Yes, we should be using memsafe languages. Yes, we should be a little humble about bugs we may create. As important as it is to entirely eliminate one "critical" class, as important it is to realize even with that gone, bugs/issues/security problems will remain.

View on HN

> As important as it is to entirely eliminate one "critical" class, as important it is to realize even with that gone, bugs/issues/security problems will remain.

Sure. Nobody believes that memory safety is the sole security issue. Or at least, no serious people, or any of the organizations doing advocacy around this issue.

And just to be clear, in C++ a "bad unwrap" could become an exploitable gadget in arbitrary code execution or bypassing security checks or literally any really serious issue. Also, the same issue would show up as any one of N failures and may even be missed.

In Rust it would manifest as a DOS attack vector and the issue would be blamed to the bad unwrap 100% of the time.

So the C++ case the possible failure modes are arbitrarily serious vulnerability with poor observability and difficulty finding it. In Rust that failure mode is a mild generally non-exploitable vulnerability* that 100% of the time fails in the exact same way making monitoring & detection trivial.

* Yes, it could be a single stage of an exploit where you take down 1 service which opens up another vulnerability. But that's still a more expensive exploit (in terms of $ to discover) than if you had this problem in C++.

> Say, the "typical" rust laziness ... just unwrap() because well we know for sure it can't possibly be None, right ?

Which is safe.

> Do that in a form of crit code path, and while that may not open you to an exploit,

Oh, so you realize that it is safe.

> it'll still down your service and damn you to a crashloop.

So there isn’t an argument here.

Next.

A DOS attack is still a security vulnerability, but as I describe above it's still a better failure mode than you get with C++.

"memory-safe" != "safe".

Make a fair assessment what it means to your app / service when you have a, however controlled/contained, reproducible unexpected (by the developer) exit. Or what it means to use a hardcoded default (unwrap_or). Or what it means to pass up an Err via "?". Or to map an Err to None.

My argument is simple: The memory safety of rust is no reason to become arrogant as a programmer. It should, in fact, maybe make you more humble - what you learned about your own typical mistakes as you learned to write rust and tackle the borrow checker and decode clippy's extensive litany of sins in your source. And to consider that rust, as prime example, exists because people learned - from mistakes. From those design flaws in C/C++, namely.

Assume you make mistakes as well is likely to turn you into a better person. Definitely into a better programmer. No matter which language you use. Hopefully rust (on that I fully agree)

I will try to be more humble. Thank you.

> it'll still down your service and damn you to a crashloop.

Nope. Your service will be structured such that it is subdivided in tasks, each task being wrapped in a `catch_unwind`[1], such that a panic merely kills the task it occurs in, not your service.

[1]: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

Reply on news.ycombinator.com