4 ms·

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 assumpti

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.

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.