Note that the half Rust would prevent tends to be less impactful, still a CVE, but the exploit is less impactful to end users.
Note that the half Rust would prevent tends to be less impactful, still a CVE, but the exploit is less impactful to end users.
We did a big improvement, but why can’t we disable “unsafe”?
That would leave absolutely no margin for such errors.
Because there are things which literally can not be safe, and rust will not let you get away with pretending.
Can you post maybe a good article explaining this?
If you want to go further, you can disable unsafe in a crate by adding #[forbid(unsafe)].
And if you need more control than that, there's probably tooling out there that will help depending on what exactly you need.
https://github.com/rustsec/rustsec/tree/main/cargo-audit
Cool, so it's possible to exclude dependencies which include unsafe stuff! That's awesome.
See, this is the kind of stuff I was looking for.
From the perspective of a team writing new Rust code:
1) Don't allow unsafe (you can have an easy code search for this) 2) Forbid unsafe cargos
Finally: how do you catch unsafe in the standard library?
This can be accomplished with cargo vet (https://mozilla.github.io/cargo-vet/how-it-works.html?highli...)
I'm a c++ guy interested in Rust, my understanding is Unsafe lets me design custom high performance interfaces that do weird pointer tricks (which is needed to interface to the C and C++98 interfaces I work with), and it is on me to bounds check. Then the users of my interface don't use unsafe because I did all the nasty parts and their code is easy to write well.
If you mean "writing unsafe in your codebase yourself," this isn't borne out by the numbers.
If you mean "depending on unsafe somewhere in your dependencies" then 100% of Rust code needs unsafe, just like any other language. Interacting with hardware, many operating systems' APIs, these aren't created in a way to guarantee it, and you need to interact with them to do anything.