4 ms·

> If there were 90-98% fewer C++ type/bounds/initialization/lifetime vulnerabilities we wouldn’t be having this discussion. I disagree. We shouldn’t aim for 90

> If there were 90-98% fewer C++ type/bounds/initialization/lifetime vulnerabilities we wouldn’t be having this discussion. I disagree. We shouldn’t aim for 90-98%. We should aim for 100%. Reason: unlike logic errors, memory safety bugs are exploitable more often than not. Logic errors are usually just some useless glitch and only sometimes exploitable. > rust has 6 CVE’s Couldn’t quickly check if any of those six were memory safety or not. It’s sad that rust still has memory safety issues and if that’s true then my conclusion is that rust isn’t safe enough.

steveklabnik 3y ago
> It’s sad that rust still has memory safety issues and if that’s true then my conclusion is that rust isn’t safe enough. Let's assume all the CVEs are memory safety issues (some are not, some are, in reality.) Even then, they're things like "a bug in the standard library" that was then fixed. All software has occasional bugs. It is not possible to never have bugs.
- aapoalas 3y ago
  In workplace safety, at least in my country, there is a commonly accepted level to aim for: No accidents. It makes sense in a way. If you don't aim for zero, what do you aim for? A few hands lost in a month? A few crushed fingers? In this viewpoint I'd argue that aiming for a 98% reduction is a bit absurd: "Yeah we had an issue but it was the only one this month so it's within our budget." Of course, goals are not the same as realised results. Getting a 98% reduction should be considered a huge, huge win. The next step should then be "what can we do to get rid of the rest?" Or at least the alternative seems odd: "We got this far, job done, nothing useful to do anymore." Of course, the means will change. If C++ guarantees full memory safety next month, then the next steps after that won't be more memory safety but something else.
  - pizlonator 3y ago
    That's a really good way of stating what I believe. :-) If C++ had memory safety next month then the next step would be to add stronger types. Once memory safety is a thing, you can start to add types that describe contracts and then you can ensure lots of interesting logical safety properties that aren't memory safety.
  - Georgelemental 3y ago
    > there is a commonly accepted level to aim for: No accidents. But you also balance that goal against practical reality. For example, you could end workplace accidents by outlawing work and having everyone starve to death, but that's not done because the costs are too high.
- pizlonator 3y ago
  I think "bug in stdlib" is forgivable, and I wouldn't fault Rust for it, exactly for the reason you say. It would be a great outcome if Rust's compiler and stdlib became a trusted compute base and folks had to be extra careful there. It's not a great outcome if there are memory safety bugs arising from how some Rust programmer did some stuff. So, I would revise my statement to: "It would be sad if Rust had memory safety issues that any user of the language could run into, and if that was true, then my conclusion would be that Rust isn't safe enough."

steveklabnik 3y ago

> It’s sad that rust still has memory safety issues and if that’s true then my conclusion is that rust isn’t safe enough. Let's assume all the CVEs are memory safety issues (some are not, some are, in reality.) Even then, they're things like "a bug in the standard library" that was then fixed. All software has occasional bugs. It is not possible to never have bugs.

aapoalas 3y ago
In workplace safety, at least in my country, there is a commonly accepted level to aim for: No accidents. It makes sense in a way. If you don't aim for zero, what do you aim for? A few hands lost in a month? A few crushed fingers? In this viewpoint I'd argue that aiming for a 98% reduction is a bit absurd: "Yeah we had an issue but it was the only one this month so it's within our budget." Of course, goals are not the same as realised results. Getting a 98% reduction should be considered a huge, huge win. The next step should then be "what can we do to get rid of the rest?" Or at least the alternative seems odd: "We got this far, job done, nothing useful to do anymore." Of course, the means will change. If C++ guarantees full memory safety next month, then the next steps after that won't be more memory safety but something else.
- pizlonator 3y ago
  That's a really good way of stating what I believe. :-) If C++ had memory safety next month then the next step would be to add stronger types. Once memory safety is a thing, you can start to add types that describe contracts and then you can ensure lots of interesting logical safety properties that aren't memory safety.
- Georgelemental 3y ago
  > there is a commonly accepted level to aim for: No accidents. But you also balance that goal against practical reality. For example, you could end workplace accidents by outlawing work and having everyone starve to death, but that's not done because the costs are too high.
pizlonator 3y ago
I think "bug in stdlib" is forgivable, and I wouldn't fault Rust for it, exactly for the reason you say. It would be a great outcome if Rust's compiler and stdlib became a trusted compute base and folks had to be extra careful there. It's not a great outcome if there are memory safety bugs arising from how some Rust programmer did some stuff. So, I would revise my statement to: "It would be sad if Rust had memory safety issues that any user of the language could run into, and if that was true, then my conclusion would be that Rust isn't safe enough."