3 ms·
As somebody who would like to move to capability-safe languages, I think that moving to memory-safe languages is a necessary first step. You don't have to move
by BuuQu9hu 10y ago
As somebody who would like to move to capability-safe languages, I think that moving to memory-safe languages is a necessary first step.
You don't have to move to Rust, but you do have to move away from C.
- abecedarius 10y agoI want to see that move too, but I don't agree it's a prerequisite: you can sandbox code in unsafe languages using something like Sandstorm.
- Manishearth 10y agoStill means you can leak application memory ; this is what happened with (cloud|heart)bleed. Sandstorm mitigates RCEs escaping the sandbox, but not the leaking of secrets.
- gpderetta 10y agoYou are not wrong in general, but people have pointed out that heatbleed technically was not caused by a memory safety issue.
- Manishearth 10y agoWell, it's debatable. It was memory safety in the sense that they were using a buffer to manually manage memory and then messing up there. Languages like Rust won't save you from that, yes, but it is still at a basic level the same kind of bug. The question is if someone writing the program in Rust or Go or w/e would have used such a custom-allocator approach. It's unlikely, but such an approach is unlikely in C too, so it's not very clear-cut :) (but my general point was about sandstorm not fixing all the problems, just a subset -- not about whether other languages fix all those problems)