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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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:
--------------------------+------------------------------------
Description changed by Sebastian:

Old description:

> Hi there, requesting review and advice for an initial branch to lay some
> groundwork for Rust support in Tor.
>
> 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:
>
> 1) Just commit them along with the Rust 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)
>
> I have no clear preference, as all options have upsides and issues of
> their own. As a data point, the libc crate which we'll definitely depend
> on is 860KB in size (1.3MB uncompressed), the tiny_keccak crate is 40KB
> compressed (80KB uncompressed).
>
> The branch is add_rust in my repo. This branch has been reviewed by komlo
> (thanks!), but more review cannot hurt. It currently does not pass make
> distcheck if Rust is enabled (--enable-rust configure flag) unless the
> dependencies are already in cargo's cache - it is pending a resolution to
> the question above. To try it out yourself, edit out the --frozen
> parameter from the cargo invocation and let it talk to the internet.
> Doing that means make distcheck passes with Rust enabled.
>
> 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.

New description:

 Hi there, requesting review and advice for an initial branch to lay some
 groundwork for Rust support in Tor.

 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:

 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)

 I have no clear preference, as all options have upsides and issues of
 their own. As a data point, the libc crate which we'll definitely depend
 on is 860KB in size (1.3MB uncompressed), the tiny_keccak crate is 40KB
 compressed (80KB uncompressed).

 The branch is add_rust in my repo. This branch has been reviewed by komlo
 (thanks!), but more review cannot hurt. It currently does not pass make
 distcheck if Rust is enabled (--enable-rust configure flag) unless the
 dependencies are already in cargo's cache - it is pending a resolution to
 the question above. To try it out yourself, edit out the --frozen
 parameter from the cargo invocation and let it talk to the internet. Doing
 that means make distcheck passes with Rust enabled.

 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.

--

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22106#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs