I guess you make a living writing zero day exploits?

Keep believing that Rust magically prevents you from getting owned when you fuck up.

That is a fallacy. No one has claimed that Rust magically prevents you from getting owned. Quite to the contrary: there is no magic in preventing most, if not all memory handling errors. Which are the most common reason for security problems. Removing one category of errors entirely would free a lot of resources to deal with the remaining ones.

Even the "removing one category of errors" is not true when you use unsafe blocks in Rust, which is done generously in system programming.

Is that so? How large parts of the Rust kernel drivers in existence are inside unsafe blocks?

Yes, unsafe, as the name says, allows unsafe parts. But it is trivial to audit code for the usage of unsafe. Which means, everything else isn't. And it is there where the most common mistakes are made.

Is it trivial to audit? Here is a critical overflow in a matrix transpose: https://vulert.com/vuln-db/crates-io-transpose-125781

This is exactly the mistakes we also have in C and Rust people would do a little dance and take such bugs as argument why C is really dangerous and needs to be avoided. But rather obviously, mistakes can also happen in Rust and Rust does not "eliminate a class of errors" except when completely avoiding unsafe blocks. Maybe Rust is still more memory safe than C, I actually also believe this, but it is nowhere as safe as people like to claim and whether this is worth all the complexity is entirely unclear.

It is trivial to audit the usage of "unsafe". Grep does this. Of course auditing the unsafe functions is another thing. But you can have large codebases without unsafe and consequently a lot of less work with auditing your code. I don't have personal experience with Rust, but quite a bit with Go. It is almost ridiculous, how much more safe Go is in comparison with C. So yes, it is worth every bit.

The example shows that Rust can not even prevent an error as something simple as in a matrix transpose. Sure, you could write safe code, but how does this help if people don't do it? It is the exact same problem as in C and I have seen C code that is very reasonable.

Do you have a link to the code with the error? Following your link I didn't see it.

This is a better link which then has a link to the Github issues: https://rustsec.org/advisories/RUSTSEC-2023-0080

Ok, thanks, finally found the source of transpose. That uses unsafe. Which of course means, all guarantees of safety are off. I am not sure why the usage of unsafe is necessary here, but one way or the other, safety now is in the hand of the programmer.

My point rather was: wherever you don't use unsafe, you are protected by the compiler from certain errors. Which I consider extremely important, that is why I am a strong proponent of memory-safe languages.

Now, if there is a question whether Rust requires you to use unsafe to often, that would be a valid technical critique of Rust, but that didn't seem to drive the Linux discussion.

I think this is exactly the life lie of Rust. It claims to be memory safe and equally suited for system programming. But you get memory safety only when completely avoiding unsafe and it competes with C only when using unsafe. And it is certainly not true that you get memory safety in the part not using unsafe or that you only need to review the unsafe part. The memory safety of the safe part depends on the programmer maintaining invariances in the unsafe part that the Rust compilers needs to ensure the memory safety. At the same time the safety prerequisites of the unsafe parts can be violated by logic errors in the safe part (as in the transpose examples). It still helps to isolate the unsafe part, but in practice I am not convinced that the typical Rust code I see for system programming is fundamentally more secure than equally well designed C code which was also written with an eye towards memory safety and with use of modern tools to find problems.

> Go codebases? Switching to Rust so you can what exactly?

The way I heard it, the Rust's type system, async implementation(s), they way lifetimes just keep propagating once you start, and its macro languages are way more engaging, thus Rust must be superior.

but those improvements, and the complexity that they bring, are not enough to make the switch from a Go codebase to a Rust codebase unless performance is REALLY an issue.