It's not like NASA sent a rover, written almost fully in C, to Mars. It's not like billions of cars and even more billions of their ECUs are written in C. It's not like the firmware of the keyboard you're writing your comment on, or even the OS/browser you're using is written in C. C bad, Rust good.
This isn't about Rust, the same problems were well known (and long suffered & complaned about) before Rust came around and there are well known much older engineering techniques for parsing untrusted data. It's nice that the Rust phenomenon has brought with it some new spirit of vigor and momentum to break out of the apathy, though.
Re Rover code and ECUs - this is the difference between safety critical code and security critical code at the attack surface.
The first kind deals primarily with "don't keel over or go crazy when natural phenomena throws unexpected circumstances at you", the second deals with inputs crafted by intelligent adversaries who can see your code and test & iterate attacks to exploit any flaws they uncovered through analysis or experimentation against your implementation. (Of course if we nitpick, an intelligent attacker is a natural phenomenon.)
NASA rovers and car ECUs have minimal people looking to exploit them, so I'm not overly convinced they're exploit free either.
I'm not a Rust evangelist or even a user, but the current paradigm of "THIS TIME, we'll write safe, complex, performant C/C++ code properly" isn't the solution, nor is manually squashing bugs one by one.
The solution seems to be a combination of improving the tooling around existing C\C++, and starting new projects in safer languages when possible.
Comments
Yup. C bad, Rust good.
It's not like NASA sent a rover, written almost fully in C, to Mars. It's not like billions of cars and even more billions of their ECUs are written in C. It's not like the firmware of the keyboard you're writing your comment on, or even the OS/browser you're using is written in C. C bad, Rust good.
This isn't about Rust, the same problems were well known (and long suffered & complaned about) before Rust came around and there are well known much older engineering techniques for parsing untrusted data. It's nice that the Rust phenomenon has brought with it some new spirit of vigor and momentum to break out of the apathy, though.
Re Rover code and ECUs - this is the difference between safety critical code and security critical code at the attack surface.
The first kind deals primarily with "don't keel over or go crazy when natural phenomena throws unexpected circumstances at you", the second deals with inputs crafted by intelligent adversaries who can see your code and test & iterate attacks to exploit any flaws they uncovered through analysis or experimentation against your implementation. (Of course if we nitpick, an intelligent attacker is a natural phenomenon.)
Those have tons of exploitable bugs!!
NASA rovers and car ECUs have minimal people looking to exploit them, so I'm not overly convinced they're exploit free either.
I'm not a Rust evangelist or even a user, but the current paradigm of "THIS TIME, we'll write safe, complex, performant C/C++ code properly" isn't the solution, nor is manually squashing bugs one by one.
The solution seems to be a combination of improving the tooling around existing C\C++, and starting new projects in safer languages when possible.