Comment by uid65534 | Hacker News Reader

Comment by uid65534 | Hacker News Reader

Parent Full thread

Having the tool actively prevent classes of errors is a worthwhile endeavor, but I do agree it gets overly focused on alone when several other _massive_ classes of vulnerabilities continue to be introduced. At a high level though, it is a lot easier to just have a framework enforce 'x' on all devs to raise the minimum bar. It doesn't help that the average Rust-bro, from which a lot of these memory safety arguments come from, is utterly terrible at making that case in reality. Case example: https://github.com/pyca/cryptography/issues/5771.

I think a lot of the arguments around C++ for example being 'memory unsafe' is a bit ridiculous because its trivial to write memory safe C++. Just run -Wall and enforce the use of smart pointers, there are nearly zero instances in the modern day where you should be dealing with raw pointers or performing offsets that lead to these bugs directly. The few exceptions are hopefully with devs that are intelligent enough to do so safely with modern language features. Unfortunately, this rarely gets focused on by security teams it seems since they are instead chasing the newest shiny language like you mention.

> its trivial to write memory safe C++

It is not unfortunately. That's why we see memory safety being responsible for 70% of severe vulns across many C and C++ projects.

Some of the reasons include: - C++ does little to prevent out-of-bounds vulns - Preventing use-after-free with smart pointers requires heavy use of shared pointers, which often incurs a performance cost that is unacceptable in the environment C++ is used.

> It is not unfortunately. That's why we see memory safety being responsible for 70% of severe vulns across many C and C++ projects.

I don't think that's really a rebuttal to what they're trying to say. If the vast majority of C++ devs don't follow those two rules, then that's not much evidence against those two rules providing memory safety.

Right but the reason they don't follow those 2 rules is that using them would require not using most C++ libraries that don't follow the rules, and would introduce performance regressions that negate the main reason they chose C++ in the first place.

This entire post is about a gradual transition. You don't have to avoid libraries that break the rules, you just have to accept that they're outside the safe zone.

For performance, you'll have to be more specific about your shared pointer claims. But I bet that it's a very small fraction of C++ functions that need the absolute best performance and can't avoid those performance problems while following the two rules.

> its trivial to write memory safe C++.

Very bold claim, and as such, it needs substantial evidence, as there is practically no meaningful evidence to support this. There are some real world non-trivial c++ code that are known to have very few defects, but almost all of them required extremely significant effort to get there.

What does "enforce the use of smart pointers" actually mean? Idiomatic C++ uses "this" and references ubiquitously, both of which are vulnerable to use-after-free bugs just like raw pointers.

Reply on news.ycombinator.com