Replace tor with Arti

arti is the new, Rust, implementation of little-t-Tor. At the moment of writing, it is not feature complete, but it's clearly the future. We should keep an eye on that, define a roadmap, and inform arti developers about our needs.

While it can run as a daemon, it has great support to run as a library. It means that most applications are encouraged to just embed it, so this is what Tor Browser will do at some point. And maybe C:OnionShare will, too? It will mean that in order for Tor Browser to support the system-wide Tor, there will be very different code paths. Also, the ControlPort as we know is going away. Right now there is no ControlPort like mechanism or specification. nickm told me they are fine with adding one, but don't want to use the old specification, because it's bad in many ways. I could not disagree, even if that will mean rewriting lot of code for us. One proposal is for this controlport mechanism to actually be Tails-specific. This clearly moves some complexity to us, but is not so bad: it would allow us to embed the onion-grater logic right into the controlport server. This discussion was not conclusive. However it goes, it's pretty clear to me that:

  • moving Tails from C-tor to arti would have a high cost. It doesn't need to happen very soon, but still.
  • the fact that other applications will move from the SOCKS5 approach to embed arti as a library will require that somehow (ie: either support upstream, or patch downstream (ie: Tails)) there will be two code paths to support both scenario

Work in progress

Branch: feature/arti

Status:

  • Arti is installed in parallel with tor, simply by fetching a binary from a GitLab pipeline job from Arti's canonical repo.
  • Arti handles all Tor traffic, seems to work fine for everything but we'll know more once the automated test suite can run this branch better.
  • Arti's bootstrapping progress is not yet integrated like tor is with TCA and tails-wait-until-tor-has-bootstrapped.service.
  • Arti is only started through TCA (when choosing "Connect to Tor automatically"), and it cannot configure TCA in any way, e.g. bridges, proxy.
  • Everything depending on the control port is broken since Arti doesn't have one and the RPC mechanism that will replace it lacks most things we need. Currently OnionCircuits shows the (unused) tor circuits, Tor Browser's circuit view shows nothing, and OnionShare is completely broken due to not being able to create onion services.
  • For more missing or broken bits: see "Next steps" below

Next steps

Related

RPC

Tor Browser

Current status

RPC

It's now clear that Arti will have an RPC (actually, it already has one).

Actual procedures

While there is already an RPC, this is providing a very limited number of procedures, see the relevant code. We don't even have a list of what methods will be implemented and when.

Capability-based permission system

It's still not clear whether Arti's RPC will provide a permission system, nor if that permission system will be as fine grained as we need in order to ditch onion-grater. Other applications developed by Tor don't really need it. We don't know if there will be interest for it in the Tor ecosystem but, given the trend towards bundling arti as a library, this might not be the case. Which means that we might need to develop onion-grater-for-arti ourselves

Event loop

The current Python bindings requires its own event loop, because the first RPC API was meant to be used asynchronously. But this will change: there is a Rust API to integrate it better with asynchronous programming. See Release notes, arti#1856, and arti!3644.

Fundraising

https://gitlab.torproject.org/tpo/operations/proposals/-/issues/118

Edited by boyska