3 ms·

Luckily, I don't have to respond by your goalposts. You are hammering on a single class of security vulnerability out of hundreds of potential vulnerabilities.

Luckily, I don't have to respond by your goalposts. You are hammering on a single class of security vulnerability out of hundreds of potential vulnerabilities. How does Rust prevent a confused deputy vulnerability? How about SQL Injection? Okay... well, what about all of the potential side channel attacks? People in higher level languages tend to believe that the relative safety of their position means that they have to be less vigilant about vulnerabilities. That is often what I have found. The number of vulnerabilities overall were similar, but the type of vulnerabilities were different. Because there was a completely mistaken belief that these platforms were "more secure", security practices were often sloppy. Most of these vulnerabilities were at the application level. So, looking for Microsoft CVEs isn't going to help you. The C++ code bases tended to have more senior level people working on them, who were more careful about both defects and vulnerabilities. Code bases in higher level languages, in general, had more junior level people working on them. Largely, the number of vulnerabilities were similar. Again, I'm speaking of my own experience. But, I think that many researchers in the field would give you a similar story. I'm always wary of people promising silver bullets over hard work.

MichaelGG 12y ago
So by your own logic, if experienced C++ developers wrote in, say, Rust, they would not make mistakes like SQL injection, and they wouldn't be making all the memory-safety mistakes, either. Edit: If your overall point is that systems are laughably insecure, and most app devs just leave gigantic holes open, sure, great. But let's not compound that by making their OSes and low-level network stuff run arbitrary code for anyone on the Internet.
- nanolith 12y ago
  It's not nearly that simple. Look, I get it: you're a fan of Rust. That's great. Use whatever language floats your boat. But, it takes more than language features to solve security issues. Memory vulnerabilities are only a small piece of the wide range of potential defects that exist in software. These are also defects that largely go away with training and experience. I can teach most C / C++ developers how to manage memory and pointers in a way that avoids all of the pitfalls that Rust is designed to prevent. It is absolutely possible to write reasonably secure software in most general purpose programming languages. This is true for C, C++, and even Rust. Don't believe me? Spend some time studying the formal proof behind the se implementation of L4, written in C. All of this being said, I am a big fan of high-level languages. For my personal work, I write 80% of my software in Literate Haskell and around 20% in a lower level language like C++. But, I also understand the limitations that comes with abstraction, and they are big. System level code operates under a lot of constraints, and the abstraction that come with "safe" languages can come at the cost of this code working at all. A good software engineer uses whichever tool he / she needs to build good software. If the process is followed, then there is no reason why we can't have an ecosystem that uses whichever languages are best for the problem. For most system level stuff, C/C++ are perfectly fine. If you want to use Rust, great. But, don't delude yourself into believing that your language choice trumps good engineering practice. It never will. Don't believe me? Write some software that can work around the Halting Problem in Rust, and get back to me. Because, that's the sort of intelligence you would need in a compiler or a tool to replace good practice.
  - MichaelGG 12y ago
    If you can teach people how to write safe C code, you should setup a site and rake it in. Meanwhile, Mozilla, Microsoft, Google, and others have tried to build safe applications and simply fail due to memory safety issues. When such high profile teams cannot deliver, then at some point you gotta say "hmm, maybe the language is at fault". I understand you like C/C++ and want to point out that if people delivery on a superhuman effort, then we can have nice things. Meanwhile, in reality, so far, this just doesn't happen. Lemme know when we can go a year without a memory safety issue getting tons of systems owned.
    - nanolith 12y ago
      When Rust has been around long enough, and people have started adopting it, then we'll see vulnerability reports in systems developed in Rust too. As I said, there are no silver bullets in security.

MichaelGG 12y ago

So by your own logic, if experienced C++ developers wrote in, say, Rust, they would not make mistakes like SQL injection, and they wouldn't be making all the memory-safety mistakes, either. Edit: If your overall point is that systems are laughably insecure, and most app devs just leave gigantic holes open, sure, great. But let's not compound that by making their OSes and low-level network stuff run arbitrary code for anyone on the Internet.

nanolith 12y ago
It's not nearly that simple. Look, I get it: you're a fan of Rust. That's great. Use whatever language floats your boat. But, it takes more than language features to solve security issues. Memory vulnerabilities are only a small piece of the wide range of potential defects that exist in software. These are also defects that largely go away with training and experience. I can teach most C / C++ developers how to manage memory and pointers in a way that avoids all of the pitfalls that Rust is designed to prevent. It is absolutely possible to write reasonably secure software in most general purpose programming languages. This is true for C, C++, and even Rust. Don't believe me? Spend some time studying the formal proof behind the se implementation of L4, written in C. All of this being said, I am a big fan of high-level languages. For my personal work, I write 80% of my software in Literate Haskell and around 20% in a lower level language like C++. But, I also understand the limitations that comes with abstraction, and they are big. System level code operates under a lot of constraints, and the abstraction that come with "safe" languages can come at the cost of this code working at all. A good software engineer uses whichever tool he / she needs to build good software. If the process is followed, then there is no reason why we can't have an ecosystem that uses whichever languages are best for the problem. For most system level stuff, C/C++ are perfectly fine. If you want to use Rust, great. But, don't delude yourself into believing that your language choice trumps good engineering practice. It never will. Don't believe me? Write some software that can work around the Halting Problem in Rust, and get back to me. Because, that's the sort of intelligence you would need in a compiler or a tool to replace good practice.
- MichaelGG 12y ago
  If you can teach people how to write safe C code, you should setup a site and rake it in. Meanwhile, Mozilla, Microsoft, Google, and others have tried to build safe applications and simply fail due to memory safety issues. When such high profile teams cannot deliver, then at some point you gotta say "hmm, maybe the language is at fault". I understand you like C/C++ and want to point out that if people delivery on a superhuman effort, then we can have nice things. Meanwhile, in reality, so far, this just doesn't happen. Lemme know when we can go a year without a memory safety issue getting tons of systems owned.
  - nanolith 12y ago
    When Rust has been around long enough, and people have started adopting it, then we'll see vulnerability reports in systems developed in Rust too. As I said, there are no silver bullets in security.