5 ms·

Or put another way, find a language, any language, that defines all possible scenarios of a file system race condition in a multi threading & multi process syst

Or put another way, find a language, any language, that defines all possible scenarios of a file system race condition in a multi threading & multi process system. It's not possible to do such a thing, and of course nobody does. They just avoid using the term "undefined behavior" even though it absolutely is. Which makes this whole thread absolutely absurd. It's the worst possible example of Rust vs. C++ CVE as the language doesn't get an opinion here at all in the first place

nindalf 3y ago
No, it's an excellent example. Rust issued a CVE, an immediate point release with a fix for the issue and a blog post explaining the problem and what they did. 2 C++ implementations fixed the issue, but no CVE or blog post. No point release either AFAIK. You harp on the fact that this is undefined in all languages. Yeah sure. But some languages take the report seriously and communicate that to their users. They don't hide behind "spec says UB" or "it's the file system's fault". They take accountability and fix it. Other languages don't because that's the prevailing culture there. That's what you're missing when you're trying to make it seem like there's no difference between Rust and C++. There's a vast difference in how each community takes security. That's why its meaningless to compare the number of CVEs in both languages. Even if C++ reduced the number of CVEs by 90% it still would not be as secure as Rust because 1 C++ CVE is not the same as 1 Rust CVE.
- kllrnohj 3y ago
  You're moving the goalposts so fast you could be competing with C++ for prioritizing performance over soundness. Reminder that your original claim was: > The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed. Now it's degraded to just "but there wasn't a CVE or blog post!" which isn't even that relevant to the broader argument of Herb's that all the language guarantees don't prevent logic bugs (hence how Rust was able to have this CVE in the first place). There's a point of "good enough" for the language itself. Nobody is making any argument that CVE count is the best or optimal metric for anything
  - nindalf 3y ago
    I didn't move the goalposts. I was going off my recollection at the time, which was a discussion around the Rust blog post and CVE. Here's a comment from me a day ago saying "I stand corrected" (https://news.ycombinator.com/item?id=39680754 https://news.ycombinator.com/item?id=39680754). > Nobody is making any argument that CVE count is the best or optimal metric for anything Except, you know, Herb Sutter in the article we're supposedly discussing. He's arguing that it's possible to compare Rust and C++ CVEs and that C++ would be just as good as Rust if the CVE counts were similar. If you took the trouble of addressing the substance of my comment that Rust and C++ CVEs aren't comparable, rather than exulting in being technically correct because you found a mistake, you would have realised that. You're welcome to assume bad faith of me, but that was the substance of my comment. I'm sorry I didn't keep in touch with every commit made to C++ compiler repos and I spoke out of turn. But I never moved the goalposts - those were always fixed on the issue that comparing CVEs between a language that takes security seriously and one that doesn't is a dumb idea.
    - kllrnohj 3y ago
      > Except, you know, Herb Sutter in the article we're supposedly discussing "Saying the quiet part out loud: CVEs are known to be an imprecise metric. We use it because it’s the metric we have, at least for security vulnerabilities, but we should use it with care. This may surprise you, as it did me, because we hear a lot about CVEs. But whenever I’ve suggested improvements for C++ and measuring “success” via a reduction in CVEs (including in this essay), security experts insist to me that CVEs aren’t a great metric to use… including the same experts who had previously quoted the 70% CVE number to me. " -Herb Sutter That's from the article we're discussing and you knew that because you also acknowledged that: > The author concedes that CVEs are not a good metric to measure by, but implies that maybe C and C++ have too many CVEs that shouldn't actually be CVEs and that the C++ community should take more control of CVEs being filed. This is ominous, and makes me fear we might start to see fewer C and C++ CVEs because issues will be closed as "intended behaviour" or "won't fix", like the filesystem issue above. So you know that Herb isn't arguing that CVEs are ideal. You instead took a wrong baseline assumption (that C++ didn't care about the FS issue) and turned it into some weird claim that the result will just be the C++ community refusing to fix or acknowledge CVEs in order to drive the count down. You're arguing two conflicting ideas: Point 1: C++ is bad because there's no one ensuring CVEs & blog posts are filed for issues Point 2: C++ is bad because a central CVE would just let them hide the issues they're desperate to hide Despite your only evidence for either of these being something you made up entirely, as you eventually reluctantly admitted.

nindalf 3y ago

No, it's an excellent example. Rust issued a CVE, an immediate point release with a fix for the issue and a blog post explaining the problem and what they did. 2 C++ implementations fixed the issue, but no CVE or blog post. No point release either AFAIK. You harp on the fact that this is undefined in all languages. Yeah sure. But some languages take the report seriously and communicate that to their users. They don't hide behind "spec says UB" or "it's the file system's fault". They take accountability and fix it. Other languages don't because that's the prevailing culture there. That's what you're missing when you're trying to make it seem like there's no difference between Rust and C++. There's a vast difference in how each community takes security. That's why its meaningless to compare the number of CVEs in both languages. Even if C++ reduced the number of CVEs by 90% it still would not be as secure as Rust because 1 C++ CVE is not the same as 1 Rust CVE.

kllrnohj 3y ago
You're moving the goalposts so fast you could be competing with C++ for prioritizing performance over soundness. Reminder that your original claim was: > The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed. Now it's degraded to just "but there wasn't a CVE or blog post!" which isn't even that relevant to the broader argument of Herb's that all the language guarantees don't prevent logic bugs (hence how Rust was able to have this CVE in the first place). There's a point of "good enough" for the language itself. Nobody is making any argument that CVE count is the best or optimal metric for anything
- nindalf 3y ago
  I didn't move the goalposts. I was going off my recollection at the time, which was a discussion around the Rust blog post and CVE. Here's a comment from me a day ago saying "I stand corrected" (https://news.ycombinator.com/item?id=39680754 https://news.ycombinator.com/item?id=39680754). > Nobody is making any argument that CVE count is the best or optimal metric for anything Except, you know, Herb Sutter in the article we're supposedly discussing. He's arguing that it's possible to compare Rust and C++ CVEs and that C++ would be just as good as Rust if the CVE counts were similar. If you took the trouble of addressing the substance of my comment that Rust and C++ CVEs aren't comparable, rather than exulting in being technically correct because you found a mistake, you would have realised that. You're welcome to assume bad faith of me, but that was the substance of my comment. I'm sorry I didn't keep in touch with every commit made to C++ compiler repos and I spoke out of turn. But I never moved the goalposts - those were always fixed on the issue that comparing CVEs between a language that takes security seriously and one that doesn't is a dumb idea.
  - kllrnohj 3y ago
    > Except, you know, Herb Sutter in the article we're supposedly discussing "Saying the quiet part out loud: CVEs are known to be an imprecise metric. We use it because it’s the metric we have, at least for security vulnerabilities, but we should use it with care. This may surprise you, as it did me, because we hear a lot about CVEs. But whenever I’ve suggested improvements for C++ and measuring “success” via a reduction in CVEs (including in this essay), security experts insist to me that CVEs aren’t a great metric to use… including the same experts who had previously quoted the 70% CVE number to me. " -Herb Sutter That's from the article we're discussing and you knew that because you also acknowledged that: > The author concedes that CVEs are not a good metric to measure by, but implies that maybe C and C++ have too many CVEs that shouldn't actually be CVEs and that the C++ community should take more control of CVEs being filed. This is ominous, and makes me fear we might start to see fewer C and C++ CVEs because issues will be closed as "intended behaviour" or "won't fix", like the filesystem issue above. So you know that Herb isn't arguing that CVEs are ideal. You instead took a wrong baseline assumption (that C++ didn't care about the FS issue) and turned it into some weird claim that the result will just be the C++ community refusing to fix or acknowledge CVEs in order to drive the count down. You're arguing two conflicting ideas: Point 1: C++ is bad because there's no one ensuring CVEs & blog posts are filed for issues Point 2: C++ is bad because a central CVE would just let them hide the issues they're desperate to hide Despite your only evidence for either of these being something you made up entirely, as you eventually reluctantly admitted.