3 ms·

> 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 di

> 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.

cbsmith 3y 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.

cbsmith 3y 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.