Arti 2.3.0 pushes Tor’s Rust rewrite deeper

What changed in Arti 2.3.0#

The Tor Project has released Arti 2.3.0, the latest version of its Rust-based implementation of Tor.

Arti is not just a client rewrite. It is Tor’s long-running effort to build a next-generation implementation in Rust, with the goal of covering more of the roles that the existing Tor network depends on. This release continues work in that direction. The project says Arti 2.3.0 advances development toward using Arti as a relay and as a directory authority, while also continuing work on RPC.

The release is not presented as a dramatic user-facing security fix. It is an infrastructure release. That still matters. Tor is a trust and routing system with many moving parts. Client behavior, relay behavior, directory authority behavior, diagnostics, logging, and APIs all shape whether the software can be operated safely at scale.

The headline changes in Arti 2.3.0 are:

• the minimum supported macOS version is now 10.14, up from 10.12
• continued development toward relay support
• continued development toward directory authority support
• continued RPC work, including a new API for inspecting tunnel paths
• new logging support, including syslog support when enabled
• a new logging.protocol_warnings option for logging protocol violations as warnings
• cleanup, testing, infrastructure, documentation, and smaller bug fixes

The Tor Project points readers to the full changelog for complete API changes and lower-visibility updates.

Why the macOS support change matters#

Arti 2.3.0 raises the minimum supported macOS version from 10.12 to 10.14.

That is a technical support change, but the project also gives a security caveat: even if older macOS versions were supported at some level before, the Tor Project does not recommend using macOS versions that no longer receive Apple updates. Those systems may carry unpatched security issues.

That distinction is important. A privacy tool does not erase the risk of a stale operating system. Tor can protect network-layer privacy in specific ways, but it cannot make an unsupported OS safe. If the host is compromised, the transport layer is no longer the main problem.

For users, the practical point is simple: if you are running Arti on macOS, check the OS version before upgrading. If the system is older than macOS 10.14, this release is outside the new minimum. If it is only barely inside the supported range, the stronger question is whether that machine should be used for sensitive work at all.

RPC and tunnel path inspection#

One notable development area is RPC. Arti 2.3.0 adds a new RPC API for inspecting tunnel paths.

The source does not frame this as a consumer privacy feature or a finished operational control plane. It says RPC development continues and names tunnel path inspection as a new API capability.

That is still useful. Tor circuits and tunnel paths are core to how the network works. Operators, developers, and tooling authors often need visibility into what the software is doing without relying on brittle logs or ad hoc inspection. A formal RPC API can make that visibility cleaner, easier to automate, and less dependent on scraping internal behavior.

There is also a trust boundary here. Any interface that exposes internal network state needs careful handling. The release note does not describe the security model of the new API in detail, so it would be wrong to infer too much from the announcement alone. The safe reading is narrower: Arti is gaining more structured introspection capabilities as its RPC layer develops.

For developers building around Arti, this is a signal to watch the API surface closely. RPC is where future management, diagnostics, and automation may become easier. It is also where breaking changes can matter if tooling starts to depend on early behavior.

Relay and directory authority work is the long game#

The release continues development toward using Arti as a relay and as a directory authority.

That matters because Tor is not only a client application. The public Tor network depends on relays and directory authorities. Relays move traffic. Directory authorities help maintain the consensus documents that clients use to understand the network.

A Rust implementation that can eventually cover these roles would be more than a language migration. It would affect maintenance, memory-safety assumptions, deployment paths, and the future operational shape of the Tor ecosystem.

But the wording matters. The Tor Project says development is continuing toward those uses. It does not say Arti has replaced the existing implementation for those roles in production. It does not say operators should migrate relays or authorities based only on this release note.

The correct reading is incremental: Arti is moving further into the parts of Tor that require deeper network participation. That is significant, but it is not the same as a final migration announcement.

Logging gets more operator-friendly#

Arti 2.3.0 adds two logging-related features.

First, Arti can now log to syslog when the relevant feature is enabled and the config option is enabled. For operators, this matters because syslog is a standard destination in many Unix-like environments. It makes Arti easier to integrate with existing monitoring, log rotation, and incident review workflows.

Second, the release adds a logging.protocol_warnings option to log protocol violations as warnings.

That is a small line with practical value. Protocol violations can be noise, signal, or both. Logging them as warnings gives operators and developers another way to observe abnormal behavior without necessarily treating every event as a fatal condition. It can help with debugging, compatibility work, and spotting strange network behavior.

As always, logging needs discipline. More visibility can help operations. It can also create sensitive records if logs are retained too broadly or collected in the wrong place. Anyone operating privacy infrastructure should treat logs as part of the threat model, not as harmless exhaust.

A coming breaking change for crate users#

The release note also warns crate users about a planned breaking change in the release after this one. The scraped source text is incomplete around the exact crate and semantics involved, but the important part is clear: the Tor Project is giving advance notice that an implicit behavior is expected to become explicit in the next release.

That should put downstream developers on alert.

If you maintain software that depends on Arti crates, do not treat 2.3.0 as a passive upgrade only. Read the upstream changelog and API notes directly. Look for deprecations, changed defaults, feature flags, and migration guidance. If the planned change affects your use case, the project is asking for feedback before it lands.

This is one of the more important operational habits around fast-moving infrastructure libraries: warnings in release notes are part of the compatibility contract. Ignore them and the next upgrade becomes more expensive.

What not to overclaim#

There are a few things this release note does not say.

It does not claim that Arti 2.3.0 is a complete replacement for all Tor roles. It does not announce a new censorship-circumvention breakthrough. It does not describe a specific vulnerability fix. It does not provide numbers for performance, adoption, relay readiness, or RPC stability in the material provided.

The useful claim is narrower and stronger: Arti is maturing across the surfaces that matter for a full Tor implementation. That includes operator logging, RPC introspection, relay work, directory authority work, platform support boundaries, and API cleanup.

For users, this release is mostly about keeping current and understanding platform support. For developers and operators, it is a marker in the longer Arti transition.

Practical takeaways#

If you use Arti directly:

• check that your macOS version is 10.14 or newer
• avoid using unsupported macOS versions for sensitive work, even if software still runs
• read the full changelog before upgrading production workflows

If you build against Arti crates:

• review API changes in the release notes
• watch the planned breaking change for the next release
• test against 2.3.0 early if your tooling depends on logging or RPC behavior

If you operate privacy infrastructure:

• evaluate syslog support against your existing logging policy
• avoid retaining logs longer than needed
• treat protocol-warning logs as useful diagnostics, not automatic proof of attack

Arti 2.3.0 is not a loud release. It is the kind of release that moves a critical system closer to being operable, inspectable, and maintainable in more roles. For Tor, that is the work that matters.