6 ms·

> It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C+

> It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed. Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all. Case in point, this was fixed in both major C++ libraries: https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d8c82c2d47771ee89192b8 https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d... https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9e24e171201db189b661700bf https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9... So what C++ community refused to regard this as an issue and refused to fix it? Where is your supporting evidence for your claims?

nindalf 3y ago
I stand corrected that the issue wasn't fixed (https://news.ycombinator.com/item?id=39680006 https://news.ycombinator.com/item?id=39680006). The issue was fixed, but no CVE by the C++ libraries. That reinforces the point that the author's attempt to equate 1 Rust CVE = 1 C++ CVE isn't valid.
kouteiheika 3y ago
> Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all. Relevant piece of the standard: http://eel.is/c++draft/fs.race.behavior#1.sentence-2 http://eel.is/c++draft/fs.race.behavior#1.sentence-2 Officially it's undefined behavior. And here's a comment from the maintainer of the STL in MSVC regarding this: https://old.reddit.com/r/cpp/comments/151cnlc/a_safety_culture_and_c_we_need_to_talk_about/js8m9sp/ https://old.reddit.com/r/cpp/comments/151cnlc/a_safety_cultu...
- kllrnohj 3y ago
  That statement really doesn't support your claim and unsurprisingly Rust has the same basic caveat because of course it does, it's not possible for a language to guarantee exclusive IO access to the filesystem. https://doc.rust-lang.org/std/io/index.html#io-safety https://doc.rust-lang.org/std/io/index.html#io-safety
  - vlovich123 3y ago
    The Rust docs say something substantively different about safety from what the C++ standard says. The Rust docs are talking about the safety and soundness of keeping track of the fd ownership. The C++ standard says that FS races are UB.
    - kllrnohj 3y ago
      FS races in Rust are UB as well, they're just scared to say that very explicitly. They hide behind this phrasing: "Many I/O functions throughout the standard library are documented to indicate what various library or syscalls they are delegated to. " And just think about it rationally for a second. The FS is implemented by the kernel, which doesn't give a damn what language you're using. So Rust cannot possibly guarantee anything about it. Everything about Rust's FS API is every bit as full of UB as C++'s because it's a shared system with external processes - Rust can't guarantee shit. They just make you go look up what the syscalls are to find out what the guarantees (or lack-thereof) actually are instead.
      - nindalf 3y ago
        > Rust can't guarantee shit And yet, the Rust community takes it seriously, issuing a CVE, a point release and a blog post. You won't find these 3 from all 3 major C++ implementations (clang, gcc and msvc) because they don't take the issue as seriously because their spec says they don't have to. Rust can't guarantee shit but at least they do shit when there's a problem. They take accountability for their shit. You keep harping on minor nitpicks, but you can't escape the fact that the C++ community did not take this issue as seriously as Rust did. Therefore it is meaningless to compare CVEs across the two ecosystems, which was the substance of the top level comment.
        kllrnohj 3y ago
        > because they don't take the issue as seriously because their spec says they don't have to. And yet they all quickly fixed the issue and nobody tried to hide behind "the spec" Should there have been a CVE? Probably. But there's no central C++ CVE committee to have done that, either, which to Herb's point there probably should be. Should there have been a blog post? Probably not. People don't ship their own standard library, so the blog post is low value. What matters is whether or not distros/OS's picked up that fix promptly. Which unfortunately is hard to find out since most Linux distros suck ass at keeping their standard libraries up to date.
Kranar 3y ago
Saying it was fixed in two of the three C++ standard libraries is irrelevant, the language standard itself specifies that the behavior is undefined. This would be like saying C++ the language fixed buffer overflows because GCC added bounds checking. Most sensible C++ developers know that you should not depend on undefined behavior to write correct software, and yet your argument that because some implementations (not all) have decided to provide semantics for this, that it's now okay to use it or no longer a problem.
- gpderetta 3y ago
  Most sensible developers develop software against compiler specifications, not the standard. Very very little useful software can be implemented strictly within what's offered by the standard.
  - temac 3y ago
    That's very not a reason to justify the critical shortcomings of a standard, especially so when implementations are known to make their practical safeties regress in the name of they are allowed by the letter. In that context the very culture of C++ normalizers and implementers has to change and the introduction of this paper is a step in the wrong direction in that regard.
    - gpderetta 3y ago
      Realistically the only improvement to the spec is changing fs races from undefined behaviour to something less program-invalidating. But to what? Unspecified behaviour would require the standard to give a set of possible outcomes which might not be implementable. Implementation defined would still require the compiler to pick and document a specific behaviour which might also not be possible to guarantee. The only way to provide stronger guarantees is to rigorously define the behaviour of the OS, which is of course not possible. Not even POSIX does that and of course C++ targets beyond POSIX. The reality is that there are a lot of things that are commonly done that are formally undefined (for example mmap, ldopen, openmp) and the user has to look for details beyond the C++ standard and into other documents (other standards, the compiler manual). The alternative is a fully defined isolated sandbox, but that would be pointless for a system language and not even Java attempts that.

nindalf 3y ago

I stand corrected that the issue wasn't fixed (https://news.ycombinator.com/item?id=39680006 https://news.ycombinator.com/item?id=39680006). The issue was fixed, but no CVE by the C++ libraries. That reinforces the point that the author's attempt to equate 1 Rust CVE = 1 C++ CVE isn't valid.

kouteiheika 3y ago

> Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all. Relevant piece of the standard: http://eel.is/c++draft/fs.race.behavior#1.sentence-2 http://eel.is/c++draft/fs.race.behavior#1.sentence-2 Officially it's undefined behavior. And here's a comment from the maintainer of the STL in MSVC regarding this: https://old.reddit.com/r/cpp/comments/151cnlc/a_safety_culture_and_c_we_need_to_talk_about/js8m9sp/ https://old.reddit.com/r/cpp/comments/151cnlc/a_safety_cultu...

kllrnohj 3y ago
That statement really doesn't support your claim and unsurprisingly Rust has the same basic caveat because of course it does, it's not possible for a language to guarantee exclusive IO access to the filesystem. https://doc.rust-lang.org/std/io/index.html#io-safety https://doc.rust-lang.org/std/io/index.html#io-safety
- vlovich123 3y ago
  The Rust docs say something substantively different about safety from what the C++ standard says. The Rust docs are talking about the safety and soundness of keeping track of the fd ownership. The C++ standard says that FS races are UB.
  - kllrnohj 3y ago
    FS races in Rust are UB as well, they're just scared to say that very explicitly. They hide behind this phrasing: "Many I/O functions throughout the standard library are documented to indicate what various library or syscalls they are delegated to. " And just think about it rationally for a second. The FS is implemented by the kernel, which doesn't give a damn what language you're using. So Rust cannot possibly guarantee anything about it. Everything about Rust's FS API is every bit as full of UB as C++'s because it's a shared system with external processes - Rust can't guarantee shit. They just make you go look up what the syscalls are to find out what the guarantees (or lack-thereof) actually are instead.
    - nindalf 3y ago
      > Rust can't guarantee shit And yet, the Rust community takes it seriously, issuing a CVE, a point release and a blog post. You won't find these 3 from all 3 major C++ implementations (clang, gcc and msvc) because they don't take the issue as seriously because their spec says they don't have to. Rust can't guarantee shit but at least they do shit when there's a problem. They take accountability for their shit. You keep harping on minor nitpicks, but you can't escape the fact that the C++ community did not take this issue as seriously as Rust did. Therefore it is meaningless to compare CVEs across the two ecosystems, which was the substance of the top level comment.
      - kllrnohj 3y ago
        > because they don't take the issue as seriously because their spec says they don't have to. And yet they all quickly fixed the issue and nobody tried to hide behind "the spec" Should there have been a CVE? Probably. But there's no central C++ CVE committee to have done that, either, which to Herb's point there probably should be. Should there have been a blog post? Probably not. People don't ship their own standard library, so the blog post is low value. What matters is whether or not distros/OS's picked up that fix promptly. Which unfortunately is hard to find out since most Linux distros suck ass at keeping their standard libraries up to date.

Kranar 3y ago

Saying it was fixed in two of the three C++ standard libraries is irrelevant, the language standard itself specifies that the behavior is undefined. This would be like saying C++ the language fixed buffer overflows because GCC added bounds checking. Most sensible C++ developers know that you should not depend on undefined behavior to write correct software, and yet your argument that because some implementations (not all) have decided to provide semantics for this, that it's now okay to use it or no longer a problem.

gpderetta 3y ago
Most sensible developers develop software against compiler specifications, not the standard. Very very little useful software can be implemented strictly within what's offered by the standard.
- temac 3y ago
  That's very not a reason to justify the critical shortcomings of a standard, especially so when implementations are known to make their practical safeties regress in the name of they are allowed by the letter. In that context the very culture of C++ normalizers and implementers has to change and the introduction of this paper is a step in the wrong direction in that regard.
  - gpderetta 3y ago
    Realistically the only improvement to the spec is changing fs races from undefined behaviour to something less program-invalidating. But to what? Unspecified behaviour would require the standard to give a set of possible outcomes which might not be implementable. Implementation defined would still require the compiler to pick and document a specific behaviour which might also not be possible to guarantee. The only way to provide stronger guarantees is to rigorously define the behaviour of the OS, which is of course not possible. Not even POSIX does that and of course C++ targets beyond POSIX. The reality is that there are a lot of things that are commonly done that are formally undefined (for example mmap, ldopen, openmp) and the user has to look for details beyond the C++ standard and into other documents (other standards, the compiler manual). The alternative is a fully defined isolated sandbox, but that would be pointless for a system language and not even Java attempts that.