Comment by krater23
5 months ago
Sorry man, but I work since 2012 in professional security development in C/C++. Normally no one talks anymore about things like buffer overflows, use after free,... since years. Everyone uses tools to check for this, and in the end it's cheaper than using Rust. The attack vectors we talk about are logic errors and wrong usage of crypto. Things that can happen with Bash, C/C++, Rust and any other language and that you can't check automatically. Additionally to that, we talk about supply chain attacks, a thing that Rust with Cargo falls deep into.
But, based on a initiative of some Rust entusiast of one Team we tried it. Result after a half of a year was to not to use it. Learning a new language is difficult, Rust is for much people not fun to write and a newbie Rust programmer writes worse code than a senior C/C++ programmer, even if it's the same person.
Beside of people hyped by Rust, there is not much interest to replace C/C++. Currently I see no existential risk at all. On the other hand, Rust currently is overhyped, I would not bet that it's easy to find long time experienced Rust developers to maintain your code in a decade.
> Normally no one talks anymore about things like buffer overflows, use after free,... since years
Some of the biggest vulnerabilities of recent years (e.g. Heartbleed) were out-of-bounds access. The most common vulnerability sources are things that are impossible in Rust, but cannot be fully solved via C++ static checkers.
> > Normally no one talks anymore about things like buffer overflows, use after free,... since years
> Some of the biggest vulnerabilities of recent years (e.g. Heartbleed) were out-of-bounds access.
If I understand the Heartbleed bug correctly, it did not involved buffer overflows. It was a logical bug where they "trusted" the user-provided payload length (that can be much larger than the actual payload) and allocated the response buffer accordingly without zeroing it (malloc vs calloc). The "trash" in the uninitialized memory turned out to be quite valuable.
"xkcd: Heartbleed Explanation":
https://xkcd.com/1354/
"Add heartbeat extension bounds check.":
https://github.com/openssl/openssl/commit/731f431497f463f3a2...
Rust has unsafe, just like Java.
On the other hand, _all_ of C++ is unsafe.
> we talk about supply chain attacks, a thing that Rust with Cargo falls deep into.
How so? By listing all dependencies in an easy to digest way?
Making it hard to have a dependency does not stop devs from reusing code, it just leads to that code bing copy/pasted into code bases. I found several copies of gzip in every large C++ code base I ever looked at. Sometimes the functions get renamed, as somebody reported that linking failed when pulling in gzip as a library elsewhere. Most of the time with some patches applied. Never with documentation on where the code came from or how to update it.
"Header only libraries" are taking this approach and turn it into a best practice: Just copy this file somewhere into your source tree and you are done.
Even if you use proper dependencies, you typically depend on huge kitchen sink libraries that depend on the world themselves... often with the world being "vendored" (== copied into the library repository).
Those hidden dependencies are the worst kind of supply chain security issue you can have as itnis costly to even know about them being there.
> Currently I see no existential risk at all.
I see rust as a continuation of a trend that was started with Java... C++ has lost entire markets to memory safe languages in the last 25 years, be it the enterprise applications (Java), windows software (C#) or scientific computing (python). With these markets, C++ also has lost mind share and that shows in the new features being proposed.
When I visit a rust conference I am the old guy. When I go to a C++ conference I am of average age. The old guards are retiring with few new people filling up the ranks.