9 ms·

> And anyway, what is “the overarching software community”? I feel that it's pretty much a consensus in the software security world that C and C++ should be av

by oytis 4y ago

> And anyway, what is “the overarching software community”? I feel that it's pretty much a consensus in the software security world that C and C++ should be avoided. Not sure why he omitted Rust from the list, it is in the original document, and is pretty much a drop-in replacement for C++. Also using a dynamic language like Ruby for anything secure or safe sounds like a terrible idea.

funnyfoobar 4y ago
Can you please expand on > Also using a dynamic language like Ruby for anything secure or safe sounds like a terrible idea afaik, it depends on how you use Ruby right? I agree that using metaprogramming could lead to issues, but i would like to hear your view points on security?
- Yoric 4y ago
  I assume this is because the number of properties that can be statically audited in Ruby (or in most dynamic programming languages) is extremely small wrt what you can do in strongly-typed programming languages such as Rust, Ada, Haskell, OCaml, F#, ... Static audits (including, but not limited to static typing) are very strong barriers against entire classes of safety issues. Not supporting them doesn't automatically make code bad, but it prevents lots of defense-in-depth (what the Rust community calls "fearless programming").
  - UncleMeat 4y ago
    Unfortunately, there are a lot of overloaded terms. Languages like Ruby are indeed nightmares for static analysis. Even constructing a call graph is a disaster. But "safety properties" includes a huge amount of stuff that isn't necessarily security relevant. Do you want to prove that your Ruby program won't crash? Good luck. But do you want to prove that your Ruby program won't read key material out of memory when it shouldn't? Pretty easy. The security problems in these sorts of managed languages tend to either be logical errors (also present in a C++ codebase) or dynamic code loading / unsafe deserialization (not present often in C++ codebases, but much easier to eliminate in principle).
    - Yoric 4y ago
      For what it's worth, I am not attempting to compare Ruby (or generally dynamic languages) to C++. I am comparing Ruby to statically, strongly-typed languages. C++ is statically typed but is generally not a strongly-typed language, since there are many ways to escape strong typing, either willingly (e.g. with a cast to `void*`) or by accident (e.g. through UB). > But "safety properties" includes a huge amount of stuff that isn't necessarily security relevant. Good remark. However, as a former safety (not security) researcher, it feels to me like the consensus in some parts of the security community is that once you have lost safety guarantees (i.e. you're not sure what your program is going to do), you have lost this entire line of defense and need to move to the next one (e.g. containerization). Example: Python has a very clear syntax and it is often easy to audit code to find out whether the algorithm implemented matches the specifications. However, Python is also a language in which `True`, `False` or integer literals can be redefined dynamically. So, with this in mind, how can you be sure that your Python code that appears to calculate fibonacci is not going to actually `ctype` into something memory-unsafe that could be used to escape into the shell? Of course, this example (and anything analogous in other dynamic languages) requires active malicious intent by the author of the code or one of the module it uses, but it's not too hard to come up with examples that end up with OS or XSS injections, without malicious intent by the code author. I believe that we both agree that these examples are safety issues escalating into security issues.*
drewm1980 4y ago
That part was a quote from the NSA. He didn't omit it. But I agree his argument would have been stronger if added to the list the most realistic C++ competitors and differentiated against those instead of the more dynamic languages.
- oytis 4y ago
  Looks like there are two lists in the linked document - one of them includes Rust and the other doesn't. My bad.
- 1wd 4y ago
  The quoted document has two similar sentences, one on page 3 includes Rust, one on page 5 does not: > Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®. > Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®. https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI... Stroustrup quotes the second one without Rust.
meibo 4y ago
Rust is definitely not a drop-in for C++, be it for interop with massive C++ codebases or developer adoption. You may be able to get your devs to switch, but your productivity will suffer so much that your stakeholders will be on your ass to figure out how to fix something there is no fix for: the mental load of Rust is a lot higher than C++'s and it takes a long time for regular people to become as proficient in it as they are having written C++ for 15 years.
- zozbot234 4y ago
  > the mental load of Rust is a lot higher than C++'s I don't believe this. That's a reasonable claim for many other languages, but C/C++ are in a category of their own.
  - FpUser 4y ago
    >"C/C++ are in a category of their own." If one wants to know it all then yes. C++ is huge language. In practice except few people nobody really needs to. Subset of modern C++ enough to solve many real world tasks is very easy to learn in my opinion. With Rust one must first train brain to wrap around those ownership rules and this might not be easy. Fortunately or not I do not know even remotely enough of Rust to do the real comparison of "mental load" but at some point I will.
    - imron 4y ago
      > With Rust one must first train brain to wrap around those ownership rules and this might not be easy. You need to do that in c++ also, otherwise you'll still have the same problem - only randomly at runtime instead of at compile time.
    - charcircuit 4y ago
      >With Rust one must first train brain to wrap around those ownership rules and this might not be easy. C++ users already understand ownership because C++ has ownership too. With C++ you have to me extra careful because the compiler won't save you from making mistakes like Rust will.
zozbot234 4y ago
> Not sure why he omitted Rust from the list, it is in the original document Nice observation, that seems to change the meaning of the paper substantially. OP might be privately admitting that you should use Rust if you can (not much that's new here, the Carbon folks said the same thing) and everything else just silently assumes that you can't do that for some reason - be it legacy or perhaps concerns about Rust's supposedly challenging learning curve. (It goes without saying that we shouldn't expect a C/C++ committee paper to outright advocate for Rust.)
FpUser 4y ago
>"Rust ... is pretty much a drop-in replacement for C++" Performance and "low-levelness" wise it most likely is. From high level point of view it messes with how one must think when writing code and is missing some features / paradigms found in modern C++ (for better or worse, not gonna dwell on it here). In my opinion it is closer to "drop-in replacement" for C.
- oytis 4y ago
  I mean modulo interop with legacy code or need for proprietary compilers Rust can be used wherever C++ is used. Not quite true for C#, Go etc.
copirate 4y ago
> Not sure why he omitted Rust from the list, it is in the original document He didn't remove Rust from the quote though. The NSA document[1] contains two lists of languages considered safe and for some reasons Rust is only included in one: > Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®. > Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift® [1] https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...

by oytis 4y ago

funnyfoobar 4y ago

Can you please expand on > Also using a dynamic language like Ruby for anything secure or safe sounds like a terrible idea afaik, it depends on how you use Ruby right? I agree that using metaprogramming could lead to issues, but i would like to hear your view points on security?

Yoric 4y ago
I assume this is because the number of properties that can be statically audited in Ruby (or in most dynamic programming languages) is extremely small wrt what you can do in strongly-typed programming languages such as Rust, Ada, Haskell, OCaml, F#, ... Static audits (including, but not limited to static typing) are very strong barriers against entire classes of safety issues. Not supporting them doesn't automatically make code bad, but it prevents lots of defense-in-depth (what the Rust community calls "fearless programming").
- UncleMeat 4y ago
  Unfortunately, there are a lot of overloaded terms. Languages like Ruby are indeed nightmares for static analysis. Even constructing a call graph is a disaster. But "safety properties" includes a huge amount of stuff that isn't necessarily security relevant. Do you want to prove that your Ruby program won't crash? Good luck. But do you want to prove that your Ruby program won't read key material out of memory when it shouldn't? Pretty easy. The security problems in these sorts of managed languages tend to either be logical errors (also present in a C++ codebase) or dynamic code loading / unsafe deserialization (not present often in C++ codebases, but much easier to eliminate in principle).
  - Yoric 4y ago
    For what it's worth, I am not attempting to compare Ruby (or generally dynamic languages) to C++. I am comparing Ruby to statically, strongly-typed languages. C++ is statically typed but is generally not a strongly-typed language, since there are many ways to escape strong typing, either willingly (e.g. with a cast to `void*`) or by accident (e.g. through UB). > But "safety properties" includes a huge amount of stuff that isn't necessarily security relevant. Good remark. However, as a former safety (not security) researcher, it feels to me like the consensus in some parts of the security community is that once you have lost safety guarantees (i.e. you're not sure what your program is going to do), you have lost this entire line of defense and need to move to the next one (e.g. containerization). Example: Python has a very clear syntax and it is often easy to audit code to find out whether the algorithm implemented matches the specifications. However, Python is also a language in which `True`, `False` or integer literals can be redefined dynamically. So, with this in mind, how can you be sure that your Python code that appears to calculate fibonacci is not going to actually `ctype` into something memory-unsafe that could be used to escape into the shell? Of course, this example (and anything analogous in other dynamic languages) requires active malicious intent by the author of the code or one of the module it uses, but it's not too hard to come up with examples that end up with OS or XSS injections, without malicious intent by the code author. I believe that we both agree that these examples are safety issues escalating into security issues.*

drewm1980 4y ago

That part was a quote from the NSA. He didn't omit it. But I agree his argument would have been stronger if added to the list the most realistic C++ competitors and differentiated against those instead of the more dynamic languages.

oytis 4y ago
Looks like there are two lists in the linked document - one of them includes Rust and the other doesn't. My bad.
1wd 4y ago
The quoted document has two similar sentences, one on page 3 includes Rust, one on page 5 does not: > Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®. > Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®. https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI... Stroustrup quotes the second one without Rust.

meibo 4y ago

Rust is definitely not a drop-in for C++, be it for interop with massive C++ codebases or developer adoption. You may be able to get your devs to switch, but your productivity will suffer so much that your stakeholders will be on your ass to figure out how to fix something there is no fix for: the mental load of Rust is a lot higher than C++'s and it takes a long time for regular people to become as proficient in it as they are having written C++ for 15 years.

zozbot234 4y ago
> the mental load of Rust is a lot higher than C++'s I don't believe this. That's a reasonable claim for many other languages, but C/C++ are in a category of their own.
- FpUser 4y ago
  >"C/C++ are in a category of their own." If one wants to know it all then yes. C++ is huge language. In practice except few people nobody really needs to. Subset of modern C++ enough to solve many real world tasks is very easy to learn in my opinion. With Rust one must first train brain to wrap around those ownership rules and this might not be easy. Fortunately or not I do not know even remotely enough of Rust to do the real comparison of "mental load" but at some point I will.
  - imron 4y ago
    > With Rust one must first train brain to wrap around those ownership rules and this might not be easy. You need to do that in c++ also, otherwise you'll still have the same problem - only randomly at runtime instead of at compile time.
  - charcircuit 4y ago
    >With Rust one must first train brain to wrap around those ownership rules and this might not be easy. C++ users already understand ownership because C++ has ownership too. With C++ you have to me extra careful because the compiler won't save you from making mistakes like Rust will.

zozbot234 4y ago

> Not sure why he omitted Rust from the list, it is in the original document Nice observation, that seems to change the meaning of the paper substantially. OP might be privately admitting that you should use Rust if you can (not much that's new here, the Carbon folks said the same thing) and everything else just silently assumes that you can't do that for some reason - be it legacy or perhaps concerns about Rust's supposedly challenging learning curve. (It goes without saying that we shouldn't expect a C/C++ committee paper to outright advocate for Rust.)

FpUser 4y ago

>"Rust ... is pretty much a drop-in replacement for C++" Performance and "low-levelness" wise it most likely is. From high level point of view it messes with how one must think when writing code and is missing some features / paradigms found in modern C++ (for better or worse, not gonna dwell on it here). In my opinion it is closer to "drop-in replacement" for C.

oytis 4y ago
I mean modulo interop with legacy code or need for proprietary compilers Rust can be used wherever C++ is used. Not quite true for C#, Go etc.

copirate 4y ago

> Not sure why he omitted Rust from the list, it is in the original document He didn't remove Rust from the quote though. The NSA document[1] contains two lists of languages considered safe and for some reasons Rust is only included in one: > Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®. > Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift® [1] https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...