Tor Browser Will Feature More Rust Code (bleepingcomputer.com) 149
An anonymous reader writes:
"The Tor Browser, a heavily modified version of the Firefox browser with many privacy-enhancing features, will include more code written in the Rust programming language," reports BleepingComputer. In a meeting held last week in Amsterdam, Tor developers decided to slowly start using Rust to replace the C++ code. The decision comes after Mozilla started shipping Rust components with Firefox in 2016. Furthermore, Rust is a memory-safe(r) language than C++, the language used for Firefox and the customized Tor code, which means less memory corruption errors. Less of these errors means better privacy for all.
"Part of our interest in using safer languages like Rust in Tor is because a tiny mistake in C could have real consequences for real people," Tor developer Isis Agora Lovecruft posted on Twitter, adding "Also the barrier to entry for contributing to large OSS projects written in C is insanely high."
"Part of our interest in using safer languages like Rust in Tor is because a tiny mistake in C could have real consequences for real people," Tor developer Isis Agora Lovecruft posted on Twitter, adding "Also the barrier to entry for contributing to large OSS projects written in C is insanely high."
And the barrier for Rust isn't? (Score:4, Insightful)
I'm pretty sure the number of programmers who know C is several orders of magnitude higher than Rust.
Re:And the barrier for Rust isn't? (Score:5, Insightful)
I'm pretty sure the number of programmers who know C is several orders of magnitude higher than Rust.
I can't imagine that being a problem. Rust is a familiar looking language designed not to have shoot-yourself-in-the-foot holes. I'd expect a good developer, who's already familiar with other languages, to be contributing good PRs in Rust within a day.
Re: (Score:2)
You want an app that's supposed to protect your security online to be written by someone who hasn't studied or used the language but decided they could do well enough "within a day"? Yeah, no thanks.
Re:And the barrier for Rust isn't? (Score:5, Informative)
You want an app that's supposed to protect your security online to be written by someone who hasn't studied or used the language but decided they could do well enough "within a day"? Yeah, no thanks.
Honestly, yes. A clean language like Rust means that you won't get problems due to misuse of the language no matter how new you are to it; only due to misunderstanding of algorithms or architecture or security principals. The whole point of the comparison with C is that after a decade of experience in C you'll still find accidental security flaws due to unspotted buffer overruns or read-after-free.
Re:And the barrier for Rust isn't? (Score:5, Informative)
Quick goggle tells me that rust compiler is written in C.
That's why nobody seriously uses Goggle. Now if you tried Google [google.com], you'd get a snippet mentioning a "self-hosting compiler written in Rust" as the first result.
(Yes, Rust's code generation backend is LLVM, written in C++. Don't try to build strawmen out of this.)
Re: (Score:3)
However it emits bitcode which is optimized and transformed into machine code by LLVM. So after code has passed the multitude of safety checks in the front end it shares a substantial portion of its toolchain with Clang and other languages that make use of LLVM.
Reflections on Trusting Rust (Score:2)
A language with only one compiler written in that selfsame language can't be trusted very easily because all available binaries might have trojans that self-replicate using the technique that Ken Thompson demonstrated in "Reflections on Trusting Trust" [cmu.edu]. The usual way to detect a "Trusting Trust" trojan is David A. Wheeler's diverse double-compiling [dwheeler.com], which starts by bootstrapping a compiler's source code on three independent implementations of a language and seeing if the process of compiling a compiler with
Re: (Score:2)
That said I think it would be beneficial to see
Re: (Score:2)
The same could be said for gcc, clang
No it can't because there are multiple independent implementations of C++ available to the public. A licensee of Microsoft and Intel C++ can use those, Clang, and GCC for a four-way DDC test to ensure that the resulting Clang or GCC executable is free of self-replicating binary trojans.
or a bunch of other non-C++ languages. [...] And even if it happens for gcc, does it happen for every language that forms part of a modern distribution.
If the compiler for a non-C++ language is written in C++ or another language supported by GCC, you can do due diligence on GCC and then use that trojan-free executable as the first step in making reproducible builds of toolch
Re: (Score:2)
Re: (Score:3)
I'd expect a good developer, who's already familiar with other languages, to be contributing good PRs in Rust within a day.
Are you a manager? Do you actually code in Rust? Because while I don't code in Rust, I spent some time with it to understand what kind of guarantees it provides. There are several concepts that you have to wrap your head around and become familiar with before you can write code and know what's going on at a fundamental level.
Re: (Score:1)
what fundamental level? Its 2017! We dont care about how the shit works we just want it to work. you must be one of those stick in the mud "i want to be smart" people. Havent you noticed your kind are going the way of the do do bird..
Re: (Score:2)
Havent you noticed your kind are going the way of the do do bird...
I wish the do do bird would go the way of the dodo bird.
Re: (Score:2)
WAT?!?
Can somebody mod down ljw1004's disinformation? (Score:2, Informative)
This is not true at all.
Can somebody please mod down ljw1004's disinformation? I don't think he's ever even used Rust. Anybody who has actually used it would never make the claim that he just made.
Rust is not an easy language to learn.
Even people with extensive academic experience, years of industry experience, and an excellent understanding of a complex language like C++ will find Rust
Do you hear that? (Score:1)
Better duck. That whooshing sound is loud!
Re: (Score:1)
I'm pretty sure the number of programmers who think they know C is several orders of magnitude higher than Rust.
There, fixed that for you.
Re: (Score:2)
You still didn't get it right...
I'm pretty sure the programmers who know Rust are several orders of magnitude better programmers.
Re: (Score:2)
ITT: The Holy Wars begin.
Re: (Score:2)
Re: (Score:2)
I'm pretty sure the number of programmers who know C is several orders of magnitude higher than Rust.
You don't get it. In every respectably-sized C project, there are lots of assumptions about "objects" lifecycles (who allocates, who has to free), concurrency access, etc. Unless you have spent a long time in the code it's difficult to know all the conventions used throughout the project, and you're pretty sure you'll shoot yourself in the foot the first time you'll try to modify the code.
In Rust, all these conventions are encoded in the type system and are checked by the compiler. Which means that when you
Re: (Score:3)
Well rust must be reallllly good... (Score:1)
"because a tiny mistake in C could have real consequences for real people"
Seems rust is an ai that churns out code which can never do evil.
Re:Well rust must be reallllly good... (Score:5, Funny)
No one is suicidal enough to write critical code in C. What would happen if someone wrote, say, a kernel, in C!?!
Re: Well rust must be reallllly good... (Score:2)
And Rust is famously corrosive. Once your product starts to Rust, it gets ugly and easily broken. Pretty soon even a toddler can punch holes through it.
Re: (Score:2)
I can't wait for Rust to run on big iron.
Re: (Score:2)
What would happen if someone wrote, say, a kernel, in C!?!
The users would probably be subjected to an endless treadmill of updating their kernel packages and rebooting each of their machines every couple of weeks.
Re: (Score:1)
But that's really just it though isn't it? You write core functionality like a Kernel in C, but it's relatively small part of the overall code base - it's a part to which you devote a disproportionate amount of time relative to it's size because you absolutely must get it right and because hand crafting performance into it is incredibly important.
You wouldn't then however go and take C all the way up to your web stack, because that would be fucking stupid - the cost and time to productivity and security rat
Re: (Score:2)
Re:Well rust must be reallllly good... (Score:5, Informative)
What would happen if someone wrote, say, a kernel, in C!?!
The thing you observe around you right now: holes in kernels, servers, browsers, virtual machines, regular security announcements... (Because everyone decided to repeat the same mistake.)
Re: (Score:3)
Java has been around for over 20 years. JavaScript has been around for over 20 years. C# has been around for over 15 years. Haskell has been around for over 25 years. Python has been around for over 25 years. Go has been around for over 7 years. Rust 1.0 was released almost 2 years ago. There are many other "safe" languages that I haven't mentioned.
If you knew anything at all about software you would know the implications that garbage collection has on performance. It's a good thing you posted as AC because otherwise you would have just embarrassed yourself to the point that you'd probably be down-modded for the next fifty years.
So given all of this time, and all of these different non-C/non-C++ languages, why have we seen almost none of the types of software you listed be successfully implemented using them?
To reiterate: because performance.
Web browsers written in non-C/non-C++ languages have all been failures. Xena/Javagator was a failure. HotJava Browser was a failure. Grails was a failure. Servo is shaping up to be a colossal failure.
Servo was never intended to be actually used-- It's just an experimental prototype for research. [wikipedia.org]
Face it, C and C++ have proven themselves to be the only languages capable of being used successfully for the types of software that you listed. Despite having had allegedly "safer" languages for decades and decades now, we haven't seen anyone come up with anything to successfully replace the software written in languages like C or C++.
I like C++. But you're mistaken in thinking that Rust should be compared to JIT languages like
Re: (Score:2)
So where are all of the kernels, servers, browsers, virtual machines, etc., etc., etc., etc., written purely in "safer" non-C/non-C++ languages?
Probably in the same place where there are non-brainwashed programmers, like those who grew up with C since their very childhood? It's a vicious circle you're dealing with here.
Java has been around for over 20 years. JavaScript has been around for over 20 years. C# has been around for over 15 years. Haskell has been around for over 25 years. Python has been around for over 25 years. Go has been around for over 7 years. Rust 1.0 was released almost 2 years ago. There are many other "safe" languages that I haven't mentioned. So given all of this time, and all of these different non-C/non-C++ languages, why have we seen almost none of the types of software you listed be successfully implemented using them?
They're not quite old. C began around 1970. That's pushing fifty years of age now! And it took twenty years for many software systems to even start adopting it as the system language. Some, like MacOS, had an affinity towards Pascal before they started getting their first bits of C. Lots of those you mention are not suitable for it a
Re: (Score:3)
Re: (Score:1)
What is it with this perfect solution fallacy based Rust meme? No one is saying Rust can prevent all coding problems, except those of you creating strawmen. But solving some common mistakes is still a step forward, even if it is not solving all possible mistakes and problems.
Re: (Score:1)
"because a tiny mistake in C could have real consequences for real people"
As opposed to, "because a tiny mistake in C could have virtual consequences for virtual people."
C'mon . . . this is 2017 . . . nobody does anything real anymore . . . everything is virtual these days.
Remember:
If it's there, and you can see it . . . it's real.
If it's not there, but you can see it . . . it's virtual.
If it's not there, and you can't see it . . . it's gone.
Virtual people have virtual problems on virtual TV shows.
So, there!
Re: (Score:2)
If it's there, and you can see it . . . .
If it's not there, but you can see it . . .
If it's not there, and you can't see it . .
We should ask Donald Rumsfeld about this then.
Also, for the case of "If it's there, but you can't see it".
Alternatively you might have something to teach Rumsfeld about!
Uh-huh (Score:3, Interesting)
"Part of our interest in using safer languages like Rust in Tor is because a tiny mistake in C could have real consequences for real people," Tor developer Isis Agora Lovecruft posted on Twitter[.]
This line of thinking seems eerily similar to the arguments people make when they choose to roll their own encryption rather than rely on a pre-existing project like openssl.
Re: (Score:2)
Re: (Score:3)
In other words, "please someone else please do lots of hard but pointless work for me so that I may pretend to be productive [postgresql.org]."
It's actually amazing to me how maturely and respectfully the Postgresql guys responded to that. They are truly a mellow bunch.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
I've been doing 'C' for a _long_ time (and I remember and used the =+ and =- operators).
I haven't run into these over-complicated details of 'C'; maybe I've missed them. Elegant,
yes, but over-complicated - no!
It all comes down to testing - coming up with unit tests to ensure new code and/or changes
you make don't regress. Look at git hub - you can count (probably) on one hand the number
of projects that have a serious test suite built in to their code base - you know gmake test.
It's not the language, but th
Re: (Score:1)
From a code quality point of view, absolutely. OpenSSL is a horribly written, poorly documented codebase with a long history of coding mistakes.
From a cryptography point of view -- beware. There are a huge number of gotchas. It's not enough to implement the TLS and PKI specs to the letter. You have to make sure that your code is resistant to side-channel (timing) attacks, oracle attacks, workarounds for buggy clients/servers, workarounds for weaknesses in the spec, etc. Most of that comes about through tria
The budget per US federal case (Score:2)
Mixed-up priorities (Score:1)
" for real people," Tor developer Isis Agora Lovecruft posted on Twitter, adding "Also the barrier to entry for contributing to large OSS projects written in C is insanely high"
This is completely orthogonal to designing a secure browser.
Re: Mixed-up priorities (Score:2)
It's hard to add productive code to a large existing project. Large existing projects are mostly written in C. Therefore it's hard to contribute to C projects.
If this is what passes for logic among the Rusty Firefox set, I'll avoid it.
Re: (Score:2)
Re: (Score:2)
So why hasn't it happened?
It has happened. There are plenty of such libraries.
Your real question, I think, is why don't more people use those libraries (or write their own)? I don't know the answer to that, but it's why I commented, so more people can know the way (or a way).
Re: (Score:2)
Re: If it's scary, then you don't know C. (Score:2)
OpenBSD's use of C is scary because one obscure function that is only normally used to format data structures provided by the kernel had a bug that may or may not be exploitable?
And we're supposed to instead trust people who think the right syntax for a method that panics unless a result is good is ".expect(failure_message)"?
Re: (Score:2)
Nonsense. Use-after-free and double-free bugs are common sources of exploitable security issues, and "a decent string library and buffer library" doesn't help at all with those.
Re: (Score:2)
Or you can make it a function.
Re: (Score:1)
And yet use-after-free and double-free bugs continue to exist. Your approach isn't working, even though it's had since the 90s to deliver. We plainly need better languages than C.
Re: (Score:3)
Using some wrapper library to force dynamic checks on all pointer accesses would mean giving up all the advantages of using C in the first place.
Re: (Score:3)
And yet there is no good reason to use C for anything outside certain special fields like drivers or operating system kernels, and even in these fields usage of C becomes more and more questionable.
Re: (Score:2)
But let's talk more specifically why C is better than C++: C is a clean design from the beginning. It works very well in what it is designed for, and even its critics agree on that point. Whereas C++ is the opposite of a clean design, it is a
Re: (Score:2)
a design that allows undefined behavior is as dirty as they come.
Re: (Score:2)
Please, come up with something better.
Re: (Score:2)
I don't use it to defend C++, I use it to disprove your quaint notion that C is supposed to be clean and not an ugly hack of a language that should have died out twenty years ago. C++ is the lipstick that is used to make C look less like a pig - surprisingly with some success, especially since C++11.
Re: (Score:2)
Also, "undefined behavior" isn't an ugly hack, it's just reality in language design. Every language has undefined behavior except a special few like ML. Complaining about undefined behavior in a language is generally a sign that someone has no idea when it comes to language design.
Re: (Score:2)
"People, eat more shit. Billions of flies can't be wrong". Seriously, though, that was only done so people can feel a semblance of familiarity with the syntax. I personally can't stand C syntax, it is very awkward to type on any keyboard that differs from ANSI. All this letter salad is seriously uncomfortable on my German keyboards and even worse on keyboards meant for other
Re: (Score:2)
C# isn't completely defined. It has undefined behavior as well. It was so much effort to completely define ML that few people have wanted to go through the effort of completely defining a language since then.
Also, since you are a better programmer than average, if you had spent two years converting old C to C, it still would have been much safer and more readable code. That is not because
Re: (Score:3)
Matter of fact, yes. And this only drives my point home harder. I had to port a few of these for a proprietary embedded system. Ultimately it was easier to rewrite them in clean C++ and maintain the result than to maintain the original mess of code (and I am not really a C++ fan). There is no good reason to use primitive tools if advanced tools can do the job in a safer and more comfortable way. Only use primitive tools when advanced tools are unfit for the task on hand.
Re: (Score:2)
Try and compile any newly written C code on a platform other than Linux. Chances are it won't work.
Re: (Score:2)
If you were writing a real world application that pulled in half a dozen libs, then each of those is going to do different things with varying degrees of rigor plus your own code. Even the most scrutinized code in the world contains buffer overflow vulns so chances are your application does too. That probably doesn't matter for a game. It matters a lot for a system process or somethin
Re: (Score:2)
Rust never sleeps (Score:4, Funny)
This is a browser for Johnny Rotten
I am all for it (Score:4, Interesting)
I am all for it. I know there will appear a group of people here bragging how they are good programmers and never do memory bugs in C. Maybe it is true, maybe not. Still, show me even one bigger project written in C that never had any memory management related bug!
In a bigger project, you will not have just have programmers belonging to this elite. You will also attract less skilled developers. This could partly be solved by having more peer-review, but the more peer-review you have of the code and the more checks you do before committing, the slower the development process becomes. And even high class projects with amazing history of C usage like, OpenBSD, occasionally have their bugs.
My opinion is that it is better if the peer-review time and development time is spent on getting the algorithms correct rather than hunting around for memory handling issues.
My biggest concern about this move is the state of Rust. It is still somewhat "unstable" as it is a young language with heavy development.
Re: (Score:1)
Still, show me even one bigger project written in C that never had any memory management related bug!
Show me one bigger project completely written in Rust.
Re: (Score:2)
I would actually think - given the privacy and security of the project in question - that you'd WANT the barrier to entry to be high.
I'm not suggesting artificially raising the barrier, but if the people contributing don't understand type-safety, pointer-safety, etc. then does stripping all that out so they can contribute actually make better code? I would suggest that it actually achieves the opposite, long-term.
That's not to say that C is the ideal language here, or that Rust is any better or worse, but
Re: (Score:2)
I'm not suggesting artificially raising the barrier, but if the people contributing don't understand type-safety, pointer-safety, etc. then does stripping all that out so they can contribute actually make better code?
Why would you assume that good pointer/type safety skills makes a “better programmer” in a situation where type/pointer safety is a non-issue? I don't see how a SQL script writer would benefit from understanding pointer arithmetic or tracking of resources.
As for argument that this is an artificial barrier that would discourage “bad programmers” from even trying, a) rust has quite a steep learning curve and b) if need for understanding type safety was any deterrent, JavaScript would n
Re: (Score:2)
I'm not suggesting artificially raising the barrier, but if the people contributing don't understand type-safety, pointer-safety, etc. then does stripping all that out so they can contribute actually make better code? I would suggest that it actually achieves the opposite, long-term.
It doesn't strip out type safety. It is a strongly typed language. In some ways more strongly typed than C or C++ because it doesn't allow you to cast things except some numeric types. What the language does allow you to do is skip the type declaration if the compiler can infer it from your code but it still enforces that type. So you couldn't assign a variable to be a bool or an int from two branches of a conditional for example.
Pointer safety isn't an issue because you don't use pointers in safe program
Re: (Score:2)
'Safe' vs 'unsafe' I think is the wrong dichotomy.
Consider that the world actually needs 'unsafe' tools - for instance: knives, saws, fire. But what you want in tools like this is they always act in a nice deterministic way so, if you treat them with respect, you can obtain useful work from them.
Code is essentially the same thing. What is necessary is the proper amount of respect for the damage your tools can inflict, not suggesting everyone to use safety scissors (except where it's appropriate of course).
And does it work properly? (Score:1)
Isn't that all that really matters? Who cares even if it's 100% written in binary code? (I mean my hat off to whomever would be fucking crazy enough to do something like that)
Am I getting my point across?
Firefox is a project without a system engineer (Score:5, Insightful)
Is it so hard to write code that compiles with 0 errors and 0 warnings that will pass valgrind with with 0 warnings?
Firefox (and by extension Tor) need to figure out why with 70+ threads they still have deadlocks. Perhaps they need a language that doesn't do threading?
Actually I exaggerated, currently Firefox is only using 68 threads to display this page...
Project without a _REAL_ system engineer?
Re: (Score:2)
This sounds like the same sort of mentality that gave us Java. Sun created Java in its own image, so it encouraged extra threads and creation of lots of objects because they figured it would run on big machines. They sold it though as something that would run everywhere. The threading and objects made it run like a dog on small machines.
Re: (Score:1)
Wonder what you'll think about Chrome and Google when you realize it needs even more resources to do the same job without much benefit, and still with the same warnings, memory leaks, deadlocks and other crap that we know and love.
Re: (Score:2)
Why not actually research before commenting? (Score:1)
You wouldn't look like a fool if you bothered to read up on Rust before commenting on it. Your understanding is completely erroneous.
Re: (Score:2)
Of course exploits are going to be found in Rust code. It's not like it magically makes it impossible to write exploits. It's just that those exploits won't be memory safety bugs, buffer overruns or the like, because the Rust compiler rejects code with those. No point spending programmer time dealing with those when the compiler can handle it.