Remix.run Logo
dns_snek 4 hours ago

Why are we comparing a number of exploitable vulnerabilities to the number of segfault reports? Where does the "5000x" figure come from?

ViewTrick1002 3 hours ago | parent [-]

The number is memory vulnerabilities. Not if they are exploitable. The numbers comes from this part of the article:

    This near-miss inevitably raises the question: "If Rust can have memory safety vulnerabilities, then what’s the point?"

    The point is that the density is drastically lower. So much lower that it represents a major shift in security posture. Based on our near-miss, we can make a conservative estimate. With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC).

    Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction. 
https://security.googleblog.com/2025/11/rust-in-android-move...
dns_snek 2 hours ago | parent [-]

Then someone's playing with definitions here because a bug that can't be exploited and doesn't have a demonstrable impact on safety or security isn't a vulnerability under any definition that I subscribe to - it's just a bug.

What we ultimately care about is how many preventable, serious defects sneak into production code - particularly those concerning data security, integrity, and physical safety. The only statistics we should all care about is how many serious CVEs end up in the final product, everything else is just personal preference.

Eliminating a segfault when `--help` is provided twice is nice, but it didn't fix a security vulnerability so using it to bolster the security argument is dishonest.