IMO the fact that the actix-web debacle was so well publicised speaks volumes in itself. The issues were actually discovered ahead of time by people reading the source code rather than people encountering bugs or vulnerabilities in the wild. That's a huge improvement over C software. Of course there are still bugs in Rust programs and libraries, but much fewer. And I think fewer to the point that eliminating them entirely might actually be feasible with enough effort.

For every vocal example there are tons that fly under the radar until they are on the news for the wrong reasons.

It is no accident that Ada and Java also have security guidelines similar to MISRA, because even with memory corruption bugs out of the picture, as log4j newly remided us, security only happens when it is part of the daily process, regardless of the language.

Isn't the whole reason you're mentioning actix-web because the community mostly balked at the amount of unsafe code in it? Surely that should be some evidence that the norms in Rustland are qualitatively different in many ways to what you'd find elsewhere?

Yes, pretty much like that. The author put "unsafe" blocks everywhere and the rest is history. Unsafe as a keyword is a kind of pledge: as a dev, you swear to the compiler that you've checked this part for correctness/safety. If you don't, you may get bitten, but the simple fact that "grep -R unsafe" will yield most (if not all) instances of potential memory fuckups is a huge win for auditability.

Rust's unsafe wouldn't have done anything to protect against an hypotetical log4r.

As for the memory fuckups you are right, pity that they are using a C GUI library.

Even if the binding has been deemed safe upon validation, if only remains a valid certification until the next Gtk version update, even minor ones might break the assumptions validated on the unsafe code block.

> Rust's unsafe wouldn't have done anything to protect against an hypotetical log4r.

You are correct. No programming language will protect you from writing flawed application logic.

> pity that they are using a C GUI library. (...) Gtk version update, even minor ones might break the assumptions

I don't know about that. GTK is more "battletested" than most frameworks, and has a lot of contributors to fix bugs. Also, and that's a very important point, GTK cares for accessibility! Using any other framework would have meant excluding a lot of people from the GUI.

As for assumptions, i certainly hope GTK devs don't push breaking changes to the ABI on minor updates. But i guess that's yet another assumption that can be broken.

Do you think Actix Web would be safer if it were written in C++?

Probably not, the point was that being in Rust wasn't either.

But the point is the exact opposite because any use of unsafe is clearly marked as such, and therefore a code audit will instantly find its use and question it. Hence the fallout surrounding it.

How do you find unsafe on a binary library?

Also that is besides the point, unsafe only deals with a very specific cause of errors that plague C code bases (and those of languages copy-paste compatible with it).

Rust's unsafe wouldn't have done anything to protect against an hypotetical log4r.

My point is that Actix Web was still safer than it would have been if it were written in C++ (which is Rust’s whole goal as far as safety), and moreover the norms of the Rust community are so strong that most of the unsafe usage has since been removed, since it was unnecessary. Unsafe deals with memory errors, which are consistently the largest class of security vulnerabilities in native codebases. This is uncontroversial at this point. Rust won’t protect you from log4j, but it never claimed to. Java still protects you from mishandling memory, despite all the stupid automatic classloading features we keep discovering in it.