This is why we need rust. Has Windows and edge and VMware used rust, these bugs wouldn't have happened. Rust is a game changer with it's borrow checker.
Let's not make magic bullet statements about technology. It's a good way to scare people away...
Isn't that the point of the parent's comment?
Complete hyperbole. All anyone says is that Rust prevents a class of security issues related to memory access.
Sure, bad logic bugs happen of course, but more often than not they result in bugs relating only to their own area and often somewhat limited in scope. They're also usually a fairly significant mistake that's often times easier to see - not necessarily all the time, but I'm probably more likely to catch a logic bug in a code review than I am a memory issue beyond a missing free.
Memory bugs however are much nastier - even a minor mistake can result in a complete takeover of the system as manipulation of the instruction pointer basically means game over and there are many ways to get that with only a little memory manipulation - blow out the stack until you overwrite the return address, overwrite vtables on the heap, overwrite function pointers, etc. Even a minor off-by-one can result in total exploitation in some scenarios.
Having the world re-written in rust is roughly the same as having linux on the desktop everywhere. It so far hasn't happened and what the world will look like once it does is anybody's guess, some classes of bugs will disappear, quite possibly. Other classes of bugs may then become more dominant. If rust automatically meant 'bug free software' that would be one thing but there are many classes of bugs and quite a few of those classes will lead to security issues.
It kind of has, though Linux contributed kernel, not UI. And "desktop" is mobile phone. It's not what everyone had in mind when we talked about Linux on desktop though.
But to answer your point about Rust, the reason there is no such OS is that security in itself is not a prevailing factor when people choose OS. Which doesn't make gp's argument false, it just shows why his wishes about Rust in critical software will probably never be granted.
What has happened is that a new class of devices was created that uses linux at the core, but that's not the desktop. (Happy 'linux on the desktop' user here since a very long time, roughly since it supported 'X' and my trusty SGI Indy got too slow to stay with the times).
Anybody that wants rust to replace C (or any other language) would be better of coding than complaining.
You had your own SGI Indy? I only had temporary access to one, but loved it at the time...
EDIT: it happened at home (mobile), not so much in business.
A whole bunch of them in fact. The only thing surviving from those days are the keyboards. Indestructible.
If you consider all the consumer electronics with a GUI that run under Linux, it is probably even "worse" (well, worse for Windows...)
You could argue that all of that does not make a unified platform, but neither does all the Windows (although the fragmentation might be somehow less important there)
Believing that a system/techno can take over the world in a year can be stupid. Believing that market dominance can't change in a decade or 2 (even if that's driven by usage changes), equally so.
(I was kind of surprised when MS started to completely switch their strategy and be furiously OS agnostic in tons of area. When you look at the figures, they actually did not have the choice if they want to survive the next several decades, and they probably would not have done that if they had...)
For instance, the browser Javascript VM will most likely use some form of JIT, which works by generating machine code at runtime, and then executing the generated code. Nothing in the Rust language can prevent a bug in the generated code from being exploitable.
And even within pure Rust code, developers can and will do unsafe tricks to get the last few percent points of speed (for instance, storing flags in the least significant bit of pointers). While Rust requires these parts to be marked with "unsafe" (which allows reviewers to focus on them), it cannot prevent bugs caused by these pieces of code.
Rust isn't a panacea or cure-all, and its fans are doing more harm than good (for Rust) by their zealotry on this matter, in my view.
And just to make it very clear: I do like Rust. It has some great features that I can envision having an excellent (and superior to C or C++) case for using in certain kinds of systems and application programming. But I'm not convinced these features are as much of a safeguard as some apparently are.
They are - there is a world of difference between the two. From a security perspective the ability to audit unsafety explicitly is massive. Right now we rely on intuition and fuzzing at large scale to try to cover massive parts of a codebase. With explicit unsafety you can limit your checks to a subset of modules, rather than the entire program. Massive, massive difference that can not be understated.
> if Rust gains any genuine traction and widespread use it is very likely they'll exist "in the wild" and as exploits waiting to be discovered.
Naturally. But this certainly isn't worse than where we are now - where languages make 0 effort to be safe, or have far too much historic baggage to do it meaningfully.
Beyond that, rust's attitude towards security is pretty positive. Rust has been quick to adopt LLVM sanitizer support, fuzzer support for AFL and cargo-fuzz, and new mitigation techniques such as safestack. With rust's updates coming out quickly you get access to these in a matter of weeks/ months as opposed to years.
Rust isn't a cure-all, no one should be calling it one. But your response is overly pessimistic.
Businesses love money more than they love C, if rewriting made economic sense, it wouldn't need to be lobbied.
This is like hiring somebody to build a bridge, it falling due to incompetence killing hundreds of people and then having nobody suffer any consequences. "Eh, bridges fall, what can you do."
Make people pay for buffer overflows and C is gone tomorrow.
There are times when C is unavoidable, unfortunately, but when somebody chooses a technology regardless of better, safer alternatives, "just because", they should be made liable, absolutely.
There are safer, better alternatives for almost everything we do. But economy dictates that we end up with a compromise. Rust would be just another compromise, slightly different stage, no huge difference and potentially a huge cost.
Silver bullets in software development do not exist, rust is no exception to this and the irrational hyping of rust as being a silver bullet actually has the opposite effect.
If rust is that much better at all aspects of software development (and not just in preventing one class of bugs) then it will find mainstream adoption. But you don't get that effect by ramming it down other people's throats, you get that effect by showing it in practice. And this is where rust - at least so far - is underwhelming.
Also, and this is another point of irritation with me, the rust community makes it seem as if theirs is the only language that will avoid this kind of bug, which is far from true, there are other platforms / languages with far wider adoption that have these traits as well.
I think the argument is that the economics need to change. People need to stop being irresponsible - we need liability when someone is negligent, just like in any other engineering discipline.
> Silver bullets in software development do not exist, rust is no exception to this and the irrational hyping of rust as being a silver bullet actually has the opposite effect.
I keep seeing this, and yet I have not once seen anyone call it a silver bullet.
> Also, and this is another point of irritation with me, the rust community makes it seem as if theirs is the only language that will avoid this kind of bug, which is far from true, there are other platforms / languages with far wider adoption that have these traits as well.
Show me another language with no garbage collection, memory safety, C/C++ level performance that has been anything other than academic.
I totally agree with that and have been a long time proponent of liability for damage caused by software bugs.
But that would have to be all bugs, not just some classes of bugs.
> Show me another language with no garbage collection, memory safety, C/C++ level performance that has been anything other than academic.
D.
And by the way, rust is only 'memory safe' as long as you don't disable the safety mechanisms, so I think 'memory safe by default' would be a better way to describe it.
Why? That goes against everything we've done to categorize bugs - we do not treat all bugs the same, and we would not consider all bugs to be due to negligence.
> D.
Only with a garbage collector or a 'safe' annotation. Rust has the opposite - a safe language by default.
> And by the way, rust is only 'memory safe' as long as you don't disable the safety mechanisms, so I think 'memory safe by default' would be a better way to describe it.
That's fine, memory safe by default is an acceptable way to refer to it. It's worth noting that I have written thousands of lines of rust code and never published code with a single line of unsafe. None of my projects have required it. So 'by default' is pretty powerful, since I've never ever needed to opt out.
That would be something you could only know by evaluating this on a bug-by-bug basis, the important thing to realize is that to an end user it simply does not matter what class of bug caused their data-loss, loss of privacy or loss of assets.
That said, I feel that we're now talking about memory safety vs semantic safety.
We can certainly prove a program is entirely memory safe. Rust's type system is prove, so the work is then to prove the unsafe code safe (actively being researched).
There is no way to prove all semantics of a program (Rice's theorem). Therefor I would argue that a bug is due to a semantic issue is not necessarily negligent, whereas we could easily see memory safety issues from using C as a case of negligence.
But in terms of liability they would likely both fall into the same bucket.
So the ideal as you perceive it is so far from realistic that I do not believe pursuing that road is fruitful.
What we can do is class bugs (or actually, the results of bugs, the symptoms that cause quantifiable losses) in general as a source of (limited) liability. This will put those parties out of business that are unable to get their house in order without mandating one technology over another (which would definitely be seen as giving certain parties a competitive edge, something I don't think will be ever done).
So that's why I believe that solution is the better one.
But in a perfect world your solution would - obviously - be the better one, unfortunately we live in this one.
Why is 'you should not have exposed C code to the internet' an unreasonable basis for care?
I'm not saying your approach is wrong, I think they're not mutually exclusive - your solution would provide incentive to not use C in a technology agnostic way. But at some point isn't it just irresponsible to write critical infrastructure, or code that exposes user information, in a language that has historically been a disaster for security?
Because it does not mesh with reality. There are 100's of millions of lines of C code exposed to the internet in all layers of the stack. So if you start off with a hardcore position like that you virtually ensure that your plan will not be adopted.
It's the legacy that is the problem, not the future.
> But you don't get that effect by ramming it down other people's throats, you get that effect by showing it in practice.
I disagree. I've seen many C programmers who think that C is the be all end all of programming languages. Those people will not be convinced by showing them another technology that is better in practice. The fact that it's actually unbelievably hard to write correct software in C is somehow a point of pride for many people, though I speculate that few of them can actually follow through.
Of course there will always be logic bugs in software, even with formal systems and whatnot (i.e. bugs in the specifications). But memory bugs and the resulting security exploits could in many cases be a thing of the past already.
Many industries have similar regulations, i.e. seatbelts in cars. If somebody dies because of a faulty or non-existing seatbelt, there will be consequences. If somebody dies because they were talking on the phone and the car didn't prevent it, well, you can't control everything.
Is this a buffer overflow? Why was this written in C? No good answer - pay up.
You can't really use these analogies in a security context, because real world engineers aren't liable if their designs fail due to sabotage, overloading or other unexpected conditions outside the standards they designed to.
Software is different to real world 'analog' engineering in that a single very small mistake can bring down the whole thing. Most civil engineering designs would be riddled with small mistakes like that, but the overall system has (multiple layers of) factors of safety built in and the ability of other parts to compensate. You can see how concrete buildings in war zones (even places with shoddy engineering standards to begin with) can take large fractions of their structure being shot away before failing. A software vulnerability though is like finding just one perfect place where a single bullet could bring the whole thing down.
The EU is now taking Google and other corporations to task for their user agreements (licenses), to try to get them into compliance with consumer law there. It's a start, I suppose. https://www.theregister.co.uk/2017/03/17/europe_facebook_goo...
Just out of curiosity, what kind of performance penalty are people be willing to accept in exchange for memory safety?
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
I'm not anything close to a developer (scripting to scratch my own itches is the extent of any "development" I do) so I can't claim to truly understand the issues other than generally, at a high-level.
I've heard variations of this argument -- "Rust will save us!", if I may exaggerate slightly -- many, many times and it seems to be occurring more often lately. It makes me genuinely wonder, then, why isn't the first priority to immediately begin work to rewrite all of the existing "legacy" code in Rust? IIUC, Mozilla has been working on rewriting Firefox is Rust -- which is A Good Thing(TM), it seems -- but that's the only major piece of software I've heard about.
If Rust truly is this panacea that it's often made out to be, why is code continuing to be written in anything other than Rust?
Familiarity is a huge one that impacts adoption. There's many other factors discussed.
In the book The Diffusion Of Innovation there are two great examples given.
The first is a health official trying to convince a town of people to boil their water in order to avoid infection. They utterly failed to convince anyone to do so because the concept of 'germs' was totally unfamiliar to these people, and the need to boil water conflicted with their cultural conception of the issue.
The other is dvorak - a keyboard layout that is, by some metric, objectively better than QWERTY. And yet adoption barely exists.
The reasons rust is not being used to replace C everywhere are many - Rust is young, many people do not want to learn rust, many people do not care about software security, rust has an unfamiliar syntax/ concepts in it, rust has a younger ecosystem, etc.
There is also the issue of liability in software. If I write an internet facing text-parser in C, and it's full of vulnerabilities, I am not liable. My negligence in technology choice (and I do consider it negligence) does not impact liability, unlike any other engineering discipline. So why change?
Some things never change.