#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
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
