you are viewing a single comment's thread
view the rest of the comments
[–] 29 points 3 days ago* (last edited 2 days ago) (10 children)

I mean yes, I do, given safe Rust inherently fixes seemingly every exploit listed in this article:

  • RCE from integer overflow (not possible by default in Rust, CVSS 9.0)
  • RCE from a race condition (not possible in safe Rust, CVSS 9.0)
  • An exploit of a buffer copy
  • An out-of-bounds write leading to local privilege escalation
  • Using an uninitialized resource
  • TCP query stack buffer overflow leading to local privilege escalation

I feel like it's the 1960s and I'm being told "we get it, you like seatbelts".


Edit: Sorry, re: the first one. I was misremembering based on a mix of a few things (see below). It does this in debug mode (which in itself is good to have), and it won't compile if it can detect an overflow statically, but it's not checking over/underflow at runtime by default. It can do this if you want it to, but that's an inherent speed penalty from C. I was thinking of Swift, which does automatically detect integer under/overflow at runtime unless you explicitly tell it not to on a per-operator basis.

In the spirit of not making you "trust me bro" since I was so wrong about the integer under/overflow one, here's Rust's overview of how safe Rust guarantees against data races.

  • source
  • parent
  • hideshow 10 child comments
  • [–] 7 points 3 days ago (1 child)

    RCE from integer overflow (not possible by default in Rust

    It is possible. Rust will check for overflow and panic in debug builds, but will silently wrap integers in release builds.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 2 days ago*

    Yeah, you're right. I was thinking of a combination of Rust's debug mode, the fact it won't compile if it detects a static under/overflow, and Swift's default producing a runtime error on integer under/overflow. Corrected; I apologize.

  • source
  • parent
  • [+] -17 points 3 days ago (6 children)

    Yeah because the way you said it is extremely dick-ish and sounds like someone trying to push their preferred language onto others.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 30 points 3 days ago* (5 children)

    > "sounds like someone trying to push their preferred language onto others."

    > didn't even name Rust in the first comment

    I literally only talked about Rust when someone else mentioned it, because I'm not specifically talking about Rust.

    Whereas yes, Rust is relevant to the Linux kernel for obvious reasons (matching C's speed and being easily interoperable with it), I said "a modern language" because I'm talking generally about the use of old, unsafe languages and major exploits surrounding problems that modern languages fix cropping up every 5 seconds.

    I'm not going to police my own tone about what are clearly negligent engineering practices. SWE should be treated with the same level of scrutiny as other engineering fields when its poor, outdated practices are constantly causing accelerating worldwide damage.

  • source
  • parent
  • hideshow 5 child comments
  • [+] -15 points 3 days ago (4 children)

    Everyone is sick of this low effort advocacy

  • source
  • parent
  • hideshow 4 child comments
  • [–] 10 points 3 days ago (1 child)

    Idk, I find it pretty informative.

  • source
  • parent
  • hideshow 1 child comment
  • [–] -4 points 3 days ago

    Cool, that's fine. I think it was clear I didn't mean literally everyone. At least for me the boosterism has been pretty relentless for many years, taking over from the Python dogmatism before that.

    The languages are cool and have many nice aspects, the volunteer advertising is tiresome though.

  • source
  • parent