I think we will see more Rust adoption as code generation gets better.
Machines will generate all the code, test that it works according to spec, you only need a vague notion of what is succint (do you just implement some existing trait?), what is typical (do you use index based data structures? do you simply use a Box, do you need Rc? Where should you use Optional?, do you want to use RefCell to make it mutable and so on), what is concise (just macro expand?), what is the correct type to use so you can warn the machine to re-adjust itself.
Personally I don't use Rust, I don't want to learn everything about Rust. It is the new enterprise Java boilerplate BS of our time.
So instead of running people through that ordeal, let them write the specs and machines should write the verbose boilerplate so the code is so called "safe" and concise without giving up too much.
This isn’t a recent decision, which the title implies. This rewrite started in 2020, and they released Arti 1.0 in 2022. Check out the release post (https://blog.torproject.org/arti_100_released/) where they explain their rationale for the rewrite. They were unhappy with the state of the C codebase and couldn’t see a way to slowly refactor it. Their experience with Rust was positive for all the commonly cited reasons - if it compiles it works, good ecosystem leading to development velocity, better portability across operating systems, and attracting more contributors. They did say they weren’t happy at the time with binary sizes.
The change log in the arti repo (https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CHAN...) shows a lot of recent development too- versions 1.6, 1.7 and 1.8 were released in the last 3 months and they talk about setting the foundations for larger features to come. All in all it seems like the decision worked out for the team.
This is legit question, especially for Tor binaries.
Advantage of Rust (or original C implementation) is for users that do not have runtime and want to import Tor libraries (like arti-client) in their code. Go could work but those unmanaged languages are better here. So in the end Rust (or C, C++ etc.) can serve more user-cases.
Recently this link was on HN[1]. It ranks your browser on regular tracking and fingerprinting separately. "Tor without JS" was the only option I found to be completely fingerprint resistant. Even Tor "with JS on strict settings" ranked it as only "partly fingerprint resistant". (Interestingly firefox without JS never returns)
Scary stuff.
I'd like to hear other people's experiences/experiments here.
I'm sure replacing the battle-tested C implementation with a Rust implementation that's extremely vulnerable to supply-chain attacks and has seen little real-world usage is not going to backfire at all.
Is there any way to run a Tor exit node without expecting to get a knock on the door from the FBI/DHS? Like advertising as an exit node but only to a whitelist of sites? For ~20 years I ran a dozen cabinet at a colo but never felt I could donate bandwidth to Tor because of that (did a big mirror server instead), and now I have gigabit (could be 10gig) at home, but still just don't want to deal with the issues.
Rust adoption in privacy tooling always feels like watching an old fortress quietly replace its wooden beams with steel ones. Tor’s codebase has carried decades of security assumptions, C-era tradeoffs and performance scars, so a gradual Rustification seems like the most sensible way to buy safety without breaking the ecosystem.
The real win isn’t “rewrite everything” but reducing the surface area where memory-unsafety bugs can even exist. If the team can shift the high-risk subsystems (parsing, crypto glue, protocol edges) into Rust while keeping well-tested C where it’s stable, Tor ends up with a sturdier core without a multi-year rewrite freeze.
The interesting question is how far they’ll push it:
Will future pluggable transports be Rust-first?
Will relay operators eventually run a hybrid runtime?
Or does this turn into a long coexistence phase like Firefox?
Either way, a safer Tor is a good Tor.
21 comments
[ 3.0 ms ] story [ 54.1 ms ] threadThat's exactly why we have different languages and tools, because they adapt differently to different projects, teams and problems.
But as soon as you get into the silly "tool X is better period" arguments, then all the nuance of choosing the right tool for the job is lost.
My biggest gripe with the Tor project is that it is so slow.
I don't think merely moving to Rust makes Tor faster either. And I am also not entirely convinced that Rust is really better than C.
Machines will generate all the code, test that it works according to spec, you only need a vague notion of what is succint (do you just implement some existing trait?), what is typical (do you use index based data structures? do you simply use a Box, do you need Rc? Where should you use Optional?, do you want to use RefCell to make it mutable and so on), what is concise (just macro expand?), what is the correct type to use so you can warn the machine to re-adjust itself.
Personally I don't use Rust, I don't want to learn everything about Rust. It is the new enterprise Java boilerplate BS of our time.
So instead of running people through that ordeal, let them write the specs and machines should write the verbose boilerplate so the code is so called "safe" and concise without giving up too much.
The change log in the arti repo (https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CHAN...) shows a lot of recent development too- versions 1.6, 1.7 and 1.8 were released in the last 3 months and they talk about setting the foundations for larger features to come. All in all it seems like the decision worked out for the team.
- better data race handling;
- no garbage collection, more predictable performance;
- stricter type system that can enforce constraints better;
- closer to metal and better FFI support.
Which seems to matter more for Tor project than support for some barely used platform.
Advantage of Rust (or original C implementation) is for users that do not have runtime and want to import Tor libraries (like arti-client) in their code. Go could work but those unmanaged languages are better here. So in the end Rust (or C, C++ etc.) can serve more user-cases.
There are others like Go.
I think they made the choice based on ecosystem, performance and prior experience with C.
Recently this link was on HN[1]. It ranks your browser on regular tracking and fingerprinting separately. "Tor without JS" was the only option I found to be completely fingerprint resistant. Even Tor "with JS on strict settings" ranked it as only "partly fingerprint resistant". (Interestingly firefox without JS never returns)
Scary stuff.
I'd like to hear other people's experiences/experiments here.
[1] https://coveryourtracks.eff.org/