Tor Browser Will Feature More Rust Code (bleepingcomputer.com)
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."
I'm pretty sure the number of programmers who know C is several orders of magnitude higher than Rust.
I still have more fans than freaks. WTF is wrong with you people?
"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.
"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.
#DeleteChrome
is able discover the origins of onion routing users. A change in code is nice but does not change the ability to track and find.
Domestic spying is now "Benign Information Gathering"
Isis agora lovecruft
" 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.
Yeah, you should totally trust someone who runs Randi Harper's industry blacklist of "problematic" people in tech. Problematic... like White people. Or Male Identifying Penis Carrying Humanoids. Or the more than three quarters of the US who didn't want to follow the faux-left Clintonites down the drain.
Hell, the "they/them" madeup bullshit pronouns on his twitter profile is enough to stop paying attention to him, but the fact that he joined in on or even spearheaded the Jacob Applebaum lynch mob which was later proven to be a hoax created by 3 white knights who refused to even ask the supposed "victims" (who rejected it outright) they decided to speak on behalf of is enough: https://twitter.com/isislovecr...
(Personal rule: Someone who claims to have made up bullshit pronouns is male. Since gender is a social construct and men and women have equal rights, this is not transphobic because gender doesn't matter, right?)
Also, what's the "insanely high" bar for C? Knowing how to code? Yes, yes. Very problematic. Why would you want to require people to know how to code to contribute source code to a browser that millions rely on to keep themselves safe from being killed to actually know how to... contribute source code.
That's to say: the difference between knowing C and not knowing C is like that between being able to find your arse with either hand, and not.
Those for whom C is the main hurdle shouldn't be let anywhere near the design of a critical piece of software such as Tor, let alone its implementation, regardless of language.
This is a browser for Johnny Rotten
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.
The barrier of entry for contibuting to large OSS projects is high, but that is because those projects are large and complex, not because they are written in C. There is no shortage of C programmers and the language itself is simple. Moving to Rust will make the barrier of entry higher, not lower, since there are few programmers who know Rust or are willing to learn your favorite pet language of the week in order to submit a patch, regardless of its merits.
Comes down to "we have a community of people who are excited to build it in Rust and that's that"
So there it is.
Every time someone says this is better than that it doesn't stay that way very long. Since Rust is new and pretty much running on Firefox and Tor and their cousins. Which is great but hardly catching on as replacing C++. Even if it does become popular, what's to say exploits won't be found in Rust considering that recent hacking competition had no trouble with Firefox. The other question is, will Rust even become popular other than with Firefox?
> Also the barrier to entry for contributing to large OSS projects written in C is insanely high
There, FTFY:
> Also the barrier to entry for contributing to large projects is insanely high
Programming is Hard. And Complex Systems are... uh Complex.
Every language has its specific difficulties, and may be Rust is "better" than C in many respects (then maybe not, I just don't know, and I tend to distrust excited evangelists a bit).
An old project always carries a considerable baggage of technical debt, so maybe Mozilla looks way better after having been rewritten to "whatever". I sure hope so. There are always risks, like shedding the old contributors (and therefore important knowledge) over a community-splitting design decision), second system syndrome and others. There are enough success stories out there, though.
But assigning (nearly) all to the language choice is to me always a sign of inexperience.
When growing a huge application, you're creating a big building of languages anyway: being aware of those and carefully managing their growth, their interaction and their teachability is much more important than the "base" language.
As once a (Balinese) craftsman said to me "don't improve your tool: improve your craftsman" (OK, a bit extreme, but it does help to broaden the focus, doesn't it?)
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?
I tend to rant.
As I understand it, Rust is yet another language with arguably good features, but still runs on some sort of virtual machine, akin to a JVM.
If the Rust creators made it so it wrote *native* code then I'd have more warm feelings. I don't care what's said about optimization. Until then, I'd rather use the devil you know JVM where I'm stuck with it.
I've read that there is a strong feminist movement that is associated with Rust, and that just makes me think that the technical aspects of Rust will suffer.
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?
TODO: create/find/steal funny sig.
For a language that's supposed to make it so much harder to write buggy code, Rust's implementation (which is written in Rust, like you point out) sure is buggy! Right now there are over 3,000 open issues and over 17,000 closed ones.
If the people who developed the language itself, and who presumably know it best, can't even reliably use it to create bug-free code, how are normal programmers supposed to be able to?
And don't waste our time trying to compare Rust's implementation to GCC by saying "But GCC has bugs, too!". GCC is massive compared to Rust. It includes front-ends for numerous languages (C, C++, Objective-C, Objective-C++, Fortran, Ada, and Java, among others), plus numerous back-ends for a variety of platforms, plus a lot of other code. Rust is tiny in comparison. It's just a simple compiler front end for one language, and a limited standard library.
Ignoring the bug problem, it's not like Rust has helped the Rust developers themselves develop their product faster, either. Rust 1.0 was very much delayed. It isn't just the Rust implementation that was affected by this. Servo, which is also developed by Moz://a and which features some of the same people who are working on Rust, is taking forever to product something usable. Even IE 3 gives a better experience at this point.
When we look at the evidence, Rust doesn't fare well at all. It just doesn't live up to the hype. It doesn't help avoid bugs. It doesn't increase programmer productivity. It puts you through a lot of pain for no gain.
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's learning curve to be steep. "Lesser" programmers will have a much, much more difficult time with it.
Based on my experience and that of a number of very experienced and skilled programmers that I know, it would take at minimum of 2 weeks for a talented programmer to become barely proficient with it. Two or three months is a more reasonable time frame for an average programmer.
Rust is not a language like Java, C#, Python, or Go, where a good C++ programmer can be writing high-quality code within a few days. It's much more like Haskell, where even experienced practitioners need a lot of time (measured in weeks or months) to truly understand its concepts and nuances.
Anyone who claims that Rust can be learned well "within a day" is full of bullshit.
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". The usual way to detect a "Trusting Trust" trojan is David A. Wheeler's diverse double-compiling, 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 itself converges to identical binaries. But you can't do DDC if the only available Rust compiler is written in Rust. Sure, you can use OCaml to compile the old Rust frontend and use old Rust to compile the new Rust frontend, but then you'd need multiple independent OCaml compilers so that it can be verified using DDC.
Sure it's safer, for idiots that don't know how to code in the first place.
Better duck. That whooshing sound is loud!
You wouldn't look like a fool if you bothered to read up on Rust before commenting on it. Your understanding is completely erroneous.
"...which means less memory corruption errors. Less of these errors means better privacy for all."
I think you meant: "...which means fewer memory corruption errors. Fewer of these errors means better privacy for all."
There. Fixed.
mrustcc or something. Look it up on github.
*HOWEVER* the problem, based on what I've read, is that a 'blessed' compiler is needed, which is signed by each successive compiler in the chain (in 'mozilla' rust's case, this was first the ocaml version as a bootstrap in a now incompatible version of rust, then a series of further incompatible rust compilers that were self-hosting in the interim, and now the current rust compiler binary required to bootstrap current rust versions.)
This is the same concern I have with ada, or I would just use that instead! The only serious non-commercial compiler available is GNAT and in order to trust it you have to trust *EVERY BINARY* used to compile it in the past 20+ years to not have inserted something malicious, or even just a mundane and difficult to verify output code bug.
IMHO having a self hosting compiler is fine, but having a bootstrap compiler that can be compiled up from a C toolchain (meaning whatever language its prereq compiler is in, it can be bootstrapped from C, as a lowest common denominator compiler option) Do this and you can verify up to the current compiler version. Claim a user has to just 'trust us' and use a binary bootstrap, because the alternative is compiling 15-30 old revisions to get up to a compiler written in the modern language, and you're just being ludicrious. Rust isn't safe until the compiler can be audited, and even then without a second source compiler, trust issues will remain.
For a real people, "Isis Agora Lovecruft" sure sounds like a fake name.