Initial Rust support
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:
- Just commit them along with the Rust and C source code
- 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
- 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.