Re:Implications of Rewriting a Browser Component in Rust
by ec109685 on Thursday February 28, 2019 @02:02PM
(#19274057)
If you want to prevent this class a bugs, you don’t need to switch languages is the point. Run a linter that prevents that syntax.
Re:Implications of Rewriting a Browser Component in Rust
by hedora on Thursday February 28, 2019 @02:04PM
(#19274069)
Right, but all you have to do in C++ is switch the array implementation to bounds check by default. This is not rocket science, and is certainly easier than rewriting large code bases from scratch.
Similarly, I could complain that rust arrays are too slow, and produce an array implementation that uses unsafe under the covers.
Re:Implications of Rewriting a Browser Component in Rust
by steveklabnik on Thursday February 28, 2019 @02:16PM
(#19274184)
Dropbox did this in their Rust code: https://github.com/dropbox/rust-brotli-decompressor/blob/mas...
https://github.com/dropbox/rust-brotli-decompressor/blob/mas...
Toggle the feature, remove the bounds checks unconditionally.
You wouldn't get "similarly broken results." The results for doing this in C/C++ are far more serious, which was a point the article made.
If you do this in Rust/C#/Java/etc they will safely crash. If you do this in C/C++ it is undefined behavior, it may crash, but it also could allow remote code execution.
The Rust version of this bug is Security-Low (crash), the C++ version is Security-Critical (potential RCE).