[kprotty]

> zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust

buffer overflows [0] [1], use after frees [2] [3], and other memory bugs [4] [5] [6] can appear in safe rust from unsound unsafe internals.

[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2887...

[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000...

[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3116...

[3] https://github.com/rustsec/advisory-db/blob/main/crates/cros...

[4] https://github.com/rustsec/advisory-db/blob/main/crates/toki...

[5] https://github.com/rustsec/advisory-db/tree/main/crates/

[6] https://github.com/Qwaz/rust-cve

[nindalf]

Rust has a low bar for creating CVEs, because the standards for safety are higher.

From the link you’re sharing

> Fortunately, they are context-sensitive library APIs that are not usually used in a way that the bugs can be triggered. Many of them require very specific interaction to trigger (e.g., partially consume an iterator and zip() it with another iterator) that is not likely to appear in their daily usage.

Here’s a concrete example that shows the difference between how different languages approach CVEs. Rust is not the only language affected by this TOCTOU bug (https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html) but other languages finesse it by saying “all bets are off when you’re interacting with the filesystem”. Therefore no CVE for them, while Rust ends up looking insecure in the eyes of those who count CVEs.

What I’m saying is - don’t count CVEs without looking at the context and content of those CVEs. Don’t assume that some software is secure simply because they don’t file CVEs, because that’s an ostrich approach.

[kprotty]

> don’t count CVEs without looking at the context and content of those CVEs

The CVEs are counted as they're memory issues (not only logical issues) that can technically surface in safe Rust code and are also considered UB in other languages (those which finesse other conditions to be "unspecified" instead of "undefined") too.

CVEs have rating systems to better interpret their relevance. Whether these ratings incorporate how easy it is to trigger or how practical the damage could be is subjective. They primarily report potential exploits, not a standard for judgement. All this nuance though was lost with the parent commenter claiming "zero memory bugs in safe rust".

> Don’t assume that some software is secure simply because they don’t file CVEs

I agree. This extends across all languages. Another warning to add is that high profile security bugs can still occur without memory safety issues (with wormhole/dao exploits being practical examples).

[nindalf]

I think we’re on the same page here.

Neither of us agree with a blanket assertion that code written in Rust is flawless and free of bugs.

This can be easily disproved by looking at the bugs fixed in the Rust compiler and standard library, and looking at open soundness issues in the Rust issue tracker.

I think CVEs are useful in tracking the security of your code, but can’t be meaningfully compared between languages. Different languages and ecosystems have differing bars on what needs a CVE.

The important takeaway is that while Rust and Rust code in general aren’t perfect, they’re still substantially better than the alternatives. Better is hard concept to convey and get people to buy into. They see a couple of bugs and say “well, there’s bugs either way so what difference does it make”.

[kprotty]

Yea, I think we're mostly on the same page.

For higher level domains where unsafe isn't required and some runtime overhead is acceptable, I believe there's real cases to be made that Rust can be substantially better than the alternatives; Can prevent logical UAF with borrowing, bound checks may be mostly elided, enforced language level checks for nullability like Option<&T> and valid values in general like enums, explicit error handling, etc.

For lower level domains however, I'm not sure that argument is as easy. Anecdotally, I work almost exclusively on systems like databases, schedulers, allocators, and similar. There, memory efficiency is an explicit feature via tricks that either Rust's borrow checker really doesn't like or are very awkward to do with its unsafe APIs; Non-linear/concurrent object lifetimes, self-referential & intrusive data structures, and reinterpret casting being the big ones.

If rust code makes it harder to do those things, while also providing little (never none) benefit over the alternatives (for reference, both Zig & Rust have checked {integer ops, slice access, nullability}, sum types, metaprogramming, rich error combinators, etc.) then it's harder to make the claim Rust is substantially better.

[nindalf]

I can't speak about the experience of writing unsafe. I haven't written any, and hope never to do so.

That said, your concerns are pretty valid, widely echoed and are being taken seriously. Writing unsafe code is a chore and it needn't be. I'm hoping the newly created Operational Semantics team (https://www.rust-lang.org/governance/teams/lang#Operational%...) makes progress here.

[hn92726819]

I don't consider this a bug caused by safe code. The bug is in the unsafe code, sure, but not in the safe code. Maybe the safe code triggers the bug in unsafe code. Maybe the unsafe code triggers undefined behavior, then anything can happen.

My point wasn't that rust is bug-free, but that certain classes of bugs will not exist in the safe portion, which significantly reduces attack surface.

Additionally, my point was to compare languages without safety guarantees like C to safe rust. Your statement is true, but it doesn't do anything to counter what I'm saying, which is that entire classes of bugs (namely the most common critical c bugs) are not found in safe rust, which is still the case.

Worded another way, within the boundaries of safe rust, you will not find a cause of a memory corruption bug. Things that can be the cause memory bugs include: unsound unsafe rust, c, kernel-level manipulation, random bit flips, malicious hardware, etc etc. I consider none of those to be bugs in safe rust, and additionally, they can cause bugs in all other programming languages as well.