alpire

7 ms·

1. 1.▲
   by alpire 2y ago

   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 addit
2. 2.▲
   by alpire 2y ago

   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
3. 3.▲
   by alpire 2y ago

   > 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-
4. 4.▲
   by alpire 2y ago

   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&#x
5. 5.▲
   by alpire 2y ago

   > 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 iss
6. 6.▲
   by alpire 2y ago

   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 saf