5 ms·

The reality is that people are adding critical code to the kernel and surrounding infrastructure (OpenSSL) on a Friday night after a long weeks work and never b

The reality is that people are adding critical code to the kernel and surrounding infrastructure (OpenSSL) on a Friday night after a long weeks work and never bother to look at it again. We absolutely need something like Rust to cover our backs!

pclmulqdq 4y ago
The idea that Rust can solve this problem is ridiculous to me. The types of bugs that sleep-deprived contributors writing fire-and-forget code will make will just shift to something that the borrow checker doesn't help with.
- UltraViolence 4y ago
  It's not ridiculous, it's a proven fact! Rust obviously won't stop logical errors, but it will put an end to the almost unending cue of memory and thread related bugs. Mind you that Firefox, for example, has been around for 17 years. Every month I get security updates fixing multiple memory holes in the code each of which could potentially allow anyone to take over my machine. Seventeen years!! They must have fixed hundreds if not thousands of such bugs by now, and every month more are repaired by updates. We'd have none of those had it been written in Rust. Also mind the time saved by developers not having to hunt for such (hard to track down) bugs!
  - cesarb 4y ago
    > We'd have none of those had it been written in Rust. Except for memory issues in JIT-generated code from Javascript? Not all browser vulnerabilities are caused by memory safety issues in the code generated by the Javascript JIT, but several of them are (particularly "type confusion" vulnerabilities). Rust might help avoid vulnerabilities in the code generator, but not in the generated code.
- unrealhoang 4y ago
  So, no bug that the borrow checker can help with? Sounds like a big win to me, why is it ridiculous?
  - pclmulqdq 4y ago
    The parent comment implied that this meant that there would be fewer bugs. That is definitely not what happens. The factor that actually generates the bugs is the tired person writing code they will never read again or use. The borrow checker won't help with that. I write code with different types of bugs in C, Go, Rust, Javascript, and Verilog, for example. I rarely write code with no bugs, especially when I have no real connection to the code.
    - unrealhoang 4y ago
      GP comment implied there would be fewer exploitable bugs. That is definitely what happens. If you think there's the same amount of severe exploit from software written in Go/Java/Javascript and software written in C/C++, you are just factually wrong. 70% of exploitable bugs from large company products (M$, Apple, Google) ARE memory safety bugs.
      - pclmulqdq 4y ago
        I do not agree with you, and I think it's a pretty strong claim to make that Rust code has fewer exploitable bugs than other code without evidence. The fact that 70% of "exploitable bugs from large company products" are memory safety bugs does not imply that those products will be any harder to exploit when re-written in Rust, just that they won't have certain types of memory safety bugs - which happen to be 70% of the known exploitable bugs that have emerged. One big reason why we have so many CVEs for memory safety bugs is that they are very easy to find with analyzers and easy to programmatically test. We currently live in a world where a lot of deployed code has not had the benefit of those analyses, but the attackers do. Hence the huge number of CVEs. Rust closes that asymmetry, which is significant. It does not mean that we won't move on to a new class of exploitable bugs that show up due to a new class of analyzers. Also, exploitation means a lot of things to a lot of people. The fact that it's really easy to crash a Rust program could also be considered an exploit (as a number of CVEs do). Just using Rust does not save you from exploits. Using Rust well makes it easier to be safer.

pclmulqdq 4y ago

The idea that Rust can solve this problem is ridiculous to me. The types of bugs that sleep-deprived contributors writing fire-and-forget code will make will just shift to something that the borrow checker doesn't help with.

UltraViolence 4y ago
It's not ridiculous, it's a proven fact! Rust obviously won't stop logical errors, but it will put an end to the almost unending cue of memory and thread related bugs. Mind you that Firefox, for example, has been around for 17 years. Every month I get security updates fixing multiple memory holes in the code each of which could potentially allow anyone to take over my machine. Seventeen years!! They must have fixed hundreds if not thousands of such bugs by now, and every month more are repaired by updates. We'd have none of those had it been written in Rust. Also mind the time saved by developers not having to hunt for such (hard to track down) bugs!
- cesarb 4y ago
  > We'd have none of those had it been written in Rust. Except for memory issues in JIT-generated code from Javascript? Not all browser vulnerabilities are caused by memory safety issues in the code generated by the Javascript JIT, but several of them are (particularly "type confusion" vulnerabilities). Rust might help avoid vulnerabilities in the code generator, but not in the generated code.
unrealhoang 4y ago
So, no bug that the borrow checker can help with? Sounds like a big win to me, why is it ridiculous?
- pclmulqdq 4y ago
  The parent comment implied that this meant that there would be fewer bugs. That is definitely not what happens. The factor that actually generates the bugs is the tired person writing code they will never read again or use. The borrow checker won't help with that. I write code with different types of bugs in C, Go, Rust, Javascript, and Verilog, for example. I rarely write code with no bugs, especially when I have no real connection to the code.
  - unrealhoang 4y ago
    GP comment implied there would be fewer exploitable bugs. That is definitely what happens. If you think there's the same amount of severe exploit from software written in Go/Java/Javascript and software written in C/C++, you are just factually wrong. 70% of exploitable bugs from large company products (M$, Apple, Google) ARE memory safety bugs.
    - pclmulqdq 4y ago
      I do not agree with you, and I think it's a pretty strong claim to make that Rust code has fewer exploitable bugs than other code without evidence. The fact that 70% of "exploitable bugs from large company products" are memory safety bugs does not imply that those products will be any harder to exploit when re-written in Rust, just that they won't have certain types of memory safety bugs - which happen to be 70% of the known exploitable bugs that have emerged. One big reason why we have so many CVEs for memory safety bugs is that they are very easy to find with analyzers and easy to programmatically test. We currently live in a world where a lot of deployed code has not had the benefit of those analyses, but the attackers do. Hence the huge number of CVEs. Rust closes that asymmetry, which is significant. It does not mean that we won't move on to a new class of exploitable bugs that show up due to a new class of analyzers. Also, exploitation means a lot of things to a lot of people. The fact that it's really easy to crash a Rust program could also be considered an exploit (as a number of CVEs do). Just using Rust does not save you from exploits. Using Rust well makes it easier to be safer.