Slashdot Mirror
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"
" 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.
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.
With a decent string library and buffer library, the vast majority of security bugs in C are easily fixed.
"First they came for the slanderers and i said nothing."
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).
"First they came for the slanderers and i said nothing."
Well, OpenBSD uses their own set of string libraries. It's a little too limited for my taste, but it works well for them. Microsoft cleaned up a lot of their security problems by disallowing unsafe string functions, and making their own. Again, this is too limited for my taste, but it cleaned up quite a bit.
"First they came for the slanderers and i said nothing."
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.
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 in the same way that contributing to the engineering of a new space vehicle is difficult and subject to understanding a lot of fields, and only available to a handful of specialists, surely there is a factor of capability here.
If they were having problems MANAGING the C code, that's reason enough to move everything to Rust. But having a high barrier of entry because you use C? That just sounds like they're dumbing-down because they're short of contributors - something that I wouldn't want to see in such a project.
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.
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
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.
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
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.
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.
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.
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 not be popular by any metric. It seems that enforced type safety is hostile to novices.
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 something facing the internet like a browser or an anonymizing protocol.
An entire class of problems in C simply don't exist in Rust because it has proper intrinsic types for strings and arrays. Static info is enforced at compile time. The length of strings / arrays is enforced at runtime. Lifetime / borrow checking means you can't inadvertently read or write to garbage either. Rust is no panacea but it shuts down a pile of problems that plague C and C++. It's not hard to see why some people are beginning to advocate its use.
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)"?
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.
Rust compiles to native machine code. Performance is comparable to C or C++.
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 programming. You can use a reference, a bit like in C++ but not a pointer. And the thing you hold a reference to is guaranteed to be there thanks to compiler lifetime checks. In a sense it forces the programmer to think more carefully about who creates and owns objects and their lifetime because they're not going to get past the compiler until they do.
BTW Rust does support pointers and casting but you have to use them from explicit unsafe blocks. So if I absolutely knew some chunk of memory was a kind of type I could force the compiler to trust me. Likewise if I had to talk with a C-library which returned NULL or took NULL as an arg I can do that too. However Rust is safe by default..
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.
'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).
"There are a dozen opinions on a matter until you know the truth. Then there is only one." - CS Lewis (paraprhase)
Try and compile any newly written C code on a platform other than Linux. Chances are it won't work.
Only the State obtains its revenue by coercion. - Murray Rothbard
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.
It's not part of the standard for the same reason hashes and queues are not part of the standard: there are systems where they are not needed, they can easily be acquired where they are needed, and no one wants to add more bloat to the language.
"First they came for the slanderers and i said nothing."
#define Free(m) free(*m); *m = NULL
Or you can make it a function.
"First they came for the slanderers and i said nothing."
There's a really good reason to use C: because it's portable. Not only between systems, but also between languages. If you write a library in C, it can be used from almost any language, and bindings can be generated automatically for all of them. Not so with Python.
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 pile of garbage, and each generation adds more garbage to the pile, as the fans of the language tell you, "Don't use last year's garbage, this standard finally got it right!" No, it still didn't, C++ is still just a bigger pile of garbage. But you know, maybe a few standard's from now it will finally be a good language. What a work in progress.
"First they came for the slanderers and i said nothing."
a design that allows undefined behavior is as dirty as they come.
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
Oh, and you are using that to defend C++? You think C++ doesn't have undefined behavior?
Please, come up with something better.
"First they came for the slanderers and i said nothing."
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.
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.
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
Nah dude, look, almost every language since 1980 has copied C syntax. If it were a bad language, Java wouldn't have copied the syntax.
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.
"First they came for the slanderers and i said nothing."
"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 languages.
Yeah right, it's not a bug, it is a feature. That is a seriously weak excuse.
C# has this specification: "A program that does not contain any occurrences of the unsafe modifier cannot exhibit any undefined behavior."
Java also quite similar in this area (completely defined inside a single thread, multithreading may be non-deterministic).
I develop for embedded systems that are in the field and aren't easily accessible if something goes wrong. Thanks to all those shitty quirks of C I have to program in an overly defensive way.
If I had a say in it, I'd rather develop in Ada, but I haven't, so I had to spend two years converting old C code in modern, readable and much safer C++ code. The application is somewhat slower now, but much more stable and with half the amount of source code.
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
Yeah, I respect your loyalty to Ada, and I'm sorry you can't develop in it. The world would be better if you could.
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 of the language, that is because of you.
"First they came for the slanderers and i said nothing."