alpire

That's exactly right. We've had extra hardening enabled in tests, and that does catch many issues. But tests can't exercise every potential out-of-bounds issue, which is why enabling it prod enabled us to find & fix additional issues.

The hardening mode we enabled is quite recent added to libc++. It was proposed in 2022: https://discourse.llvm.org/t/rfc-c-buffer-hardening/65734. It was designed to run in prod, so it's quite fast. Previous debug modes I've seen came with a much higher costs, and therefore weren't (usually) enabled in prod.

> its trivial to write memory safe C++

It is not unfortunately. That's why we see memory safety being responsible for 70% of severe vulns across many C and C++ projects.

Some of the reasons include: - C++ does little to prevent out-of-bounds vulns - Preventing use-after-free with smart pointers requires heavy use of shared pointers, which often incurs a performance cost that is unacceptable in the environment C++ is used.

For more information on our safe coding approach, as applied to the web domain, check out this paper (https://static.googleusercontent.com/media/research.google.c...) or this talk (https://www.youtube.com/watch?v=ccfEu-Jj0as).

> You have a bunch of sub-par programmers, who don't use the old, well documented, stable, memory-safe functions and techniques. They write code with memory safety bugs.

We should really stop putting the blame on developers. The issue is not that developers are sub-par, but that they are provided with tools making it virtually impossible to write secure software. Everyone writes memory safety bugs when using memory-unsafe languages.

And one helpful insight here is that the security posture of a software application is substantially an emergent property of the developer ecosystem that produced it, and that includes having secure-by-design APIs and languages. https://queue.acm.org/detail.cfm?id=3648601 goes into more details on this.

Android talked more about the memory-safe languages they're using in a previous blog post: https://security.googleblog.com/2022/12/memory-safe-language...

Google also published their perspective on memory safety in https://security.googleblog.com/2024/03/secure-by-design-goo..., which also goes over some of the memory-safe languages in use like Java, Go and Rust.