|
|
# 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](https://arti.torproject.org), 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`](https://arti.torproject.org/).
|
|
|
|
|
|
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`](https://gitlab.torproject.org/tpo/core/arti/-/blob/main/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.[^1]
|
|
|
- **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.
|
|
|
|
|
|
[^1]: :warning: 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.
|
|
|
|
|
|
See a deprecation breakdown draft [here](./DeprecationTorPhases)
|
|
|
|
|
|
### 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](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/control-spec.txt).
|
|
|
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. |