News for hackers. Stuff that matters.
Re:Firefox does not have a well-designed privsep model by kev009 on Monday June 11, 2018 @04:43PM (#17288399)
As the oxidize projects continue to land this email will become more and more obsolete. There's simply no way for C++ to compete with Rust, and while there will be continued utility pledge() is pretty quaint versus memory safety.
Re:Firefox does not have a well-designed privsep model by greenhouse_gas on Monday June 11, 2018 @05:15PM (#17288663)
>As the oxidize projects continue to land this email will become more and more obsolete. There's simply no way for C++ to compete with Rust,

Not everything is fixable with rust. JS, for one, is JIT compiled, so Rust wouldn't help much there (it's one of the reasons it's not being oxidized).

"Also, Rust’s memory safety only applies to code written in Rust, but a JIT compiler also generates machine code and then jumps to it. That generated code does not benefit from rustc’s static analysis."[1]

[1]. https://www.reddit.com/r/rust/comments/8ptnfr/servo_to_upgra...

Re:Firefox does not have a well-designed privsep model by yellowapple on Monday June 11, 2018 @08:54PM (#17289916)
"pledge() is pretty quaint versus memory safety."

Compile-time memory safety does fsck all when it comes to actual runtime memory safety, especially when it comes to things like JIT compilers (which generate machine code that is not under the same guarantees as the language in which that JIT compiler was written).

Put differently: Rust does not replace pledge. Pledge is a line of defense when Rust's compile-time guarantees are insufficient for whatever reason (e.g. when the program in question is generating machine code on-the-fly, like - again - with JIT compilers).

Even for programs which don't generate and execute machine code during runtime, there's still the possibility for things like rustc bugs, memory corruption (whether on disk or in core, and whether caused by cosmic rays or an attacker deliberately corrupting memory through some other attack vector), etc. that are inherently immune to compiler-level defenses (whether because the compiler is the thing affected, like in the former case, or because the problem happens after the program is compiled, like in the latter case). It also doesn't do much against bugs that have little to do with memory safety (e.g. flaws in authentication/authorization checks, bad DIY crypto, etc.).

Assuming you don't need other safeguards because you're writing your programs in Rust is incredibly naïve, to say the least. Don't get me wrong: Rust is a fantastic step in the right direction, and does eliminate a large swatch of real-world bugs. It ain't a silver bullet, though, and it's unwise to treat it as such.

Re:Firefox does not have a well-designed privsep model by taborj on Monday June 11, 2018 @05:10PM (#17288626)
Doesn't every email explaining the current state of <insert item here> become more and more obsolete over time?
Re:Firefox does not have a well-designed privsep model by hundchenkatze on Monday June 11, 2018 @05:24PM (#17288722)
Not if <inserted item>'s state stops changing. :)
Re:Firefox does not have a well-designed privsep model by taborj on Monday June 11, 2018 @05:36PM (#17288820)
A good point
Re:Firefox does not have a well-designed privsep model by peterwwillis on Monday June 11, 2018 @06:01PM (#17289002)
> There's simply no way for C++ to compete with Rust

There's no way for 8-track to compete with compact cassettes. There's no way for VHS to compete with Betamax. There's no way for C to compete with <insert any language>. Yet, against all odds, technical superiority does not always result in market dominance.

Call me when there's more Rust jobs than C++ jobs, or when they're not entirely posted to Rust mailing lists.

Re:Firefox does not have a well-designed privsep model by adrianmonk on Monday June 11, 2018 @08:27PM (#17289786)
They're not talking about popularity of the language. They're talking about two particular pieces of software, and which one will be ahead of the other based on the choice of implementation language.