3 ms·

Rust generally does consider "you're holding it wrong" type bugs to be safety issues. See for example [0], where the Rust developers filed a CVE for (and fixed

Rust generally does consider "you're holding it wrong" type bugs to be safety issues. See for example [0], where the Rust developers filed a CVE for (and fixed) an issue in the standard library which the C / C++ communities mostly considered a holding-it-wrong issue. [0] https://www.reddit.com/r/cpp/comments/151cnlc/a_safety_culture_and_c_we_need_to_talk_about/ https://www.reddit.com/r/cpp/comments/151cnlc/a_safety_cultu...

bregma 3y ago
A you're-holding-it-wrong that still got fixed in all the major C++ standard library implementations.
- pests 3y ago
  Fixed?
  - bregma 3y ago
    Code was added to libc++ and libstdc++ to avoid the TOCTOU exploit documented in the CVE. "Fixed" in this case means the source code for the library was modified to prevent the documented exploit, and test cases were added to their test suites to exercise the code. Not sure about the Microsoft C++ standard library since the Microsoft Windows system API does not provide the same softlink functionalty.
jacquesm 3y ago
But: they are holding it wrong and it got fixed regardless because if you can fix such stuff you should. For Rust such a CVE is nearly free given the installed base of Rust and the fact that most of that code is fresh and in maintenance. But that definitely isn't true for all of the instances of glibc that are currently deployed.
- megous 3y ago
  Well, a fix in glibc fixed it across the whole system and for all already compiled programs. Can you say the same for Rust?
  - nequo 3y ago
    Dynamic linking is something that I would personally like to see in Rustland too. But parent's point is that some issues that count as a CVE for Rust do not count as such for C/C++ because the boundaries of undefined behavior are drawn elsewhere. This means that there are many fixes that are simply never made for C/C++, even though dynamic linking would make such a counterfactual fix easier to deploy.
    - megous 3y ago
      Parent point was that such CVE could be fixed in Rust super cheaply (free) because code is maintained. If I have to reinstall the whole system to fix CVE in Rust stdlib in a brave new world where everything is written in Rust, then it's certainly not free fix.
      - nequo 3y ago
        I actually think you're right. Apologies. I also don't see deploying a glibc fix as particularly costly.
      - jacquesm 3y ago
        But we don't live in that brave new world and we're talking about now, not some hypothetical.
cozzyd 3y ago
Is calling free with the wrong address a safety issue or "you're holding it wrong."
- dureuill 3y ago
  It is both. "Memory safe" means that if the user is "holding it wrong", it won't cause a memory error. In safe Rust, it is impossible to call free with the wrong address (simply by virtue of the `free` equivalent being unsafe, and with the pervasive use of smart pointers to make it practical to stay in safe land). Similarly even if you "hold it wrong" and use a wrong comparison function in Rust's sort, you might get nonsensical results, but no memory errors. That's precisely what safety means in this context
tialaramex 3y ago
In particular, most traits you've seen for Rust, such as PartialEq, or here Ord (a claim that our type is totally ordered) are safe traits, this means you don't need to utter the unsafe keyword to implement these traits, and so even though Rust clearly documents the traits as having specific requirements in fact it promises it won't actually cause UB if you ignore them, and the users of that trait must behave accordingly. My misfortunate crate https://crates.io/crates/misfortunate https://crates.io/crates/misfortunate is a library of types that just deliberately implement various traits "wrongly" in order that you can play with the consequences. For example Clone promises to uh, clone things, but Rust can't know if this Doodad is really a "clone" of that Doodad, only that the result was really the correct type, so if your type only implements Default my Multiplicity type wrapper will cheerfully claim it can be cloned anyway, cloning the wrapper doesn't get you a "real" clone but only your Default - the types look correct but what's inside is not a "clone" in any reasonable sense. Rust does have what it calls unsafe traits, traits which you cannot implement without writing the "unsafe" keyword. They are solemn promises that you did what the documentation told you to, if you messed up in writing the unsafe trait then the resulting software may have Undefined Behaviour. For example, my type wrapper Comte (named after the guy who invented the trick with a hat you've seen magicians do) claims to be an ExactSizeIterator. If it has one rabbit inside it, duh, exact size. Nope, it's a trick, we can just tap the Comte with our wand and produce an unlimited number of rabbits despite claiming to be an ExactSizeIterator, that's a bad idea but it's not Undefined Behaviour. On the other hand Rust has the unsafe TrustedLen, which also says we can trust this iterator knows exactly how big it is, but because it's unsafe that's a solemn promise, if we took the Comte code but claimed to implement TrustedLen we're just despicable liars.

bregma 3y ago

A you're-holding-it-wrong that still got fixed in all the major C++ standard library implementations.

pests 3y ago
Fixed?
- bregma 3y ago
  Code was added to libc++ and libstdc++ to avoid the TOCTOU exploit documented in the CVE. "Fixed" in this case means the source code for the library was modified to prevent the documented exploit, and test cases were added to their test suites to exercise the code. Not sure about the Microsoft C++ standard library since the Microsoft Windows system API does not provide the same softlink functionalty.

jacquesm 3y ago

But: they are holding it wrong and it got fixed regardless because if you can fix such stuff you should. For Rust such a CVE is nearly free given the installed base of Rust and the fact that most of that code is fresh and in maintenance. But that definitely isn't true for all of the instances of glibc that are currently deployed.

megous 3y ago
Well, a fix in glibc fixed it across the whole system and for all already compiled programs. Can you say the same for Rust?
- nequo 3y ago
  Dynamic linking is something that I would personally like to see in Rustland too. But parent's point is that some issues that count as a CVE for Rust do not count as such for C/C++ because the boundaries of undefined behavior are drawn elsewhere. This means that there are many fixes that are simply never made for C/C++, even though dynamic linking would make such a counterfactual fix easier to deploy.
  - megous 3y ago
    Parent point was that such CVE could be fixed in Rust super cheaply (free) because code is maintained. If I have to reinstall the whole system to fix CVE in Rust stdlib in a brave new world where everything is written in Rust, then it's certainly not free fix.
    - nequo 3y ago
      I actually think you're right. Apologies. I also don't see deploying a glibc fix as particularly costly.
    - jacquesm 3y ago
      But we don't live in that brave new world and we're talking about now, not some hypothetical.

cozzyd 3y ago

Is calling free with the wrong address a safety issue or "you're holding it wrong."

dureuill 3y ago
It is both. "Memory safe" means that if the user is "holding it wrong", it won't cause a memory error. In safe Rust, it is impossible to call free with the wrong address (simply by virtue of the `free` equivalent being unsafe, and with the pervasive use of smart pointers to make it practical to stay in safe land). Similarly even if you "hold it wrong" and use a wrong comparison function in Rust's sort, you might get nonsensical results, but no memory errors. That's precisely what safety means in this context

tialaramex 3y ago

In particular, most traits you've seen for Rust, such as PartialEq, or here Ord (a claim that our type is totally ordered) are safe traits, this means you don't need to utter the unsafe keyword to implement these traits, and so even though Rust clearly documents the traits as having specific requirements in fact it promises it won't actually cause UB if you ignore them, and the users of that trait must behave accordingly. My misfortunate crate https://crates.io/crates/misfortunate https://crates.io/crates/misfortunate is a library of types that just deliberately implement various traits "wrongly" in order that you can play with the consequences. For example Clone promises to uh, clone things, but Rust can't know if this Doodad is really a "clone" of that Doodad, only that the result was really the correct type, so if your type only implements Default my Multiplicity type wrapper will cheerfully claim it can be cloned anyway, cloning the wrapper doesn't get you a "real" clone but only your Default - the types look correct but what's inside is not a "clone" in any reasonable sense. Rust does have what it calls unsafe traits, traits which you cannot implement without writing the "unsafe" keyword. They are solemn promises that you did what the documentation told you to, if you messed up in writing the unsafe trait then the resulting software may have Undefined Behaviour. For example, my type wrapper Comte (named after the guy who invented the trick with a hat you've seen magicians do) claims to be an ExactSizeIterator. If it has one rabbit inside it, duh, exact size. Nope, it's a trick, we can just tap the Comte with our wand and produce an unlimited number of rabbits despite claiming to be an ExactSizeIterator, that's a bad idea but it's not Undefined Behaviour. On the other hand Rust has the unsafe TrustedLen, which also says we can trust this iterator knows exactly how big it is, but because it's unsafe that's a solemn promise, if we took the Comte code but claimed to implement TrustedLen we're just despicable liars.