undefined | Better HN

0 pointsmarcus0x622y ago0 comments

It’s been holding up pretty well for the specific memory safety guarantees offered by modern languages, and for a simple reason: if your language is unsafe and has a bunch of foot guns in it, all the users of that language have to be perfect all the time to avoid trouble. If your language provides a certain safety guarantee, the implementors of that guarantee have to be perfect, but at least you have a relatively constrained point to test, perhaps even something small enough to provide a formal correctness guarantee. You can’t do that writ-large with end-user code.

The flipside, of course, is that language or tool problems have a much, much, larger blsst radius.

Still, you can twist yourself into knots to try to claim otherwise, but the track records of these tools speak for themselves.

0 comments

3 comments · 1 top-level

cbsmith2y ago· 2 in thread

> It’s been holding up pretty well for the specific memory safety guarantees offered by modern languages

That seems unrelated to whether people need to be perfect to avoid security exposures. In fact, it would seem to be in contradiction.

> if your language is unsafe and has a bunch of foot guns in it, all the users of that language have to be perfect all the time to avoid trouble

That's an entirely different argument, and depends on the semantics of "unsafe" and "foot guns". I think it's more than fair to say that having more protections in place allows for mistakes to avoid becoming vulnerabilities more often, but that's a different argument.

marcus0x62OP2y ago

> That seems unrelated to whether people need to be perfect to avoid security exposures. In fact, it would seem to be in contradiction.

It seems to me to be directly related when modern languages make certain types of mistake impossible, imperfect though the creators of those languages are.

> That's an entirely different argument, and depends on the semantics of "unsafe" and "foot guns".

No. It is literally the same argument. People are imperfect, and will make mistakes (that are possible to make.) In the case of C++, we have decades of evidence that people will make memory-safety mistakes over and over and over again.

cbsmith2y ago

Some modern languages have protections from some types of mistakes. C++ has some protections for some types of mistakes as well. I agree that there is decades of evidence that people can create security vulnerabilities in C++. I could quibble that C++20 is not the same language that most of those vulnerabilities occurred with, and that if we called Rust "C++24" it'd be no more prone to security vulnerabilities, but that seems like a mostly silly argument.

However, I would point out that some very non-modern languages also offer protection from the same class of memory-safety mistakes, but over decades have proven to be fully capable of having serious security vulnerabilities.

It is also true that we have decades of evidence that C++ programmers aren't perfect, often make mistakes, and often make mistakes that don't lead to security vulnerabilities, both due to protections in the toolset, and because lack of perfection doesn't mean you've got a security vulnerability.

It'd be great to eliminate a whole class of vulnerabilities by always using tools that prevent them, but you have to consider the price that comes with it. In particular, switching everything over to a new set of tools involves rewriting all that code, and that creates the possibility that entirely different classes of security vulnerabilities (some that C++ might offer protections & mitigations for) could be introduced in to programs that have proven to be secure, sometimes for decades.

It's a far more nuanced problem. Rather than taking an absolutist position, I think it makes sense to do what we've always done (or at least should always do), which is on a case-by-case basis, weigh the risks and make the appropriate choices. I'm sure that will lead to C++ not being used in a lot of cases.

j / k navigate · click thread line to collapse