C has critical flaws everywhere: insane preprocessor, no module system or namespaces, all kinds of obscure undefined behaviors, no way to express important safety properties like "pointer is never null", weak type system that can't express tagged unions or tell the difference between data and code pointers (https://lkml.org/lkml/2017/9/25/708), broken type syntax where it's impossible for humans to write complex types, security-bug-prone standard library APIs like sprintf and strcpy, standard library missing basic stuff like hash tables, inability to expose basic library features like ref-counted pointers and growable arrays ergonomically,...
This is totally wrong. The runtime and compiler models for Rust are pretty much exactly the same as for C. People are running Rust code on 8-bit microcontrollers: https://github.com/avr-rust/ar.... You can write kernels and device drivers in Rust and people are.
This is all less true about Go because it needs a garbage collector.
Lots of smart people have tried hard to pull this off. See, for example C-Cured from UC Berkeley. They did not take off. I doubt ESR's "friend" is going to succeed where they failed.
I think an approach like Rust is more likely to be successful, where in addition to providing safety you provide a lot of nice language features to make the language more appealing.
I wrote about this: http://robert.ocallahan.org/20... Summary: In practice, attackers can leverage arbitrary-write bugs to produce the same-origin violations Microsoft warns about without requiring RCE, completely bypassing the CFI mitigations Microsoft is touting here.
Firefox downloads the required DRM module from a third-party server when you first try to use DRM'ed content.
The modules are closed source, but available on the major platforms, including Linux. I watched a DRM'ed show on Netflix in Firefox on Linux last night.
Although the modules are closed source, in Firefox they are sandboxed. They cannot do much more than decode audio and video. They can't access arbitrary files or call arbitrary platform APIs with the user's privilege. They have access to persistent storage, but only mediated by the browser, so the browser can corral or wipe that data on user request. Thus, in Firefox at least, there is no more privacy risk than other forms of Web client storage.
WebExtensions supports user scripts so there doesn't seem to be any reason why Greasemonkey couldn't be ported to WebExtensions. https://developer.mozilla.org/...
Brave's good but using it still aids Google since you're increasing the market share of Chromium, which Google controls; by making Chromium more dominant, you increase Google's power over the Web.
If you want to do your bit to reduce corporate power over the Web, Firefox is pretty much the only choice these days.
> Control of aliasing? There's a keyword for that.
Ada's "aliased" keyword simply controls whether you can create a reference to a variable at all, so you have two options: "no references" or "free-for-all". Rust is vastly more powerful. Read the Rustbelt paper.
> Immutable references? You can find examples in the standard container library.
Not sure what you're referring to. Ada's "constant" keyword is like C/C++ "const": you can't modify the value through that reference, but it could change under you via modification through some other reference. That's much weaker than the guarantee that Rust can provide.
> Data race freedom? Protected types.
Haha, by forcing taking a mutex for every read and write? No thanks. Plus, the option to use "protected" is just that, optional; the language is not statically preventing the programmer from introducing data races, like Rust does.
> No possibility of dangling pointers? Access level restrictions.
I'm not sure what you mean here. Rust provides static deallocation with compile-time checking that you don't leave dangling pointers, but in Ada deallocation is unchecked.
It is actually very easy for "incompetent" C coders to hack something together that works and is shipped, and is later discovered to be riddled with security holes. This happens all the time.
It is also easy for very experienced and talented C coders to do exactly the same thing, and that also happens all the time.
The first four bugs are basically all the same "StackClash" issue.
It's true that you can't just turn off your "security brain" when writing code in Rust or any other language. There are a lot of security-relevant bugs that are language-independent. But there are a lot of other bugs that very much depend on the weaknesses of C and C++.
If you make all that investment and fix all those bugs, you will get pretty robust C code, but fuzzers and dynamic analyzers by nature don't find all bugs even of the type they're designed to search for, so you can be sure more of the same sorts of bugs remain.
But if you use Rust, then whole classes of bugs simply won't happen. Not only will you get more robust code at the end, but it will save most of the time and money you spent hardening your C code.
Even extremely good C/C++ programmers make mistakes that have disastrous consequences. For example, the C++ developers working on browser engines at Microsoft, Google, Mozilla and Apple are extraordinarily good on average, yet every one of their veterans will be able to tell you war stories about security bugs in code they wrote
There is no large pool of skilled C/C++ programmers who routinely get everything right. Most people who think they're in that pool have simply never had their code thoroughly fuzz-tested or attacked by adversaries.
You can always write your own linked-list library that uses a little bit of unsafe code. Or use one that already exists, like the one in the standard library: https://doc.rust-lang.org/std/...
I've written a lot of Rust code over the last year. Hardly any of it uses unsafe code, but escaping to unsafe code once in a while is much better than making the whole language unsafe or making the type system super-complicated in an effort to reduce the amount of unsafe code required even further.
Ada has nothing like Rust's affine type system and the Rust features that flow from it --- strong control of aliasing, immutability guarantees (while you have an immutable reference to data, *nothing* else can modify that data), data-race freedom, dynamic memory allocation with no possibility of dangling pointers while not requiring GC/refcounting, etc.
Slashdot Mirror
> Static code analysis and runtime checking (valgrind) pretty makes C's little issues a non-event now.
Just not true, even if you add in manual security audits as well. For example:
https://lwn.net/Articles/73545...
C has critical flaws everywhere: insane preprocessor, no module system or namespaces, all kinds of obscure undefined behaviors, no way to express important safety properties like "pointer is never null", weak type system that can't express tagged unions or tell the difference between data and code pointers (https://lkml.org/lkml/2017/9/25/708), broken type syntax where it's impossible for humans to write complex types, security-bug-prone standard library APIs like sprintf and strcpy, standard library missing basic stuff like hash tables, inability to expose basic library features like ref-counted pointers and growable arrays ergonomically, ...
I could go on and on.
This is totally wrong. The runtime and compiler models for Rust are pretty much exactly the same as for C. People are running Rust code on 8-bit microcontrollers: https://github.com/avr-rust/ar.... You can write kernels and device drivers in Rust and people are.
This is all less true about Go because it needs a garbage collector.
Lots of smart people have tried hard to pull this off. See, for example C-Cured from UC Berkeley. They did not take off. I doubt ESR's "friend" is going to succeed where they failed.
I think an approach like Rust is more likely to be successful, where in addition to providing safety you provide a lot of nice language features to make the language more appealing.
I wrote about this:
http://robert.ocallahan.org/20...
Summary: In practice, attackers can leverage arbitrary-write bugs to produce the same-origin violations Microsoft warns about without requiring RCE, completely bypassing the CFI mitigations Microsoft is touting here.
Firefox does notify the user and give them an opportunity to opt out. Please check your facts instead of just making them up.
> The buggy flash plugins that infect pc's. The java pugin that formats your hard drive.
No, the EME CDMs are sandboxed and can't do those things. That is one reason they're better than NPAPI plugins.
Firefox downloads the required DRM module from a third-party server when you first try to use DRM'ed content.
The modules are closed source, but available on the major platforms, including Linux. I watched a DRM'ed show on Netflix in Firefox on Linux last night.
Although the modules are closed source, in Firefox they are sandboxed. They cannot do much more than decode audio and video. They can't access arbitrary files or call arbitrary platform APIs with the user's privilege. They have access to persistent storage, but only mediated by the browser, so the browser can corral or wipe that data on user request. Thus, in Firefox at least, there is no more privacy risk than other forms of Web client storage.
And it doesn't even affect the Web all that much.
EME lets browsers play back DRM'ed video and audio. That's all.
Firefox supports EME, but you can disable it by unchecking "Play DRM-controlled content" in preferences.
For the masses, though, "Netflix doesn't work!" is not a compelling sales pitch.
Good thing NoScript, Adblock Plus and HTTPS Everywhere have WebExtensions versions then.
WebExtensions supports user scripts so there doesn't seem to be any reason why Greasemonkey couldn't be ported to WebExtensions.
https://developer.mozilla.org/...
Brave's good but using it still aids Google since you're increasing the market share of Chromium, which Google controls; by making Chromium more dominant, you increase Google's power over the Web.
If you want to do your bit to reduce corporate power over the Web, Firefox is pretty much the only choice these days.
In fact, it even blocks non-Chrome Chromium browsers such as Opera etc!
> Control of aliasing? There's a keyword for that.
Ada's "aliased" keyword simply controls whether you can create a reference to a variable at all, so you have two options: "no references" or "free-for-all". Rust is vastly more powerful. Read the Rustbelt paper.
> Immutable references? You can find examples in the standard container library.
Not sure what you're referring to. Ada's "constant" keyword is like C/C++ "const": you can't modify the value through that reference, but it could change under you via modification through some other reference. That's much weaker than the guarantee that Rust can provide.
> Data race freedom? Protected types.
Haha, by forcing taking a mutex for every read and write? No thanks. Plus, the option to use "protected" is just that, optional; the language is not statically preventing the programmer from introducing data races, like Rust does.
> No possibility of dangling pointers? Access level restrictions.
I'm not sure what you mean here. Rust provides static deallocation with compile-time checking that you don't leave dangling pointers, but in Ada deallocation is unchecked.
> If I write a language in Rust, i doubt that would be the case.
You're wrong. Rust has 'extern "C"' functions.
> No Rust support
That's wrong too, there is a Rust fork targeting Arduino (albeit not mainline).
https://github.com/avr-rust/ru...
Because before Rust there weren't any languages that let you incrementally replace C code and have safety.
It is actually very easy for "incompetent" C coders to hack something together that works and is shipped, and is later discovered to be riddled with security holes. This happens all the time.
It is also easy for very experienced and talented C coders to do exactly the same thing, and that also happens all the time.
The first four bugs are basically all the same "StackClash" issue.
It's true that you can't just turn off your "security brain" when writing code in Rust or any other language. There are a lot of security-relevant bugs that are language-independent. But there are a lot of other bugs that very much depend on the weaknesses of C and C++.
> They are good and safe.
The endless treadmill of Linux kernel "must update" updates suggests this is not true.
If you make all that investment and fix all those bugs, you will get pretty robust C code, but fuzzers and dynamic analyzers by nature don't find all bugs even of the type they're designed to search for, so you can be sure more of the same sorts of bugs remain.
But if you use Rust, then whole classes of bugs simply won't happen. Not only will you get more robust code at the end, but it will save most of the time and money you spent hardening your C code.
Even extremely good C/C++ programmers make mistakes that have disastrous consequences. For example, the C++ developers working on browser engines at Microsoft, Google, Mozilla and Apple are extraordinarily good on average, yet every one of their veterans will be able to tell you war stories about security bugs in code they wrote
There is no large pool of skilled C/C++ programmers who routinely get everything right. Most people who think they're in that pool have simply never had their code thoroughly fuzz-tested or attacked by adversaries.
You can always write your own linked-list library that uses a little bit of unsafe code. Or use one that already exists, like the one in the standard library: https://doc.rust-lang.org/std/...
I've written a lot of Rust code over the last year. Hardly any of it uses unsafe code, but escaping to unsafe code once in a while is much better than making the whole language unsafe or making the type system super-complicated in an effort to reduce the amount of unsafe code required even further.
Ada has nothing like Rust's affine type system and the Rust features that flow from it --- strong control of aliasing, immutability guarantees (while you have an immutable reference to data, *nothing* else can modify that data), data-race freedom, dynamic memory allocation with no possibility of dangling pointers while not requiring GC/refcounting, etc.
This paper explains the unique virtues of Rust in a language-theoretic manner: https://people.mpi-sws.org/~dr...
I'm almost certain that Daniel does not work directly for Mozilla Corporation (USA) but some European subsidiary.
I worked for Mozilla's NZ subsidiary and never had any trouble entering the USA on a visa waiver.