27 ms·
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 programme
by 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 agoIn 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 agoOld 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 agoMicrosoft 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 agoHow 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.
- passivate 5y agoThat is not quite what I said. I said I would take a crashing bug over a logic bug. Logic bugs are hard to find because you can't easily test for them. IME, Security vulnerabilities are primarily about functions assuming the input is safe (logic bugs), or file format parsing bugs (logic bugs) or the function being buggy to the point where the caller can poison the stack and/or control EIP. (logic bugs) For each of these types there are some mitigations available at both the OS and hardware level, but I was making a general point about logic vs crashing bugs. > If it crashes there's a distinct possibility that the bug is exploitable. What I mean by crashing is that the program stops executing. Are you saying that crashing bugs make it easier to plant resident code? I'm nota security expert, so I don't quite know what you're referring to.
- pjmlp 5y agoWhen C and C++ segfault we can be considered lucky that it happened, instead of corrupting data, that might even be stored somewhere else and go months unnoticed.