4 ms·

1. Don't use C++.

by musicale 5y ago

1. Don't use C++.

anonymousDan 5y ago
No idea why this is being downvoted.
- charcircuit 5y ago
  It's a useless dismissal of the article. It's equivalent to saying if you don't want to write any bugs, just don't write software. The advice is useless to someone who wants to make software even though it technically is true.
  - ModernMech 5y ago
    I dunno, the first bullet point of the article is: Understand that there are no safety nets provided by the compiler or runtime while coding in C++. I took the poster's comment to mean this bullet point is essentially saying "Don't use C++ if you really want to write secure software." If we've learned anything in the 35 or so years since C++ was introduced, it's that compilers and runtimes can do a great deal of good to help developers write secure software. I mean, another reading of this article is that it's a list of the sharpest edges to watch out for in the C++ language, not a list of secure coding practices. The advice presented here boils down to "avoid these common bear traps and foot guns that are unhelpfully provided for you as part of you C++ starterpack." I think many reasonable people could easily conclude the same as the OP after reading this piece.
gefhfffh 5y ago
Jep. Secure C++ is no C++ - given you don't fall back to C or ASM, and consider safer alternatives
api 5y ago
This is correct. What people often don't think about in the safe languages debate is that it's not about the skill of specific programmers. Yes, good programmers can write secure C or C++ code. That's not the problem. The problem is what happens as code ages. What happens when bugs are fixed, refactors are done, code is ported to other platforms and OSes, multiple people work on it, and pull requests are merged. Bugs creep in when modifications are made without the full context, hastily, and by people who did not write the original code or when it was written so long ago that they've forgotten the deep details of it. Safe languages will prevent, catch, or at least "nerf" the most dangerous sorts of bugs such as memory errors. Rust is very good at catching most of them at compile time. Unsafe languages won't and it's easy for bugs to creep in later and then result in catastrophic security failures long after they're released. Look at OpenSSL, a hoary old code base that continues to produce ugly security bugs.
- 0xcde4c3db 5y ago
  In my experience, language selection is typically based on the overall ecosystem, not on any quality of the language itself. It takes an uncommonly opinionated team to pick anything other than the language whose ecosystem seems like it will let them ship with the least amount of hassle.
- ridiculous_fish 5y ago
  Old codebases have a lot of baked-in institutional knowledge and bug fixes. A RiiR effort will introduce new bugs and reintroduce old ones, especially if done "without the full context, hastily, and by people who did not write the original code." Rewrites often fail. MSFT, Google, Apple, Facebook all have a gazillion lines of C++ and it's not going away any time soon. "Don't use C++" is not practical advice for them and many other companies.
  - pjmlp 5y ago
    Microsoft Security Response Center official guidelines are: 1 - Use a managed language like C#, Java, Go if automatic memory management is ok 2 - Use a systems language like Rust if automatic memory management is not an option 3- Use C++ alongside Core Guidelines tooling. Granted, not all Microsoft projects care about those guidelines.
- passivate 5y ago
  >Safe languages will prevent, catch, or at least "nerf" the most dangerous sorts of bugs such as memory errors As a former C++ developer, errors leading to crashes (be it due to memory or otherwise) were always more preferable to me than logic errors or race conditions (which can still happen in Rust) that go unnoticed for months/years. I guess 'danger' here is subjective, but thats my view.
  - api 5y ago
    How does catching crash bugs lead to more logic bugs? In practice I've never seen this. In any case we're talking about security here where many crash bugs can in fact be catastrophic security vulnerabilities. If it crashes there's a distinct possibility that the bug is exploitable.
olliej 5y ago
Not a useful comment, a better one /might/ be "don't write new software in c++." But that said, C++ is safer than C. This is a result of large and complex software developing features that require a large amount of manual and error prone code, whereas C++ can do the work for the developer, and will do it correctly everytime. Are there bad things in C++? of course. But you can avoid the known "bad" features - we can acknowledge things we originally thought would be good were in fact bad, and also recognize they need to remain due to old code - without throwing out all the good features. Hence you get the "modern C++" subset that all serious large c++ projects use, which is not some horrific wasteland of bad code. Most security bugs that have been in C++ have been as a result of errors inherited from C and, unlike C, can be engineered out. My suspicion is that the over-representation of C++ in vulnerability statistics is a product of the size of the major C++ codebases, the value of those targets, and the complexity of the products.

1. Don't use C++.

anonymousDan 5y ago

No idea why this is being downvoted.

charcircuit 5y ago
It's a useless dismissal of the article. It's equivalent to saying if you don't want to write any bugs, just don't write software. The advice is useless to someone who wants to make software even though it technically is true.
- ModernMech 5y ago
  I dunno, the first bullet point of the article is: Understand that there are no safety nets provided by the compiler or runtime while coding in C++. I took the poster's comment to mean this bullet point is essentially saying "Don't use C++ if you really want to write secure software." If we've learned anything in the 35 or so years since C++ was introduced, it's that compilers and runtimes can do a great deal of good to help developers write secure software. I mean, another reading of this article is that it's a list of the sharpest edges to watch out for in the C++ language, not a list of secure coding practices. The advice presented here boils down to "avoid these common bear traps and foot guns that are unhelpfully provided for you as part of you C++ starterpack." I think many reasonable people could easily conclude the same as the OP after reading this piece.

gefhfffh 5y ago

Jep. Secure C++ is no C++ - given you don't fall back to C or ASM, and consider safer alternatives

api 5y ago

This is correct. What people often don't think about in the safe languages debate is that it's not about the skill of specific programmers. Yes, good programmers can write secure C or C++ code. That's not the problem. The problem is what happens as code ages. What happens when bugs are fixed, refactors are done, code is ported to other platforms and OSes, multiple people work on it, and pull requests are merged. Bugs creep in when modifications are made without the full context, hastily, and by people who did not write the original code or when it was written so long ago that they've forgotten the deep details of it. Safe languages will prevent, catch, or at least "nerf" the most dangerous sorts of bugs such as memory errors. Rust is very good at catching most of them at compile time. Unsafe languages won't and it's easy for bugs to creep in later and then result in catastrophic security failures long after they're released. Look at OpenSSL, a hoary old code base that continues to produce ugly security bugs.

0xcde4c3db 5y ago
In my experience, language selection is typically based on the overall ecosystem, not on any quality of the language itself. It takes an uncommonly opinionated team to pick anything other than the language whose ecosystem seems like it will let them ship with the least amount of hassle.
ridiculous_fish 5y ago
Old codebases have a lot of baked-in institutional knowledge and bug fixes. A RiiR effort will introduce new bugs and reintroduce old ones, especially if done "without the full context, hastily, and by people who did not write the original code." Rewrites often fail. MSFT, Google, Apple, Facebook all have a gazillion lines of C++ and it's not going away any time soon. "Don't use C++" is not practical advice for them and many other companies.
- pjmlp 5y ago
  Microsoft Security Response Center official guidelines are: 1 - Use a managed language like C#, Java, Go if automatic memory management is ok 2 - Use a systems language like Rust if automatic memory management is not an option 3- Use C++ alongside Core Guidelines tooling. Granted, not all Microsoft projects care about those guidelines.
passivate 5y ago
>Safe languages will prevent, catch, or at least "nerf" the most dangerous sorts of bugs such as memory errors As a former C++ developer, errors leading to crashes (be it due to memory or otherwise) were always more preferable to me than logic errors or race conditions (which can still happen in Rust) that go unnoticed for months/years. I guess 'danger' here is subjective, but thats my view.
- api 5y ago
  How does catching crash bugs lead to more logic bugs? In practice I've never seen this. In any case we're talking about security here where many crash bugs can in fact be catastrophic security vulnerabilities. If it crashes there's a distinct possibility that the bug is exploitable.

olliej 5y ago

Not a useful comment, a better one /might/ be "don't write new software in c++." But that said, C++ is safer than C. This is a result of large and complex software developing features that require a large amount of manual and error prone code, whereas C++ can do the work for the developer, and will do it correctly everytime. Are there bad things in C++? of course. But you can avoid the known "bad" features - we can acknowledge things we originally thought would be good were in fact bad, and also recognize they need to remain due to old code - without throwing out all the good features. Hence you get the "modern C++" subset that all serious large c++ projects use, which is not some horrific wasteland of bad code. Most security bugs that have been in C++ have been as a result of errors inherited from C and, unlike C, can be engineered out. My suspicion is that the over-representation of C++ in vulnerability statistics is a product of the size of the major C++ codebases, the value of those targets, and the complexity of the products.