[tor-bugs] #22106 [Core Tor/Tor]: Initial Rust support

[Tor Bug Tracker & Wiki]

#22106: Initial Rust support
--------------------------+------------------------------------
 Reporter:  Sebastian     |          Owner:
     Type:  defect        |         Status:  needs_revision
 Priority:  Medium        |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by Sebastian):

 Replying to [comment:4 dgoulet]:
 > Replying to [ticket:22106 Sebastian]:
 > > Here's the question: We're preventing cargo from contacting the
 internet during build/tests (and I think we definitely should do that).
 That means we will have to vendor the dependencies we're relying on. I see
 three possible options:
 >
 > Interesting... so Rust is also a thing with a separate "package
 manager". My main worry about this is how we are going to handle security
 updates (or even just updates) with Rust code dependencies shipped with
 Tor. How does that work once we ship a tor and a Rust dependency update is
 needed? We need to make a new stable or we can just tell our operators "$
 rust upgrade" or "$ apt upgrade" (whatever the command) ?
 >
 > More information to understand how that will play out would be
 appreciated because seems whatever option we choose here, we'll have this
 potential problem of doing a new stable release?

 We link Rust statically, any required updates to a shipped library will
 require a rebuild at least. We're intentionally limiting our dependencies
 on external crates dramatically to make this less of a problem, but yes -
 if one of the libraries we ship has a security update, we'll need to ship
 a new version. Note that the same is true for a few C dependencies we ship
 as well. It's annoying, but with the current state of Rust crates in linux
 distributions a different model seems not feasible at all.

 To make it clear: Yes, security updates in Rust dependencies require a new
 stable version.

 > > Once this branch is reviewed, potentially amended and merged, we're
 ready to have two more branches to base on top of this work. A partial
 reimplementation of the protover code, and a complete reimplementation of
 the consdiff code. Both make use of the rust_str_t/RustString API we're
 introducing here. Next up is a document of the "so you want to use Rust
 for Tor hacking?" variety.
 >
 > About this (and taking protover for the sake of the example but it
 applies to the other reimplementation). I strongly believe that we should
 either have Rust code do protover or the C code but not both. Maintaining
 two code base for one single feature won't be fun and adds much more work
 on the maintainer/testing/bugs side of things.
 >
 > IMO, if we embrace Rust for a subsystem, let's go 100% with it and dump
 the C one. Having two implementations for the same thing is not bad as a
 concept but I think it's bad when both are maintained and put in
 production in the same code base. So having a subsystem in Rust thus
 implies that to build/run Tor, Rust is needed, period. I'm aware of the
 transition period between C and Rust making it unavoidable for maintaining
 two code base but that's the price to pay for any scenarios but my point
 is really about not having the C one released once we transition, only
 maintained for LTS.
 >
 > My two cents.

 We're not ready to rely on Rust. This would immediately make Tor
 unbuildable on a bunch of architectures in Debian, for example. This is
 supposed to be an experiment that we can stop if it doesn't work out for
 us, or embrace fully later. We're not planning to perpetually maintain two
 implementations in the same codebase.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22106#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online