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
toarti
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
Next steps
-
Inform Arti developers about our needs (#19141 - closed): -
Test Arti in a feature branch