3 ms·

I think it's extremely silly that every time buffer length vulnerabilities get discovered, people start immediately jumping how rewriting everything in rust wou

by ATsch 7y ago

I think it's extremely silly that every time buffer length vulnerabilities get discovered, people start immediately jumping how rewriting everything in rust would have stopped it. Yes, that's not wrong, but a sane (ptr, len) "slice"/"buffer" type would have prevented this in any language, not just rust. These things happen not because C and C++ lack sophisticated ownership semantics, but because without such a type, passing a pointer and hoping the buffer is always big enough is just easier than doing the right thing. If this was something funky like a cross-thread race-condition dangling-pointer double-free, you'd have a great point. Only Rust's unique safety model can prevent that. But with things like this, as much as I love Rust and it's community, I sometimes feel like many rust fans are much more interested in being smug than making real-world progress towards safer software today.

tene 7y ago
The point is that the sane, correct choice is also the easy, default choice in Rust. We've been able to implement (ptr,len) buffer types in C for as long as we've had C, but uint8_t* is both baked into many APIs, and the path of least resistance. We've spent decades pushing the limits of security improvements we can get through asking people to please try harder and do better with C, but we still see a high rate of high-impact errors like this. Rust's safety model isn't the only valuable thing about Rust. Another big valuable part of Rust is that instead of giving the programmer a box of unsafe tools and a post-it reminding them to be careful, Rust provides sane, safe default tools that have been built based on what we've learned from the past several decades. The argument isn't "Only Rust can save you", but that Rust is a good choice that both meets the same performance requirements, and avoids these problems by default. If you've got a better solution to persuade C and C++ developers to consistently and reliably always wrap their use of pointers from other APIs into (ptr,len) buffer types, I'd love to hear it! With comments like this, I sometimes feel like many developers are much more interested in smugly dismissing a group that's made significant real-world progress in making it easy to do the right thing than they are in actually helping real developers to reliably make safer software today.

by ATsch 7y ago

tene 7y ago

The point is that the sane, correct choice is also the easy, default choice in Rust. We've been able to implement (ptr,len) buffer types in C for as long as we've had C, but uint8_t* is both baked into many APIs, and the path of least resistance. We've spent decades pushing the limits of security improvements we can get through asking people to please try harder and do better with C, but we still see a high rate of high-impact errors like this. Rust's safety model isn't the only valuable thing about Rust. Another big valuable part of Rust is that instead of giving the programmer a box of unsafe tools and a post-it reminding them to be careful, Rust provides sane, safe default tools that have been built based on what we've learned from the past several decades. The argument isn't "Only Rust can save you", but that Rust is a good choice that both meets the same performance requirements, and avoids these problems by default. If you've got a better solution to persuade C and C++ developers to consistently and reliably always wrap their use of pointers from other APIs into (ptr,len) buffer types, I'd love to hear it! With comments like this, I sometimes feel like many developers are much more interested in smugly dismissing a group that's made significant real-world progress in making it easy to do the right thing than they are in actually helping real developers to reliably make safer software today.