upvote

points

by nayroclade11 hours ago |
comments
upvoteby Sharlin11 hours ago|
next
[-]
Around 70% of security vulnerabilities are about memory safety and only exist because software is written in C and C++. Because most vulnerabilities are in newly written code, Google has found that simply starting writing new code in Rust (rather than trying to rewrite existing codebases) quickly brings the number of found vulnerabilities down drastically.
reply
upvoteby miki1232114 hours ago|
parent|
next
[-]
I find this interesting.

Curl's Daniel Stenberg claimed during his NDC talk that vulnerabilities in this project are 8 years old on average.

I wonder where the disconnect comes from.

reply
upvoteby tptacek4 hours ago|
parent|
[-]
It comes from all his reporters being teenagers in developing countries with older models, and people using SOTA models who know how to qualify a potential vulnerability having much bigger fish to fry than curl. curl is a meaningful target, but it's in nobody's top tier.
reply
upvoteby bastawhiz8 hours ago|
parent|
prev|
next
[-]
You can't just write Rust in a part of the codebase that's all C/C++. Tools for checking the newly written C/C++ code for issues will still be valuable for a very long time.
reply
upvoteby zozbot2347 hours ago|
parent|
[-]
You actually can? A Rust-written function that exports a C ABI and calls C ABI functions interops just fine with C. Of course that's all unsafe (unless you're doing pure value-based programming and not calling any foreign code), so you don't get much of a safety gain at the single-function level.
reply
upvoteby noosphr9 hours ago|
parent|
prev|
[-]
And to a good approximation all real world Rust uses unsafe everywhere.

So we now have a new code base in an undefined language which still has memory bugs.

This is progress.

reply
upvoteby kibwen9 hours ago|
parent|
next
[-]
No, this is false. For Rust codebases that aren't doing high-peformance data structures, C interop, or bare-metal stuff, it's typical to write no unsafe code at all. I'm not sure who told you otherwise, but they have no idea what they're talking about.
reply
upvoteby crote8 hours ago|
parent|
next
[-]
It's the classic "misunderstanding" that UB or buggy unsafe code could in theory corrupt any part of your running application (which is technically true), and interpreting this to mean that any codebase with at least one instance of UB / buggy unsafe code (which is ~100% of codebases) is safety-wise equivalent to a codebase with zero safety check - as all the safety checks are obviously complete lies and therefore pointless time-wasters.

Which obviously isn't how it works in practice, just like how C doesn't delete all the files on your computer when your program contains any form of signed integer overflow, even though it technically could as that is totally allowed according to the language spec.

reply
upvoteby zozbot2347 hours ago|
parent|
[-]
If you're talking about Rust codebases, I'm pretty sure that writing sound unsafe code is at least feasible. It's not easy, and it should be avoided if at all possible, but saying that 100% of those codebases are unsound is pessimistic.

One feasible approach is to use "storytelling" as described here: https://www.ralfj.de/blog/2026/03/13/inline-asm.html That's talking about inline assembly, but in principle any other unsafe feature could be similarly modeled.

reply
upvoteby crote5 hours ago|
parent|
[-]
It's not impossible, it is just highly unlikely that you'll never write a single safety-related bug - especially in nontrivial applications and in mixed C-plus-Rust codebases. For every single bug-free codebase there will be thousands containing undiscovered subtle-but-usually-harmless bugs.

After all, if humans were able to routinely write bug-free code, why even worry about unsoundness and UB in C? Surely having developers write safe C code would be easier than trying to get a massive ecosystem to adopt a completely new and not exactly trivial programming language?

reply
upvoteby zozbot2345 hours ago|
parent|
[-]
Rust is not really "completely new" for a good C/C++ coder, it just cleans up the syntax a bit (for easier machine-parsing) and focuses on enforcing the guidelines you need to write safe code. This actually explains much of its success. The fact that this also makes it a nice enough high-level language for the Python/Ruby/JavaScript etc. crowd is a bit of a happy accident, not something that's inherent to it.
reply
upvoteby bluGill7 hours ago|
parent|
prev|
[-]
Our experiences are different.

Good developers only write unsafe rust when there is good reason to. There are a lot of bad developers that add unsafe anytime they don't understand a Rust error, and then don't take it out when that doesn't fix the problem (hopefully just a minority, but I've seen it).

reply
upvoteby panstromek9 hours ago|
parent|
prev|
[-]
The parent comments references real world data from Google: https://security.googleblog.com/2024/09/eliminating-memory-s...
reply
upvoteby 4 hours ago|
prev|
[-]
deleted
reply