Slashdot Mirror
Mozilla Will Ship Its First Rust Component In Firefox 48 (softpedia.com)
An anonymous reader quotes a report from Softpedia: Mozilla announced today plans to ship its first ever Rust code with the production releases of Firefox. The first ever Rust components will arrive in Firefox 48, scheduled for release on August 2, 2016. After teasing Rust features last year, the Mozilla Foundation announced today that Firefox 48 would contain a new media stack component that's entirely coded in Rust. The first Firefox component to feature Rust code was not chosen at random because media components often execute malicious code when parsing multimedia files. "This makes a memory-safe programming language like Rust a compelling addition to Mozilla's tool-chest for protecting against potentially malicious media content on the Web," says Dave Herman, Director of Strategy at Mozilla Research. During tests of this Rust-based media component in Firefox's unstable builds, Mozilla says that after one billion uses they have yet to see a crash or issue in the Rust media component. Last month, Mozilla released the first versions of Servo, a minimal browser created in Rust code alone. At around the same time, Microsoft open-sourced Checked C, an extension to the C programming language that brings new features to address a series of security-related issues.
Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?
Good question.
My guess is that running untrusted Java code in a trusted Java sandbox has a much larger attack surface than playing untrusted media in a (more or less) trusted Rust app.
The Rust code should still be an improvement, safety-wise, over the current C/C++ solution.
That does not mean the Rust solution will be perfect, and it *definitely* doesn't mean you should download and run untrusted Rust apps!
Rust does not derive its safety from a runtime sandbox, but from static guarantees enforced by its type system. This prevents memory errors that often lead to arbitrary code execution vulnerabilities, but it does not attempt to enforce higher-level semantic security properties, e.g. if you blindly use an untrusted string as a filename, you can still be tricked into opening /etc/passwd. Rust does not inherently protect you there, nor is it advertised as doing such.
Rust isn't run in a sandbox. It's like C++. It simply has some assurances that the code it compiles should be free of some classical problems that plague software development in systems languages, without it also sacrificing the close-to-bare-metal aspects of languages like C++, and with much more of the costs involved being pushed to the compilation phase than the runtime phase. That's much more than the likes of Java have tried to offer, and it's also why so many people love to bash on it: it's hard to buy into the assurances without enough time passing, and it's made by a relatively small company that's popular to bash on right now.
Java bytecode confinement is fairly safe. But the security model for the sandbox was a disaster, basically full of "become root" classes because it relied on poorly thought-out "code access security". Rust's security model is much simpler - it was not designed to contain untrusted code, but to make sure that trusted code is not going to blow up.
Nope, in fact its the opposite. Thanks to its ownership model, Rust eliminates most of the ugly access bugs that you might run into if you do multithreading. It puts the information whether something needs to be locked before being accessed, or whether its totally threadsafe into the type system, so that the compiler can verify everything is working as you intended it.
Of course, its not perfect, but rust is one of the languages you might want to start your multithreaded program in. It doesn't save you from thinking about the problems, but if you got it wrong, it won't compile. There are still bugs, but none that fall into the category C++ would describe as "undefined behaviour" (and those are many times the reasons for the most evil security bugs AND the hardest to debug).
Pale Moon is only worth it if you want to keep using obsolete tech. It's otherwise no better than Firefox, and has not improved significantly since its inception. It has already broken compatibility with more addons than Firefox did. It will either break compatibility with the obsolete tech you list in your post, or it will continue its slow downward spiral into irrelevance. It simply doesn't have the development community to be its own browser, and once Mozilla (rightly) stops supporting those outdated legacy things, you'll be SOL. Unless of course Pale Moon's community starts to actually pitch in beyond silly PR campaigns that overrate Pale Moon and poo-poo Firefox for "leaving them behind".
It really depends on where the rust occurs. If it's just on the panelling or in the chrome then you can sand it down and repaint, but if it's structural rust you're pretty much hosed. Time to switch to Pale Moon, which hasn't started rusting yet.
You're kidding me, right?
Please tell me that you're joking.
If this is true, I really have zero desire to learn the language. Anything swamped by the disaster of political correctness is, quite frankly, just not worth the trouble. If I'm going to use standard computer science terminology and get whined at because the same word means something not-warm-and-fuzzy in a totally different context, then I'm out.
Love sees no species.
That does not mean the Rust solution will be perfect, and it *definitely* doesn't mean you should download and run untrusted Rust apps!
Yes. Rust isn't a sandbox, it's a programming language with memory safety built into the type system. A rust program can do whatever it wants to your system if you don't sandbox it yourself. On the other hand, whole nasty classes of bugs related to buffer overflows, stack smashing and data races cannot happen, which makes it harder to attack from the outside than C.
It says nothing about whether you should trust a particular rust program to not be malicious.
SJW n. One who posts facts.
> That so only true if the compiler and run-time system do not have bugs.
We can be certain there are no bugs in Rusts run-time system because it doesn't have one.
It's true that the compiler needs to be correct but that's true of all compilers. Rust is a clean, modern design and the critical parts of the compiler are fairly small, so the Rust compiler's chances of generating correct code are pretty good, even compared with much more mature C compilers.