4 ms·

This reminds me of a post I once read arguing that type-safe languages weren't actually helpful, because they (generally) still let you write programs that coul

This reminds me of a post I once read arguing that type-safe languages weren't actually helpful, because they (generally) still let you write programs that could violate type safety. I thought that argument was silly, and I think yours is too. Yes, I'm quite confident that Rust isn't a panacea, anymore than functional programming will be, or object oriented programming has been, or type safety is. The point is that each of those techniques helps you to avoid certain classes of bugs. And so far as I can tell, Rust genuinely does have features that make writing certain kinds of bugs much less likely. Yes, Rust doesn't help you prevent every kind of bug. (Shocker!) But I don't get the point of insisting that decreasing an attacker's surface space isn't worthwhile.

armitron 11y ago
Security is all or nothing. There are no in-between states. If there's something to get from all my posts, is that we need to learn to operate with the assumption of compromise in mind, plan for failures and learn to rebuild, rapidly. Rust simply solves the wrong problems. For a language that certainly has the mindset, look at Erlang. Unikernels and Erlang will do more for actual security than a million monkeys cranking out perfectly safe Rust code. "Decreasing an attacker's surface" is pragmatically, bullshit. No competent attacker (and that doesn't include just nation states these days) will be deterred by a decreased attack surface.
- smithkl42 11y ago
  Practically, I think it's wrong to say "Security is all or nothing", with no in-between states. Most attacks and/or security bugs are built on a combination of problems. Anytime you fix one of those problems, you make it less likely that someone will find a chain of problems that ultimately allows them through. If you take the example of the Heartbleed bug (a classic buffer overflow), it would still be possible to have written it in Rust, but it would have been more difficult, and hence less likely. That's a worthwhile trait for a language to have.
- dcohenp 11y ago
  I'm sorry, but this line of argument is not even wrong as it relates to the entire modern infosec field, which is founded on the fact that there is no such thing as "100% security"; that is why concepts such as "threat models" and "defense in depth" exist. Also, proving a program "correct" (for some definition of correctness that presumably includes "secure") is undecidable, ergo there cannot be such a thing as a "100% secure language". No, not even Erlang, nor Haskell, nor anything which is remotely close to Turing-complete. So all we can do is, in fact, decrease the attack surface.
  - codygman 11y ago
    > No, not even Erlang, nor Haskell, nor anything which is remotely close to Turing-complete. So all we can do is, in fact, decrease the attack surface. You often don't even need Turing completeness.

armitron 11y ago

Security is all or nothing. There are no in-between states. If there's something to get from all my posts, is that we need to learn to operate with the assumption of compromise in mind, plan for failures and learn to rebuild, rapidly. Rust simply solves the wrong problems. For a language that certainly has the mindset, look at Erlang. Unikernels and Erlang will do more for actual security than a million monkeys cranking out perfectly safe Rust code. "Decreasing an attacker's surface" is pragmatically, bullshit. No competent attacker (and that doesn't include just nation states these days) will be deterred by a decreased attack surface.

smithkl42 11y ago
Practically, I think it's wrong to say "Security is all or nothing", with no in-between states. Most attacks and/or security bugs are built on a combination of problems. Anytime you fix one of those problems, you make it less likely that someone will find a chain of problems that ultimately allows them through. If you take the example of the Heartbleed bug (a classic buffer overflow), it would still be possible to have written it in Rust, but it would have been more difficult, and hence less likely. That's a worthwhile trait for a language to have.
dcohenp 11y ago
I'm sorry, but this line of argument is not even wrong as it relates to the entire modern infosec field, which is founded on the fact that there is no such thing as "100% security"; that is why concepts such as "threat models" and "defense in depth" exist. Also, proving a program "correct" (for some definition of correctness that presumably includes "secure") is undecidable, ergo there cannot be such a thing as a "100% secure language". No, not even Erlang, nor Haskell, nor anything which is remotely close to Turing-complete. So all we can do is, in fact, decrease the attack surface.
- codygman 11y ago
  > No, not even Erlang, nor Haskell, nor anything which is remotely close to Turing-complete. So all we can do is, in fact, decrease the attack surface. You often don't even need Turing completeness.