Memory Safe Languages and Tor
We started this session with one agreement: that we wouldn't spend our time bikeshedding Golang versus Rust. Instead, we focused on two questions:
- What are our goals for migrating the Tor codebase to a memory safe language, and
- How can we accomplish these goals?
Our notes are split along those two categories.
Goals:
- Do no harm (the code that we deploy should not be a liability to the user)
- Have confidence in what is deployed
- Reduce size/memory requirements
- Developer friendliness
- Productivity
- Cross compatibility
- Not adding too much overhead
- 3rd party implementations
- Re-use existing test vectors
- Reproducibility
How:
- Modularity
- Utalizing the test network
- Improving specifications/making editing easier
- Identify incremental steps
- Focus on improving places with attack surfaces
- Reduce inter-module dependencies
- No cgo!
- Split tor and identify communication between
- Don't have parallel implementations
- tor main function implementation (replace libevent)
- Rust capability will be useful for team knowledge while working on Firefox
- Pick one component to experiment with
- Prove how Rust can be integrated into the tor build system
- Further research Rust maturity/portability, overall, whether Rust is a suitible replacement
- Supprot for integration testing
Questions:
- Clean slate versus incremental component migration
Ideas of where to start:
- Directory authority modules
We also discussed third party implementations in languages such as erlang, but decided to focus our discussion on migrating the existing tor codebase. However we identified the need to dramatically improve torspec, in order to enable third parties to implement existing Tor protocols. This will be helpful to test interoperability amongst other benefits.
At the end, Rust was the language most talked about (favorably). We identified the goal of taking next steps to experiement with some of the potential solutions we identified, and report back on what we learned.