4 ms·

Given how much critical software is written in C, and the number of problems we run into; I don't see a reason to keep repeating that line outside of the Rust m

by codr7 1y ago

Given how much critical software is written in C, and the number of problems we run into; I don't see a reason to keep repeating that line outside of the Rust marketing department. Some people will always prefer C to Rust, might as well learn to live with that fact.

klysm 1y ago
I never mentioned rust. I’m just saying C and C++ have terrible memory safety.
- codr7 1y ago
  And what's the alternative then, from your perspective? What did you have in mind when you wrote the comment?
  - klysm 1y ago
    I had no alternative in mind. The topic at hand is security and bloat, and C/C++ might be leaner apps in practice but they are generally going to have memory safety bugs which is a security problem.
    - codr7 1y ago
      It is, but there are very good tools and plenty of experience with dealing with the problem. It's been blown way the fuck out of proportion lately by the Rust mob.
udev4096 1y ago
Remember how cloudflare (in 2017) leaked pretty much everyone's secret tokens in search engine cache due to a simple buffer overflow? Yeah, that wouldn't have happened with Rust
- codr7 1y ago
  Yeah I know, if only we could rewrite the entire world in Rust everything would be rainbows and unicorns. But it's not going to happen, deal with it.
- lelanthran 1y ago
  Remember that the most expensive exploit the world has ever seen was in a memory safe GC language? My argument is that you are missing the point: the point is that a larger attack surface enables more exploits regardless of language. When using a language that has tremendous friction in expanding the attack surface you tend to have a small attack surface as a result. Theres obviously a crossover point where you'd be safer with a memory safe language and a larger attack surface than with a memory unsafe language and a minuscule attack surface.
  - lmm 1y ago
    > Remember that the most expensive exploit the world has ever seen was in a memory safe GC language? No I don't, which exploit are you talking about? The most expensive exploit I can think of was caused by heartbleed which was in a memory unsafe language. The "most expensive software bug" (not an exploit) caused by turning off the safe overflow handler in the language being used can hardly be considered an indictment of language level safety either. So what exploit are you talking about?
    - throw1111221 1y ago
      Not the person you replied to, but they're probably talking about Log4j. It's a Java logging library that had a helpful feature where logging a special format string would pull code from a remote URL and execute it. So anywhere you can get a Java server to log something you can run arbitrary code. (Ex: by setting a malicious User-Agent.) Estimates say 93% of enterprise cloud environments where affected. I suppose Stuxnet could also count, where the initial infection depends on the human curiosity of plugging an unknown usb drive into an air gapped system.
    - lelanthran 1y ago

by codr7 1y ago

klysm 1y ago

I never mentioned rust. I’m just saying C and C++ have terrible memory safety.

codr7 1y ago
And what's the alternative then, from your perspective? What did you have in mind when you wrote the comment?
- klysm 1y ago
  I had no alternative in mind. The topic at hand is security and bloat, and C/C++ might be leaner apps in practice but they are generally going to have memory safety bugs which is a security problem.
  - codr7 1y ago
    It is, but there are very good tools and plenty of experience with dealing with the problem. It's been blown way the fuck out of proportion lately by the Rust mob.

udev4096 1y ago

Remember how cloudflare (in 2017) leaked pretty much everyone's secret tokens in search engine cache due to a simple buffer overflow? Yeah, that wouldn't have happened with Rust

codr7 1y ago
Yeah I know, if only we could rewrite the entire world in Rust everything would be rainbows and unicorns. But it's not going to happen, deal with it.
lelanthran 1y ago
Remember that the most expensive exploit the world has ever seen was in a memory safe GC language? My argument is that you are missing the point: the point is that a larger attack surface enables more exploits regardless of language. When using a language that has tremendous friction in expanding the attack surface you tend to have a small attack surface as a result. Theres obviously a crossover point where you'd be safer with a memory safe language and a larger attack surface than with a memory unsafe language and a minuscule attack surface.
- lmm 1y ago
  > Remember that the most expensive exploit the world has ever seen was in a memory safe GC language? No I don't, which exploit are you talking about? The most expensive exploit I can think of was caused by heartbleed which was in a memory unsafe language. The "most expensive software bug" (not an exploit) caused by turning off the safe overflow handler in the language being used can hardly be considered an indictment of language level safety either. So what exploit are you talking about?
  - throw1111221 1y ago
    Not the person you replied to, but they're probably talking about Log4j. It's a Java logging library that had a helpful feature where logging a special format string would pull code from a remote URL and execute it. So anywhere you can get a Java server to log something you can run arbitrary code. (Ex: by setting a malicious User-Agent.) Estimates say 93% of enterprise cloud environments where affected. I suppose Stuxnet could also count, where the initial infection depends on the human curiosity of plugging an unknown usb drive into an air gapped system.
  - lelanthran 1y ago