5 ms·

Ted's post was a reaction to my overconfident assertion that even with a custom allocator, Rust would prohibit code from compiling that could lead to Heartbleed

Ted's post was a reaction to my overconfident assertion that even with a custom allocator, Rust would prohibit code from compiling that could lead to Heartbleed-like conditions. Furthermore, he was pointing out that random dorks like me talking great about Rust don't seem to actually know what was going on. I was under the impression that Heartbleed was purely out-of-bounds access, and it's not quite just that. (Still, I find it highly unlikely any memory safe language would end up with a real world program reusing the same buffers for SSL keys and user buffers, but it's possible.) Had I been a bit more careful in my claim then there'd have been no question. Ted was technically accurate (the best kind), but a lot of the resulting discussion was of the form "bad coders can always write security holes, therefore a language isn't the fix, so C's OK". Even when major products, like everything MS ships, have critical CVEs almost exclusively due to memory safety, not arbitrary bad logic. Further tptacek likes to point out that memory safety is just one class of sec bugs, and that there's frillions of other bugs in other classes. My suspicion is that this is more of a bias towards app-level stuff (ie command injection in a billion web apps), not systems. I suppose if you get pwnd it doesn't matter how, but a world free of all those MS memsafety RCEs seems like a qualitatively different one. But hey, I'm just some arbitrary weakling, and I find it hard to challenge people that are both smarter and drastically more experienced than I.

krenoten 12y ago
Writing widely-deployed infrastructure (web browsers, networking stacks, device drivers, openssl libraries) in C will be less and less justifiable over time. Rust is far from optimized right now. Rust is probably not going to be a language that you will script in. But it is a language that will possibly give Mozilla the world's most secure web browser by a significant margin if they succeed in writing the most bug prone components in Rust. It takes more thought to write Rust programs. If you want to write safer widely-deployed infrastructure, you should learn about it. It may not be your best option right now, but its ideals are those that we absolutely need to strive for. Acting macho about C and the ability to write it safely does not lead to fewer RCE's in the world. It leads to more, because newcomers may see such people who can do so as examples to be emulated, far before they are capable. Note that there are no familiar critics who say that Rust will not prevent some bugs. Note that there are no familiar proponents who claim that Rust will prevent all bugs. It is an implementation that strives to make progress in an area that we can all agree with - the safety of our programs with minimal performance degradation.
- Dewie 12y ago
  > Rust is probably not going to be a language that you will script in. No; you have D for that. EDIT: Seriously, for the grumpy down voter: I've seen quite a few programmers write that they use D even for things that are normally considered as scripting tasks.
  - edmccard 12y ago
    As to scripting in D: I don't write a lot of D code anymore, but thanks to snappy compile speeds and the 'rdmd' compiler driver (which automatically tracks dependencies), it really does have a sweet spot for writing little programs where you'd like the benefits of 'scripting languages' (no makefile hassle, short edit-run cycles) but need just a bit more runtime performance.
  - deleted 12y ago
    [deleted]
  - deleted 12y ago
    [deleted]
- greggman 12y ago
  > But it is a language that will possibly give Mozilla the world's most secure web browser by a significant margin if they succeed in writing the most bug prone components in Rust. A memory safe language alone isn't enough. Look at Java. Isn't that supposed to be a memory safe language? And yet it's constantly got security issues.
  - pcwalton 12y ago
    > A memory safe language alone isn't enough. Look at Java. Isn't that supposed to be a memory safe language? And yet it's constantly got security issues. Sure. Nobody is claiming (or should claim) that memory safety is a solution to all security problems. That's independent of the claim that memory safety is an effective defense against common vulnerabilities in C and C++ programs.
  - MichaelGG 12y ago
tracker1 12y ago
I think it depends... at a certain level, you need software to be as fast as possible for the systems above... I think more user-space applications should be written in safer languages (C#/.Net, Java, Go, Rust, Node.js, Python, ...) and low-level drivers, kernels, rendering engines and the like should be in the lowest-level possible. Unless we want everything to run as poorly (relatively speaking) as a web-application in a browser on a less-than top of the line computer... User-level applications are written on top of lower-level systems... the lower they are, the more important raw speed, and limited use of memory is.

krenoten 12y ago

Writing widely-deployed infrastructure (web browsers, networking stacks, device drivers, openssl libraries) in C will be less and less justifiable over time. Rust is far from optimized right now. Rust is probably not going to be a language that you will script in. But it is a language that will possibly give Mozilla the world's most secure web browser by a significant margin if they succeed in writing the most bug prone components in Rust. It takes more thought to write Rust programs. If you want to write safer widely-deployed infrastructure, you should learn about it. It may not be your best option right now, but its ideals are those that we absolutely need to strive for. Acting macho about C and the ability to write it safely does not lead to fewer RCE's in the world. It leads to more, because newcomers may see such people who can do so as examples to be emulated, far before they are capable. Note that there are no familiar critics who say that Rust will not prevent some bugs. Note that there are no familiar proponents who claim that Rust will prevent all bugs. It is an implementation that strives to make progress in an area that we can all agree with - the safety of our programs with minimal performance degradation.

Dewie 12y ago
> Rust is probably not going to be a language that you will script in. No; you have D for that. EDIT: Seriously, for the grumpy down voter: I've seen quite a few programmers write that they use D even for things that are normally considered as scripting tasks.
- edmccard 12y ago
  As to scripting in D: I don't write a lot of D code anymore, but thanks to snappy compile speeds and the 'rdmd' compiler driver (which automatically tracks dependencies), it really does have a sweet spot for writing little programs where you'd like the benefits of 'scripting languages' (no makefile hassle, short edit-run cycles) but need just a bit more runtime performance.
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
greggman 12y ago
> But it is a language that will possibly give Mozilla the world's most secure web browser by a significant margin if they succeed in writing the most bug prone components in Rust. A memory safe language alone isn't enough. Look at Java. Isn't that supposed to be a memory safe language? And yet it's constantly got security issues.
- pcwalton 12y ago
  > A memory safe language alone isn't enough. Look at Java. Isn't that supposed to be a memory safe language? And yet it's constantly got security issues. Sure. Nobody is claiming (or should claim) that memory safety is a solution to all security problems. That's independent of the claim that memory safety is an effective defense against common vulnerabilities in C and C++ programs.
- MichaelGG 12y ago

tracker1 12y ago

I think it depends... at a certain level, you need software to be as fast as possible for the systems above... I think more user-space applications should be written in safer languages (C#/.Net, Java, Go, Rust, Node.js, Python, ...) and low-level drivers, kernels, rendering engines and the like should be in the lowest-level possible. Unless we want everything to run as poorly (relatively speaking) as a web-application in a browser on a less-than top of the line computer... User-level applications are written on top of lower-level systems... the lower they are, the more important raw speed, and limited use of memory is.