C-tor Transition to Arti Policy

Repository of C-tor: https://gitlab.torproject.org/tpo/core/tor

This page details why and how we will start limiting the patches that we accept in our C tor code, as it is slowly deprecated in favor of arti, our Rust reimplementation of the Tor protocols.

That might sound drastic, but there's no need to worry! We're going to do our best to keep the migration easy, and to manage our resources so that all users and relay operators have a reliable code-base that they can use at every stage of the process.

We do apologize for any inconvenience these changes might bring, but they are unfortunately necessary so that our team can focus on producing the best privacy software possible.

Who should care?

This document is particularly relevant if you are:

• A developer integrating with tor.
• A C-tor code contributor

The changes described here won't affect you much yet if you are a user or relay operator.

Why

C in general is old and unsafe, and our C code in particular is old and hard-to-maintain. We find that we are much more productive, safe, and efficient programming in Rust. With this in mind, we've started a Rust implementation of the Tor protocols, arti.

With time, we intend that Arti will be the primary supported implementation of our protocols that we support. We aren't there yet, of course! It will take a fair amount of time before we can declare that Arti is mature enough to replace the old C implementation.

(Why not just support the C implementation forever? That would save everybody the trouble of migrating, but it would come at an unacceptable cost. Maintaining two implementations of all of our protocols would mean that we'd have to make two implementations of every improvement that we make in the future, which would slow down the pace of development when the whole point of moving to Arti is to try to improve that pace.)

Current status

The C Tor code is a huge monolithic code base. That is, every single features we have is packed into one binary: tor. But, our features can be divided into two high level components:

1. Client

• SOCKS Proxy (ex: Tor Browser using tor).
• Onion Services
• Pluggable Transport (client)

2. Relay

• Relays
• Bridges
• Authorities (directory and bridge)
• Pluggable Transport (relay)

Assuming that everything proceeds as planned, and we are able to find funding, Arti is on track to work as a replacement for the Client (1) side of C tor in late 2023. (When it is ready, we will give users plenty of time to upgrade.) We are also seeking funding in order to expand Arti development to implement the Relay (2) component.

Our long-term intent is that Arti will become a complete replacement for the C tor implementation, and eventually replace it entirely. We will continue to support the C tor implementation for a while after Arti is feature-complete, but will eventually end support entirely.

Contributions

Since we are focusing our efforts on Arti, we need to reduce our engineering efforts to the tor.git code base: this will affect our capacity to handle external contributions from our important and beloved contributors.

We want to encourage all contributors to shift their efforts to Arti and avoid seeing their contributions being denied inclusion due to our lack of resources to review and merge. For more information on hacking on Arti, see CONTRIBUTING.md in the source repository.

What is changing now

We are changing what kinds of patches we will accept for C tor, and are writing this to inform the community, so that people don't waste too much time contributing code that we can't accept.

For the client side of tor.git:

• New client features will generally not be accepted.¹
• Only security, stability and regression fixes will be accepted.

On the relay side, we still accept new features for now, but we will start accepting fewer over time. Here are some topics that will likely to be refused (not exhaustive):

• Memory or CPU optimization
• Code cleanup or removal
• Refactoring

The above is, as always, a best effort and the network team might decide, in a specific context, to diverge from the policy. The decision will be made on a case-by-case basis. For example, we'll likely approve nearly any change if it's blocking another Tor Project team.

See a deprecation breakdown draft here

Help

Please, don't hesitate to join our development IRC channel on OFTC, #tor-dev or drop us an email on our development mailing list (tor-dev@lists.torproject.org) in order to seek help with a change you are planning to work on before you start.

We can also help with your work on migrating feature(s) in C-tor to arti.

Control Port

One last word about the Control Port. It is a very vintage protocol and arti is moving towards not re-implementing it—or at most, implementing a subset of it. We don't know yet.

And so, for that reason, we will most likely not accept any control port changes at the moment, except for ones that are absolutely necessary. The Network Team will decide then based on the need, usage, and arguments.

Please note that we're only talking about the control port _protocol. The features available via the control port are not going away but rather will be available with arti as an API or/and some sort of RPC mechanism (still early to tell). This part is still in active design and development phase.

1. ⚠️ We will still allow features or fixes in tor.git if the work is necessary to fulfill a funded grant—for example, if we need to add a feature that requires relay-side support. The grants that Tor Project gets should shift towards Arti in the future. ↩