Firstly, the existence of unsafe does not inherently mean the code isn’t memory safe.
Secondly, memory safety does not mean no security vulnerabilities. What it does mean is that 80% of the most commonly found vulnerabilities (as gathered through statistical analysis of field failures) are gone. It means that the price for finding a vulnerability is higher.
And also sudo-rs precisely removes a lot of complexity that’s the source of vulnerabilities in normal sudo. There may be better approaches but it’s specifically not targeting 100% compat because sudo is horribly designed right now.
TLDR: this is a lazy knee jerk critique. Please do better in the future.
Reading comprehension and critical thinking again missing from your post.
The article would only “invalidate” what I wrote if the sudo-rs vulnerability was a result of memory safety. That isn’t what these vulnerabilities are.
By the way, the data on this is so clear and readily available about the real world reduction in memory safety issues Rust has in the real world I really don’t understand how you’re doubling down on your flawed position: https://security.googleblog.com/2025/11/rust-in-android-move....
This is literally empirical validation of the theoretical expected result. And Microsoft has also presented they’re seeing similar results. This is literally scientific evidence for the blinking neon sign that Rust achieves a significantly meaningful higher bar of memory safety than C/C++ regardless of any concerns you’ve raised (valid or otherwise). Rust isn’t evaluated in a vacuum against a hypothetically perfect alternative.
Unsafe rust behind harder to work with also doesn’t mean that unsafe in sudo-rs instantly runs into such issues. You can see the vast majority of the unsafe here is invoking syscalls. That isn’t what people are typically referring to as “unsafe is hard”. Basically you seem to not actually understand the issues at play and are cherry picking sound bites you think support the predetermined position you’re really set on taking. Thats what I mean by being lazy - you claim the existence of unsafe in sudo-rs makes it memory unsafe when that’s not at all necessarily the case - it just means there’s a risk there. Same with the Vec example - it’s highlighting how there can be issues but it doesn’t mean the vast majority of unsafe runs into it.
Is rust as memory safe as Java? No, it’s not. Is it substantially closer to Java safety than C/C++? Yes and it looks like it’s about at least an order of magnitude better than C/C++ while offering the same performance profile (and actually often better because it’s aliasing rules can be more aggressive and the standard library is more modern). An order of magnitude fewer vulnerabilities for the same performance is an insane jump in the Pareto frontier.
> Is this website promoting Rust, memory unsafety and insecurity?
What a joke of a question. The website prioritizes programs with 98% safe code over programs with 0% safe code. Does that mean it's "promoting memory unsafety" because it's not demanding 100%? No.
> This code is 100% Safe Rust but it is also completely unsound. Changing the capacity violates the invariants of Vec (that cap reflects the allocated space in the Vec). This is not something the rest of Vec can guard against. It has to trust the capacity field because there's no way to verify it.
> Because it relies on invariants of a struct field, this unsafe code does more than pollute a whole function: it pollutes a whole module. Generally, the only bullet-proof way to limit the scope of unsafe code is at the module boundary with privacy.
If 2% code means that, wildly spitballing, 50% code has to be manually reviewed, it's not quite as impressive.
And it might be worse regarding memory safety than the "status quo" if one accepts the assumption that unsafe Rust is harder than C and C++, as many Rust developers do.
> It may be even less safe because of the strong aliasing rules. That is, it may be harder to write correct unsafe {} Rust than correct C. Only use unsafe {} when absolutely needed.
If you're letting safe code in the same module as unsafe code mess with invariants, then the whole module needs to be verified by hand, and should be kept as minimal as feasible. Anything outside the module doesn't need to be verified by hand. "Modules with unsafe" should be a lot lot less than 50%. Your spitball is not a fit to real code.
When I wrote "98% safe code" I meant the code that can be automatically verified by the compiler. I wish the terminology was better.
> If you're letting safe code in the same module as unsafe code mess with invariants, then the whole module needs to be verified by hand, and should be kept as minimal as feasible. Anything outside the module doesn't need to be verified by hand.
More or less correct, but in principle, it also requires modules to have proper encapsulation and interfaces. Otherwise, an interface could be made that enables safe API functions to cause memory unsafety if called incorrectly.
> "Modules with unsafe" should be a lot lot less than 50%. Your spitball is not a fit to real code.
I mean, you have the search results right there. You could always take the time to look for yourself instead of "wildly spitballing", especially since the codebase is not that large.
Might want to take a closer look at your search results anyways, since those results include the FAQ, the sudoers man page, and instances of #![forbid(unsafe_code)] and #![deny(unsafe_code)]. Not exactly a promising start...
But since you asked so nicely, by tokei's count and my transcribing file paths, the modules including the `unsafe` keyword account for ~39% (8207/21106) of the total lines of code in the repo. I don't think you'll need to actually look at anywhere near that amount of code, though; from a brief glance through the search results I suspect most of the `unsafe` usages are for FFI calls, and relatively self-documenting/self-contained ones at that. If there were modules with module-wide invariants, I do not appear to have stumbled upon them.
> When I wrote "98% safe code" I meant the code that can be automatically verified by the compiler. I wish the terminology was better.
That depends on what is meant by "automatically verified by the compiler". The compiler cannot generally verify outside-unsafe code that modifies invariants that inside-unsafe code might rely on to have memory safety, for instance.
I mean the portion of the code that has no write access to those fragile invariants. At minimum, this includes all modules that don't have unsafe blocks.
