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

[Tor Bug Tracker & Wiki]

#22106: Initial Rust support
--------------------------+------------------------------------
 Reporter:  Sebastian     |          Owner:
     Type:  defect        |         Status:  new
 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 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?
 >
 > 1) Just commit them along with the Rust and C source code
 > 2) Use a separate repository with a git submodule to have them in an
 external repository, but have a somewhat tight coupling as well as a
 consistent path inside the source tree for builds from git/builds from a
 tarball
 > 3) Use a separate repository, no git submodule. Use configure magic to
 ensure we have the dependencies available (either via educated guess next
 to the tor.git repo, via env variable or - if building from a tarball -
 inside the tree)

 Uncertain here... I would go with git submodule (2) before having it
 outside (3), that's for sure but it is my personal preference. We should
 avoid (1) if we can imo (for Rust dependencies ofc), git history is
 important :).

 [snip]

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

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