8 ms·

The Tor Project is switching to Rust

348 points by giuliomagnifico 11mo ago

epolanski 11mo ago
If Rust helps with their pains and they like Rust this seems very sensible. That'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.
- dingdingdang 11mo ago
  Sensible take, thank you. When HN get these "our project: from x to y language" frontpage stories I am always thinking that it would be far more exciting with "our project: 38.2% smaller code base by optimizing our dependency use", "our project: performance optimized by 16.4% by basic profiler use" or similar!
  - staticassertion 11mo ago
    Isn't this just the same value judgment mistake? You're just presupposing that things like "smaller code base" are better in virtue of themselves the same way that "rewritten in Rust" might be as well. The parent poster's point is seemingly to reject "this is simply the better thing" (ie: "small code is better") and instead to focus on "for what we are doing it is the better thing". Why would "basic" profiler use be better than "niche" or "advanced" profiler use if for that context basic would actually have been inferior (for whatever value of basic we choose to go with)? It seems to me that the reality we're often confronted with is that "better" is contextual, and I would say that "basic" or "smaller" are contextual too.
  - morkalork 11mo ago
    Is the trade off here having more secure code in exchange for added complexity/difficulty? This is a real question, has the Tor code itself been exploited by bad actors before? All the incedences I've seen in the news were some other software running over tor that would be exploited to phone home or give up user data.
    - uecker 11mo ago
      It seems they worry about it, which I can understand. But now with Rust I worry about about new logic bugs, supply chain issues, and lack of proper security updates.
      - steveklabnik 11mo ago
        Well, given that this has been going on for years, you can already start to empirically evaluate that question.
        yjdiquhf 11mo ago
        > (So far, it's a not-very-complete client. But watch this space!)
        steveklabnik 11mo ago
        Yes, it's a beginning not the end. Or, you could look at other projects who have been using Rust for many years, and consider these factors there too. The folks who have have generally concluded the opposite.
        yjdiquhf 11mo ago
        [flagged]
        ue7gjelwjd 11mo ago
        [flagged]
        steveklabnik 11mo ago
        Do you think the sibling comment was flagged to "protect me" whatever that means, or is it because "Are you high on Prozac?" is not really a productive comment? EDIT: And now that I've scrolled down, I see you've left this comment many times as random replies. I'm sure those will get flagged, but for spam reasons, not due to some grand conspiracy.
  - classicasp 11mo ago
    I think the chance that your Rust application is going to be more performant or efficient than C, is whether you are focused on writing performant and efficient code. Out-of-the-box, I’m guessing people will use too many cargo packages, each that are over-engineered or written by less-experienced developers, so it will be less efficient and less performant. In addition, you could more easily inadvertently introduce security problems. Is Rust the right choice for Tor? Sure. Is Tor the right choice for security? If they moved to Rust, they increased security risks to make it easier to manage and find help from younger less-experienced developers, so no.
    - gldrk 11mo ago
      Given how heavily most C programs lean on type erasure vs. monomorphization and how often they reimplement basic data structures, it's kind of a miracle they hold up against Rust/C++.
      - uecker 11mo ago
        Why? Monomorphization often leads to great results in microbenchmarks due to super-specialized code but also to bloat.
    - Yoric 11mo ago
      > I think the chance that your Rust application is going to be more performant or efficient than C, is whether you are focused on writing performant and efficient code. I believe that depends on the sophistication of algorithms. High-level algorithms (especially if they involve concurrency or parallelism) are much easier to write in Rust (or in C++) than in C, which gives them a pretty good chance to be at least as fast as any reasonably safe C implementation. For low-level algorithms, of course, it's really hard to beat polished C code. > Out-of-the-box, I’m guessing people will use too many cargo packages, each that are over-engineered or written by less-experienced developers, so it will be less efficient and less performant. I don't think that this is going to be a problem. The Tor Project developers I've interacted with sounded quite serious about security. Forbidding non-blessed cargo packages is pretty trivial. > In addition, you could more easily inadvertently introduce security problems. What do you mean?
  - bluGill 11mo ago
    Sometimes language is a limiting factor and so you need to change languages before getting better. However this is rare.
- YetAnotherNick 11mo ago
  What are the project specific nuance you are talking about? Anything in this and linked post could be applied to any performant application which values memory safety. So unless they provide some Tor specific nuance, it's more or less applicable to wide range of applications.
- letmetweakit 11mo ago
  Why do you even bring this up, the blog post does not contain this message, they rewrote it to eliminate a class of bugs. They don’t bash C, so refrain yourself from mentioning what hypothetically could have been written…
  - machomaster 11mo ago
    He wrote it because he has eyes and has seen how the typical conversations about switching to Rust often go.
  - LexiMax 11mo ago
    Because Hacker News gamifies engagement, and they know that this kind of message tends to attract a lot of upvotes. The whole conversation tree is a carpet of land-mines, laid out in the hopes that someone steps on one so they can pounce. This sort of gamification of discourse is poison if you actually care about good faith or reasonable discussions. HN is not a good place for either.
- GuB-42 11mo ago
  I hate the "rewrite it in Rust" mentality, however, I think that in this particular case, Rust is the right tool for the job. The Rust specialty is memory safety and performance in an relatively unconstrained environment (usually a PC), with multithreading. Unsurprisingly, because that's how it started, that's what a web browser is. But Tor is also this. Security is extremely important as Tor will be under attack by the most resourceful hackers (state actors, ...), and the typical platform for Tor is a linux multicore PC, not some tiny embedded system or some weird platform, and because it may involve a lot of data and it is latency-sensitive, performance matters. I don't know enough of these projects but I think it could also take another approach and use Zig in the same way Tigerbeetle uses it. But Zig may lack maturity, and it would be a big change. I think it is relevant because Tigerbeetle is all about determinism: do the same thing twice and the memory image should be exactly the same. I think it has value when it comes to security but also fingerprinting resistance, plus, it could open the way for dedicated Tor machines, maybe running some RTOS for even more determinism.
  - hgomersall 11mo ago
    FWIW, rust is great on a tiny embedded system.
    - udhghhe 11mo ago
      But with no_std, Rust is not memory safe, even when not using unsafe. It does have pattern matching and modules, however.
      - estebank 11mo ago
        > But with no_std, Rust is not memory safe, even when not using unsafe. What makes you say that?
        yjdiquhf 11mo ago
        [flagged]
- guywithahat 11mo ago
  I had that thought too; the author claims tor suffers from user free bugs but like, really? A 20 year old code base with a massive supportive following suffers from basic memory issues that can often be caught with linters or dynamic analysis? Surely there are development issues I'm not aware of but I wasn't really sold by the article
  - zelphirkalt 11mo ago
    That can easily happen in C programs. Some edge case doesn't really happen, unless you specifically craft inputs for that, or even sequences of inputs, and simply no one was aware for those 20 years, or no one tried to exploit that specific part of the code. With C you are never safe, unless you somehow proved the code to be free of such bugs.
    - uecker 11mo ago
      This is a bit of an exaggeration. Many types of bugs can also happen with Rust, and with you use unsafe or have some dependency that uses it, then also memory safety bugs. At the same time, it is possible to reduce the probability and impact of such bugs in C code in a reasonable way even without formal verification.
      - estebank 11mo ago
        Does every discussion of Rust and C need this recurring subthread conversation? It is approaching Groundhog Day levels of repetition. Yes, `unsafe` code can have memory safety bugs. Yes, `unsafe` doesn't mean "unsafe". Yes, a sufficiently advanced C-developer can have a sufficiently advanced C-codebase with reduced probability of bugs that might be even better than an insufficiently advanced Rust-developer. Yes, regular safe-Rust isn't the same formal verification. Yes, Rust doesn't catch every bug. On the other hand, most developers have no need of writing `unsafe` Rust. The same tools used for static and dynamic analysis of C codebases are available to Rust (ASAN and friends) and it is a good idea to use them when writing `unsafe` (plus miri). The reason I'm replying is that "the impact of Rust on memory safety" is always a conversation that gets outsized amounts of ink that it drains focus away from other things. I would argue that sum types and exhaustive pattern matching are way more important to minimize logic bugs, even if they aren't enough. You can still have a directory traversal bug letting a remote service write outside of the directory your local service meant to allow. You can still have TOCTOU bugs. You can still have DoS attacks if your codebase doesn't handle all cases carefully. Race conditions can still happen. Specific libraries might be able to protect from some of these, and library reuse increases the likelihood of of these being handled sanely (but doesn't ensure it). Rust doesn't protect against every potential logic error. It never claimed to, and arguing against it is arguing against a strawman. What safe-Rust does claim is no memory safety bugs, no data races, and to provide language and tooling features to model your business logic and deal with complexity.
- concinds 11mo ago
  We could move past all the unproductive, polarized online arguments if everyone accepted that: 1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages. 2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal", is not an un-nuanced argument nor a Rust fanboy argument, but self-evident. That still leaves a lot of room for other languages (Rust is not my favorite language), but it pushes back against the developer equivalent of doctors and pilots resisting the adoption of checklists for decades because "I wouldn't make those kinds of mistakes so stop messing with my work".
  - udhghhe 11mo ago
    Thing is, Rust is not a memory safe programming language. It's not even close to being one. > Diagnosing a Double-Free Concurrency Bug in Rust's Unbounded Channels https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-...
    - deleted 11mo ago
      [deleted]
  - tialaramex 11mo ago
    C++ in particular has a thriving industry of people who'll come teach your team to write "proper" C++. You've probably heard that "It is difficult to get a man to understand something, when his salary depends on his not understanding it" and so of course we shouldn't expect such people to say "Don't write this in C++" when they can instead get paid to teach "How to write this in C++" for 2-3 days and feel like they made the world a better place on top. It so happens Rust is my favourite language, or at least, my favourite general purpose language, but it's also true that I am currently mostly paid to write C# and I see absolutely no reason why I'd say "No, this should be Rust" for most work I do in C#
  - yjftsjthsd-h 11mo ago
    Almost? I'd fully support 1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages. 2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal" but the problem entirely boils down to what comes next: 3a. Therefore everything should use rust. 3b. Therefore everything processing untrusted data where security is an important goal should use rust. (Some folks like to stretch what could possibly process untrusted data to turn this into 3a, but there is a difference.) 3c. Therefore most programs really should be written with a garbage-collector, or if they really need to be low-level or high performance they should use an appropriate stack to avoid gc while remaining safe (whether that's Rust, Ada+SPARK, formally-verified assembly, or whatever).
- amelius 11mo ago
  In this case Rust makes sense. However for the majority of UI projects it doesn't make sense. For UI you want to iterate quickly because requirements change often, and you want garbage collection to be able to move fast. At the same time, performance does not matter (low level stuff like bit blitting can be done by lower level libraries perhaps written in Rust or even at the hardware level). A language designed for systems programming makes zero sense there. Unfortunately, we see a lot of "This UI project now in Rust!" on HN, and people get annoyed by that, and I think rightfully so. People don't want to maintain code that was written in the wrong language, and that __will__ happen if other people pick a language for the wrong reasons.
  - yjdiquhf 11mo ago
    I am confused by this comment on the project page. https://gitlab.torproject.org/tpo/core/arti https://gitlab.torproject.org/tpo/core/arti > (So far, it's a not-very-complete client. But watch this space!) Is that comment outdated? The blog post gave me a different impression. If Arti is not ready yet, shouldn't that have been made clear in the blog post and in the various posts here? Not directing it at you, amelius.
- ls-a 11mo ago
  I think companies hired too many Rust engineers, and now those engineers are writing technical blogs and making product decisions. We're seeing a lot of those everyday on HN first page
jjgreen 11mo ago
Complete rewrites are always a bad idea ... [mutters of agreement] ... except in Rust! [cheering]
- dodomodo 11mo ago
  Comelete rewrite are not always bad, they are _just_ very costly. You just need to do cost benefit analsys and compare it with the cost and benefit of other actions.
- lynndotpy 11mo ago
  Complete rewrites have been done before. They're not impossible tasks. C to C++ (like with fish), C++ to Rust (fish again, Tor, etc), Java to C# (something I've seen), C# to C++ (evernote), Blender Game Engine to Godot (many small cases), Godot to Lumberyard (something I've seen), Unity to Godot (many small cases), etc. And there are all the myriad rewrites within the same language, or across major breaking changes (like Python 2 to Python 3). I think "you should never do a full rewrite" is something of a reactionary response to the juvenile idea new devs and interns get every now and then. But sometimes, a rewrite really is a good idea. But in this case, per the announcement ( https://blog.torproject.org/announcing-arti/ https://blog.torproject.org/announcing-arti/ ), the reasons are pretty convincing. The major reasons are, unsurprisingly, all around memory safety.
  - FieryMechanic 11mo ago
    The issue is that every other week there is a rewrite of something in Rust. I just do an eyeroll whenever I see that yet another thing is being rewritten in Rust. I've tried compiling large projects in Rust in a VM (8GB) and I've run out of memory whereas I am sure a C/C++ large project of a similar size wouldn't run out of memory. A lot of this tooling I had to compile myself because it wasn't available for my Linux distro (Debian 12 at the time). A lot of the tooling reminds me of NPM, and after spending a huge amount of my time fighting with NPM, I actually prefer the way C/C++/CMake handles stuff. I also don't like the language. I do personal stuff in C++ and I found Rust really irritating when learning the language (the return rules are weird) and just gave up with it.
bbcismyfriend 11mo ago
[flagged]
- tw1901375 11mo ago
  It did look like that ever since an NSA critical Tor developer got canceled using the same methods as against Assange. I suppose soon we'll get nsa-leftpad from cargo as a dependency among 347 other packages.
  - flipped 11mo ago
    What was the parent comment?
  - hnthrow82926 11mo ago
    [dead]
shevy-java 11mo ago
Hmmmm. 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.
- ericpauley 11mo ago
  There’s a fundamental trade-off between performance and privacy for onion routing. Much of the slowness you’re experiencing is likely network latency, and no software optimization will improve that.
- dodomodo 11mo ago
  I believe that the slowness is a matter of the amount nodes in the tor network, not something that can be fixed solely by code changes. No one is claiming the new version is faster, only that it is safer.
  - agumonkey 11mo ago
    completely agree but it could be added that a new language can sometimes help explore new ideas faster, in which case maybe the routing layer and protocol can see new optimizations
  - wat10000 11mo ago
    It’s important to remember that safety is the whole purpose of the thing. If Tor is slow, it’s annoying. If Tor is compromised, people get imprisoned or killed.
  - monerozcash 11mo ago
    This is not correct. Tor is generally not bottlenecked by the quantity of available nodes, the usual bottleneck is the quality of nodes picked by your client rather than the quantity of nodes available. Of course, technically, this problem is related to the quantity of high quality nodes :)
    - flipped 11mo ago
nurettin 11mo ago
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.
testdelacc1 11mo ago
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/ 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/CHANGELOG.md 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.
- pityJuke 11mo ago
  Yes, this is a complete exaggeration of a headline and should be flagged for that alone. This has been a long running project, and the Tor team clearly took their time to make it, as opposed to being a spur-of-the-moment change.
  - jfindper 11mo ago
    You're reading way to much into the title. "[...] is switching to [...]" does not have any implication of being a "spur-of-the-moment" thing
- iamnothere 11mo ago
  Arti is also designed to be embedded as a library in other apps, so messaging clients (for example) will be able to leverage the network without needing a correctly configured Tor daemon on the host. The extra safety in the code base is nice, but this seems like a bigger deal.
- jfindper 11mo ago
  >better portability across operating systems Does Rust have better portability than C?
N_Lens 11mo ago
Rust - "I am inevitable"
- fuzzfactor 11mo ago
  Rust never sleeps. N. Young
  - agumonkey 11mo ago
    young and rustless ?
    - machomaster 11mo ago
      Rust in peace
- pdimitar 11mo ago
  "And I... am the Oxidized Man." [snaps fingers]
- marcosdumay 11mo ago
  Unless you use aluminum or stainless steel...
anthk 11mo ago
Why not Go? It's more portable.
- hu3 11mo ago
  and easier to learn. and better funded. and easier to find devs.
  - ramon156 11mo ago
    They both suck getting new devs for Also, just because it's part of Google doesn't make go better funded. Theyd probably be fine killing go. Definitely easier to learn though :P
    - FieryMechanic 11mo ago
      Go been around for quite a while now. It isn't going anywhere.
      - vablings 11mo ago
        Rust has been around for over 10 years now. In the last five years the language hasn't changed much and has gotten better and better
        FieryMechanic 11mo ago
        I didn't like Rust one bit and gave up learning it. Go on the other hand is quite nice.
    - hu3 11mo ago
      > They both suck getting new devs for I'm willing to be Rust suck a ton more to hire devs. Since, as we both agree, Go is easy to learn. Any C#, PHP or Java dev can get going with Go in not time.
  - agumonkey 11mo ago
    i have no dog in the fight, but based on tor release schedule it seems to me that the team is very very talented and rust complexity is not a challenge for them
fithisux 11mo ago
Rust is one of the natural choices for this kind of migration. There are others like Go. I think they made the choice based on ecosystem, performance and prior experience with C.
giancarlostoro 11mo ago
I still wish Mozilla had kept oxidizing Firefox. It would have been a net positive for Rust itself.
- _zagj 11mo ago
  Clearly, the fact that Servo failed must be indicative of shortcomings in Mozilla itself, and not Rust the language, its ecosystem, or its users.
  - johncolanduoni 11mo ago
    Mozilla was the primary steward of Rust for most of the time that the Servo project was active. So if you want to lay Servo’s failure at the feet of the Rust language, it’s pretty hard to cast Mozilla as the blameless victims of… whatever it is that Rust users as a whole did to make Servo fail.
  - psychoslave 11mo ago
    The language surely has many cons, like any language out there. And maybe it wasn't a good fit for Mozilla products. But Mozilla the organisation doesn't really looks that great in term of governance. Given Rust is now even integrated officially in Linux kernel, I have strong doubt that the technical caveats are the main factor of misalignment with Mozilla priorities.
  - WD-42 11mo ago
    Did it fail? The servo project seems alive and well, just not under Mozilla. They decided CEO pay packages were more important.
    - _zagj 11mo ago
      > Did it fail 13 years to get to v0.0.1 is a success? Look at how much progress Ladybird has made in a fraction of that time. Remember that these people are constantly starting rewrites of C and C++ projects (when they're not demanding others do it) in Rust "for safety" (and "oops it's MIT now"), even of ancient Unix utilities with minimal attack surfaces like the "date" command, yet when it comes to a browser rendering engine, which entails computationally-intensive, aggressively-optimized rendering of untrusted input--a massive attack surface, and the very thing for which Rust was supposedly designed--they somehow can't get the right combination of enough Rust zealots (and Adderall) to get past the finish line.
buildbuildbuild 11mo ago
This was mostly funded by Zcash Community Grants. Good things can come from crypto R&D.
- tialaramex 11mo ago
  Pecunia non olet I think perhaps cryptocurrency is worse than selling urine for its chemical properties, but the principle applies, money is just money
ekjhgkejhgk 11mo ago
OT on Tor: 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/ https://coveryourtracks.eff.org/
- 47282847 11mo ago
  Tor Browser tries to widen the fingerprint buckets you can get put into by eg rounding off canvas sizes. The widest bucket and unavoidable is “Tor (browser) user”.
- mawadev 11mo ago
  You can even track people by favicon which bypasses incognito mode. Another part is hiding font urls in css with more tracking...
  - mr_mitm 11mo ago
    Was incognito mode ever meant to prevent tracking? I thought it was for porn, I mean buying surprise presents on a shared computer.
    - sharperguy 11mo ago
      it's commonly used for checking how sites look when not logged in, without logging out, or logging in as another user temporarily.
    - jfindper 11mo ago
      You're correct, incognito mode never has been for privacy protection from websites, ISPs, etc.
  - shlomo_z 11mo ago
    While this was possible in the past, I believe it got patched and is impossible today.
hnthrow82926 11mo ago
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.
- npn 11mo ago
  It is intended. Like any other US gov funded projects.
deleted 11mo ago
[deleted]
linsomniac 11mo ago
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.
- Havoc 11mo ago
  Not to my knowledge. > now I have gigabit You can host torrents to Linux isos to help. You’ll need to block some Chinese ASNs though. They use fake downloaders to detect peers. Like 99% of the traffic my node generated was that. Nodes from one ASN that do partial downloads over and over Else hosting open map data tile server though I gather this can generate a lot of traffic
- ahmibrme 11mo ago
  Tor provides a great blog about running an exit node: https://blog.torproject.org/tips-running-exit-node/ https://blog.torproject.org/tips-running-exit-node/ I remember reading that it’s better to register as an organization if you want to run an exit node. If you want to help the network, you can run relays. That’s much safer. https://community.torproject.org/relay/ https://community.torproject.org/relay/
- throw816593256 11mo ago
  For anyone wondering how else they can help without attracting scrutiny, consider running a bridge. I have done this at home for years and haven't noticed any ill effects like discrimination of my public IPs: https://community.torproject.org/relay/setup/bridge/ https://community.torproject.org/relay/setup/bridge/ Or, if you're OK with a little discrimination (say you're colo hosted, not residential), but still want to avoid exit-relay-level attention, running guard/middle relays is helpful: https://community.torproject.org/relay/types-of-relays/ https://community.torproject.org/relay/types-of-relays/
voidUpdate 11mo ago
Isn't Tor a concept, a protocol? It's like saying you're going to rewrite http in rust...
- kstrauser 11mo ago
  No.
- mmooss 11mo ago
  It's a product. You can download and implement it's many components.
- okanat 11mo ago
  Onion routing is the protocol. Tor is the network and the name of the reference implementation.
runtimepanic 11mo ago
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.
nlitened 11mo ago
They should just start compiling Tor with Fil-C — free memory safety, no new bugs from full code rewrite
- steveklabnik 11mo ago
  This move started before Fil-C existed.
thesnide 11mo ago
i'm starting to wonder what if those rust rewrites might be covert attempt to introduce back doors in plain sight?

348 points by giuliomagnifico 11mo ago

If Rust helps with their pains and they like Rust this seems very sensible. That'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.

dingdingdang 11mo ago
Sensible take, thank you. When HN get these "our project: from x to y language" frontpage stories I am always thinking that it would be far more exciting with "our project: 38.2% smaller code base by optimizing our dependency use", "our project: performance optimized by 16.4% by basic profiler use" or similar!
- staticassertion 11mo ago
  Isn't this just the same value judgment mistake? You're just presupposing that things like "smaller code base" are better in virtue of themselves the same way that "rewritten in Rust" might be as well. The parent poster's point is seemingly to reject "this is simply the better thing" (ie: "small code is better") and instead to focus on "for what we are doing it is the better thing". Why would "basic" profiler use be better than "niche" or "advanced" profiler use if for that context basic would actually have been inferior (for whatever value of basic we choose to go with)? It seems to me that the reality we're often confronted with is that "better" is contextual, and I would say that "basic" or "smaller" are contextual too.
- morkalork 11mo ago
  Is the trade off here having more secure code in exchange for added complexity/difficulty? This is a real question, has the Tor code itself been exploited by bad actors before? All the incedences I've seen in the news were some other software running over tor that would be exploited to phone home or give up user data.
  - uecker 11mo ago
    It seems they worry about it, which I can understand. But now with Rust I worry about about new logic bugs, supply chain issues, and lack of proper security updates.
    - steveklabnik 11mo ago
      Well, given that this has been going on for years, you can already start to empirically evaluate that question.
      - yjdiquhf 11mo ago
        > (So far, it's a not-very-complete client. But watch this space!)
        steveklabnik 11mo ago
        Yes, it's a beginning not the end. Or, you could look at other projects who have been using Rust for many years, and consider these factors there too. The folks who have have generally concluded the opposite.
        yjdiquhf 11mo ago
        [flagged]
        ue7gjelwjd 11mo ago
        [flagged]
        steveklabnik 11mo ago
        Do you think the sibling comment was flagged to "protect me" whatever that means, or is it because "Are you high on Prozac?" is not really a productive comment? EDIT: And now that I've scrolled down, I see you've left this comment many times as random replies. I'm sure those will get flagged, but for spam reasons, not due to some grand conspiracy.
- classicasp 11mo ago
  I think the chance that your Rust application is going to be more performant or efficient than C, is whether you are focused on writing performant and efficient code. Out-of-the-box, I’m guessing people will use too many cargo packages, each that are over-engineered or written by less-experienced developers, so it will be less efficient and less performant. In addition, you could more easily inadvertently introduce security problems. Is Rust the right choice for Tor? Sure. Is Tor the right choice for security? If they moved to Rust, they increased security risks to make it easier to manage and find help from younger less-experienced developers, so no.
  - gldrk 11mo ago
    Given how heavily most C programs lean on type erasure vs. monomorphization and how often they reimplement basic data structures, it's kind of a miracle they hold up against Rust/C++.
    - uecker 11mo ago
      Why? Monomorphization often leads to great results in microbenchmarks due to super-specialized code but also to bloat.
  - Yoric 11mo ago
    > I think the chance that your Rust application is going to be more performant or efficient than C, is whether you are focused on writing performant and efficient code. I believe that depends on the sophistication of algorithms. High-level algorithms (especially if they involve concurrency or parallelism) are much easier to write in Rust (or in C++) than in C, which gives them a pretty good chance to be at least as fast as any reasonably safe C implementation. For low-level algorithms, of course, it's really hard to beat polished C code. > Out-of-the-box, I’m guessing people will use too many cargo packages, each that are over-engineered or written by less-experienced developers, so it will be less efficient and less performant. I don't think that this is going to be a problem. The Tor Project developers I've interacted with sounded quite serious about security. Forbidding non-blessed cargo packages is pretty trivial. > In addition, you could more easily inadvertently introduce security problems. What do you mean?
- bluGill 11mo ago
  Sometimes language is a limiting factor and so you need to change languages before getting better. However this is rare.
YetAnotherNick 11mo ago
What are the project specific nuance you are talking about? Anything in this and linked post could be applied to any performant application which values memory safety. So unless they provide some Tor specific nuance, it's more or less applicable to wide range of applications.
letmetweakit 11mo ago
Why do you even bring this up, the blog post does not contain this message, they rewrote it to eliminate a class of bugs. They don’t bash C, so refrain yourself from mentioning what hypothetically could have been written…
- machomaster 11mo ago
  He wrote it because he has eyes and has seen how the typical conversations about switching to Rust often go.
- LexiMax 11mo ago
  Because Hacker News gamifies engagement, and they know that this kind of message tends to attract a lot of upvotes. The whole conversation tree is a carpet of land-mines, laid out in the hopes that someone steps on one so they can pounce. This sort of gamification of discourse is poison if you actually care about good faith or reasonable discussions. HN is not a good place for either.
GuB-42 11mo ago
I hate the "rewrite it in Rust" mentality, however, I think that in this particular case, Rust is the right tool for the job. The Rust specialty is memory safety and performance in an relatively unconstrained environment (usually a PC), with multithreading. Unsurprisingly, because that's how it started, that's what a web browser is. But Tor is also this. Security is extremely important as Tor will be under attack by the most resourceful hackers (state actors, ...), and the typical platform for Tor is a linux multicore PC, not some tiny embedded system or some weird platform, and because it may involve a lot of data and it is latency-sensitive, performance matters. I don't know enough of these projects but I think it could also take another approach and use Zig in the same way Tigerbeetle uses it. But Zig may lack maturity, and it would be a big change. I think it is relevant because Tigerbeetle is all about determinism: do the same thing twice and the memory image should be exactly the same. I think it has value when it comes to security but also fingerprinting resistance, plus, it could open the way for dedicated Tor machines, maybe running some RTOS for even more determinism.
- hgomersall 11mo ago
  FWIW, rust is great on a tiny embedded system.
  - udhghhe 11mo ago
    But with no_std, Rust is not memory safe, even when not using unsafe. It does have pattern matching and modules, however.
    - estebank 11mo ago
      > But with no_std, Rust is not memory safe, even when not using unsafe. What makes you say that?
      - yjdiquhf 11mo ago
        [flagged]
guywithahat 11mo ago
I had that thought too; the author claims tor suffers from user free bugs but like, really? A 20 year old code base with a massive supportive following suffers from basic memory issues that can often be caught with linters or dynamic analysis? Surely there are development issues I'm not aware of but I wasn't really sold by the article
- zelphirkalt 11mo ago
  That can easily happen in C programs. Some edge case doesn't really happen, unless you specifically craft inputs for that, or even sequences of inputs, and simply no one was aware for those 20 years, or no one tried to exploit that specific part of the code. With C you are never safe, unless you somehow proved the code to be free of such bugs.
  - uecker 11mo ago
    This is a bit of an exaggeration. Many types of bugs can also happen with Rust, and with you use unsafe or have some dependency that uses it, then also memory safety bugs. At the same time, it is possible to reduce the probability and impact of such bugs in C code in a reasonable way even without formal verification.
    - estebank 11mo ago
      Does every discussion of Rust and C need this recurring subthread conversation? It is approaching Groundhog Day levels of repetition. Yes, `unsafe` code can have memory safety bugs. Yes, `unsafe` doesn't mean "unsafe". Yes, a sufficiently advanced C-developer can have a sufficiently advanced C-codebase with reduced probability of bugs that might be even better than an insufficiently advanced Rust-developer. Yes, regular safe-Rust isn't the same formal verification. Yes, Rust doesn't catch every bug. On the other hand, most developers have no need of writing `unsafe` Rust. The same tools used for static and dynamic analysis of C codebases are available to Rust (ASAN and friends) and it is a good idea to use them when writing `unsafe` (plus miri). The reason I'm replying is that "the impact of Rust on memory safety" is always a conversation that gets outsized amounts of ink that it drains focus away from other things. I would argue that sum types and exhaustive pattern matching are way more important to minimize logic bugs, even if they aren't enough. You can still have a directory traversal bug letting a remote service write outside of the directory your local service meant to allow. You can still have TOCTOU bugs. You can still have DoS attacks if your codebase doesn't handle all cases carefully. Race conditions can still happen. Specific libraries might be able to protect from some of these, and library reuse increases the likelihood of of these being handled sanely (but doesn't ensure it). Rust doesn't protect against every potential logic error. It never claimed to, and arguing against it is arguing against a strawman. What safe-Rust does claim is no memory safety bugs, no data races, and to provide language and tooling features to model your business logic and deal with complexity.
concinds 11mo ago
We could move past all the unproductive, polarized online arguments if everyone accepted that: 1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages. 2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal", is not an un-nuanced argument nor a Rust fanboy argument, but self-evident. That still leaves a lot of room for other languages (Rust is not my favorite language), but it pushes back against the developer equivalent of doctors and pilots resisting the adoption of checklists for decades because "I wouldn't make those kinds of mistakes so stop messing with my work".
- udhghhe 11mo ago
  Thing is, Rust is not a memory safe programming language. It's not even close to being one. > Diagnosing a Double-Free Concurrency Bug in Rust's Unbounded Channels https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-...
  - deleted 11mo ago
    [deleted]
- tialaramex 11mo ago
  C++ in particular has a thriving industry of people who'll come teach your team to write "proper" C++. You've probably heard that "It is difficult to get a man to understand something, when his salary depends on his not understanding it" and so of course we shouldn't expect such people to say "Don't write this in C++" when they can instead get paid to teach "How to write this in C++" for 2-3 days and feel like they made the world a better place on top. It so happens Rust is my favourite language, or at least, my favourite general purpose language, but it's also true that I am currently mostly paid to write C# and I see absolutely no reason why I'd say "No, this should be Rust" for most work I do in C#
- yjftsjthsd-h 11mo ago
  Almost? I'd fully support 1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages. 2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal" but the problem entirely boils down to what comes next: 3a. Therefore everything should use rust. 3b. Therefore everything processing untrusted data where security is an important goal should use rust. (Some folks like to stretch what could possibly process untrusted data to turn this into 3a, but there is a difference.) 3c. Therefore most programs really should be written with a garbage-collector, or if they really need to be low-level or high performance they should use an appropriate stack to avoid gc while remaining safe (whether that's Rust, Ada+SPARK, formally-verified assembly, or whatever).
amelius 11mo ago
In this case Rust makes sense. However for the majority of UI projects it doesn't make sense. For UI you want to iterate quickly because requirements change often, and you want garbage collection to be able to move fast. At the same time, performance does not matter (low level stuff like bit blitting can be done by lower level libraries perhaps written in Rust or even at the hardware level). A language designed for systems programming makes zero sense there. Unfortunately, we see a lot of "This UI project now in Rust!" on HN, and people get annoyed by that, and I think rightfully so. People don't want to maintain code that was written in the wrong language, and that __will__ happen if other people pick a language for the wrong reasons.
- yjdiquhf 11mo ago
  I am confused by this comment on the project page. https://gitlab.torproject.org/tpo/core/arti https://gitlab.torproject.org/tpo/core/arti > (So far, it's a not-very-complete client. But watch this space!) Is that comment outdated? The blog post gave me a different impression. If Arti is not ready yet, shouldn't that have been made clear in the blog post and in the various posts here? Not directing it at you, amelius.
ls-a 11mo ago
I think companies hired too many Rust engineers, and now those engineers are writing technical blogs and making product decisions. We're seeing a lot of those everyday on HN first page

jjgreen 11mo ago

Complete rewrites are always a bad idea ... [mutters of agreement] ... except in Rust! [cheering]

dodomodo 11mo ago
Comelete rewrite are not always bad, they are _just_ very costly. You just need to do cost benefit analsys and compare it with the cost and benefit of other actions.
lynndotpy 11mo ago
Complete rewrites have been done before. They're not impossible tasks. C to C++ (like with fish), C++ to Rust (fish again, Tor, etc), Java to C# (something I've seen), C# to C++ (evernote), Blender Game Engine to Godot (many small cases), Godot to Lumberyard (something I've seen), Unity to Godot (many small cases), etc. And there are all the myriad rewrites within the same language, or across major breaking changes (like Python 2 to Python 3). I think "you should never do a full rewrite" is something of a reactionary response to the juvenile idea new devs and interns get every now and then. But sometimes, a rewrite really is a good idea. But in this case, per the announcement ( https://blog.torproject.org/announcing-arti/ https://blog.torproject.org/announcing-arti/ ), the reasons are pretty convincing. The major reasons are, unsurprisingly, all around memory safety.
- FieryMechanic 11mo ago
  The issue is that every other week there is a rewrite of something in Rust. I just do an eyeroll whenever I see that yet another thing is being rewritten in Rust. I've tried compiling large projects in Rust in a VM (8GB) and I've run out of memory whereas I am sure a C/C++ large project of a similar size wouldn't run out of memory. A lot of this tooling I had to compile myself because it wasn't available for my Linux distro (Debian 12 at the time). A lot of the tooling reminds me of NPM, and after spending a huge amount of my time fighting with NPM, I actually prefer the way C/C++/CMake handles stuff. I also don't like the language. I do personal stuff in C++ and I found Rust really irritating when learning the language (the return rules are weird) and just gave up with it.

bbcismyfriend 11mo ago

[flagged]

tw1901375 11mo ago
It did look like that ever since an NSA critical Tor developer got canceled using the same methods as against Assange. I suppose soon we'll get nsa-leftpad from cargo as a dependency among 347 other packages.
- flipped 11mo ago
  What was the parent comment?
- hnthrow82926 11mo ago
  [dead]

shevy-java 11mo ago

Hmmmm. 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.

ericpauley 11mo ago
There’s a fundamental trade-off between performance and privacy for onion routing. Much of the slowness you’re experiencing is likely network latency, and no software optimization will improve that.
dodomodo 11mo ago
I believe that the slowness is a matter of the amount nodes in the tor network, not something that can be fixed solely by code changes. No one is claiming the new version is faster, only that it is safer.
- agumonkey 11mo ago
  completely agree but it could be added that a new language can sometimes help explore new ideas faster, in which case maybe the routing layer and protocol can see new optimizations
- wat10000 11mo ago
  It’s important to remember that safety is the whole purpose of the thing. If Tor is slow, it’s annoying. If Tor is compromised, people get imprisoned or killed.
- monerozcash 11mo ago
  This is not correct. Tor is generally not bottlenecked by the quantity of available nodes, the usual bottleneck is the quality of nodes picked by your client rather than the quantity of nodes available. Of course, technically, this problem is related to the quantity of high quality nodes :)
  - flipped 11mo ago

nurettin 11mo ago

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.

testdelacc1 11mo ago

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/ 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/CHANGELOG.md 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.

pityJuke 11mo ago
Yes, this is a complete exaggeration of a headline and should be flagged for that alone. This has been a long running project, and the Tor team clearly took their time to make it, as opposed to being a spur-of-the-moment change.
- jfindper 11mo ago
  You're reading way to much into the title. "[...] is switching to [...]" does not have any implication of being a "spur-of-the-moment" thing
iamnothere 11mo ago
Arti is also designed to be embedded as a library in other apps, so messaging clients (for example) will be able to leverage the network without needing a correctly configured Tor daemon on the host. The extra safety in the code base is nice, but this seems like a bigger deal.
jfindper 11mo ago
>better portability across operating systems Does Rust have better portability than C?

N_Lens 11mo ago

Rust - "I am inevitable"

fuzzfactor 11mo ago
Rust never sleeps. N. Young
- agumonkey 11mo ago
  young and rustless ?
  - machomaster 11mo ago
    Rust in peace
pdimitar 11mo ago
"And I... am the Oxidized Man." [snaps fingers]
marcosdumay 11mo ago
Unless you use aluminum or stainless steel...

anthk 11mo ago

Why not Go? It's more portable.

hu3 11mo ago
and easier to learn. and better funded. and easier to find devs.
- ramon156 11mo ago
  They both suck getting new devs for Also, just because it's part of Google doesn't make go better funded. Theyd probably be fine killing go. Definitely easier to learn though :P
  - FieryMechanic 11mo ago
    Go been around for quite a while now. It isn't going anywhere.
    - vablings 11mo ago
      Rust has been around for over 10 years now. In the last five years the language hasn't changed much and has gotten better and better
      - FieryMechanic 11mo ago
        I didn't like Rust one bit and gave up learning it. Go on the other hand is quite nice.
  - hu3 11mo ago
    > They both suck getting new devs for I'm willing to be Rust suck a ton more to hire devs. Since, as we both agree, Go is easy to learn. Any C#, PHP or Java dev can get going with Go in not time.
- agumonkey 11mo ago
  i have no dog in the fight, but based on tor release schedule it seems to me that the team is very very talented and rust complexity is not a challenge for them

fithisux 11mo ago

Rust is one of the natural choices for this kind of migration. There are others like Go. I think they made the choice based on ecosystem, performance and prior experience with C.

giancarlostoro 11mo ago

I still wish Mozilla had kept oxidizing Firefox. It would have been a net positive for Rust itself.

_zagj 11mo ago
Clearly, the fact that Servo failed must be indicative of shortcomings in Mozilla itself, and not Rust the language, its ecosystem, or its users.
- johncolanduoni 11mo ago
  Mozilla was the primary steward of Rust for most of the time that the Servo project was active. So if you want to lay Servo’s failure at the feet of the Rust language, it’s pretty hard to cast Mozilla as the blameless victims of… whatever it is that Rust users as a whole did to make Servo fail.
- psychoslave 11mo ago
  The language surely has many cons, like any language out there. And maybe it wasn't a good fit for Mozilla products. But Mozilla the organisation doesn't really looks that great in term of governance. Given Rust is now even integrated officially in Linux kernel, I have strong doubt that the technical caveats are the main factor of misalignment with Mozilla priorities.
- WD-42 11mo ago
  Did it fail? The servo project seems alive and well, just not under Mozilla. They decided CEO pay packages were more important.
  - _zagj 11mo ago
    > Did it fail 13 years to get to v0.0.1 is a success? Look at how much progress Ladybird has made in a fraction of that time. Remember that these people are constantly starting rewrites of C and C++ projects (when they're not demanding others do it) in Rust "for safety" (and "oops it's MIT now"), even of ancient Unix utilities with minimal attack surfaces like the "date" command, yet when it comes to a browser rendering engine, which entails computationally-intensive, aggressively-optimized rendering of untrusted input--a massive attack surface, and the very thing for which Rust was supposedly designed--they somehow can't get the right combination of enough Rust zealots (and Adderall) to get past the finish line.

buildbuildbuild 11mo ago

This was mostly funded by Zcash Community Grants. Good things can come from crypto R&D.

tialaramex 11mo ago
Pecunia non olet I think perhaps cryptocurrency is worse than selling urine for its chemical properties, but the principle applies, money is just money

ekjhgkejhgk 11mo ago

OT on Tor: 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/ https://coveryourtracks.eff.org/

47282847 11mo ago
Tor Browser tries to widen the fingerprint buckets you can get put into by eg rounding off canvas sizes. The widest bucket and unavoidable is “Tor (browser) user”.
mawadev 11mo ago
You can even track people by favicon which bypasses incognito mode. Another part is hiding font urls in css with more tracking...
- mr_mitm 11mo ago
  Was incognito mode ever meant to prevent tracking? I thought it was for porn, I mean buying surprise presents on a shared computer.
  - sharperguy 11mo ago
    it's commonly used for checking how sites look when not logged in, without logging out, or logging in as another user temporarily.
  - jfindper 11mo ago
    You're correct, incognito mode never has been for privacy protection from websites, ISPs, etc.
- shlomo_z 11mo ago
  While this was possible in the past, I believe it got patched and is impossible today.

hnthrow82926 11mo ago

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.

npn 11mo ago
It is intended. Like any other US gov funded projects.

deleted 11mo ago

[deleted]

linsomniac 11mo ago

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.

Havoc 11mo ago
Not to my knowledge. > now I have gigabit You can host torrents to Linux isos to help. You’ll need to block some Chinese ASNs though. They use fake downloaders to detect peers. Like 99% of the traffic my node generated was that. Nodes from one ASN that do partial downloads over and over Else hosting open map data tile server though I gather this can generate a lot of traffic
ahmibrme 11mo ago
Tor provides a great blog about running an exit node: https://blog.torproject.org/tips-running-exit-node/ https://blog.torproject.org/tips-running-exit-node/ I remember reading that it’s better to register as an organization if you want to run an exit node. If you want to help the network, you can run relays. That’s much safer. https://community.torproject.org/relay/ https://community.torproject.org/relay/
throw816593256 11mo ago
For anyone wondering how else they can help without attracting scrutiny, consider running a bridge. I have done this at home for years and haven't noticed any ill effects like discrimination of my public IPs: https://community.torproject.org/relay/setup/bridge/ https://community.torproject.org/relay/setup/bridge/ Or, if you're OK with a little discrimination (say you're colo hosted, not residential), but still want to avoid exit-relay-level attention, running guard/middle relays is helpful: https://community.torproject.org/relay/types-of-relays/ https://community.torproject.org/relay/types-of-relays/

voidUpdate 11mo ago

Isn't Tor a concept, a protocol? It's like saying you're going to rewrite http in rust...

kstrauser 11mo ago
No.
mmooss 11mo ago
It's a product. You can download and implement it's many components.
okanat 11mo ago
Onion routing is the protocol. Tor is the network and the name of the reference implementation.

runtimepanic 11mo ago

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.

nlitened 11mo ago

They should just start compiling Tor with Fil-C — free memory safety, no new bugs from full code rewrite

steveklabnik 11mo ago
This move started before Fil-C existed.

thesnide 11mo ago

i'm starting to wonder what if those rust rewrites might be covert attempt to introduce back doors in plain sight?