Skip to content

Recommended Tor versions policy

Recommending or not recommending Tor versions is foremost a mechanism to convey to relay operators and users whether they run a supported Tor version or not: if they run a not recommended one they'll just get a notification in their Tor logs saying so. This policy lays out the expectations behind recommending and removing recommended Tor versions as done by the Directory Authorities and other involved parties.

Recommending a Tor version

Recommending a Tor version is needed in case a new one is about to get released. The network team is the driver behind Tor releases and recommending new Tor versions is part of their release process. The recommendation is committed to the dir-auth Gitlab repository by the network-team as soon as a new Tor version (be it a stable or unstable one) is scheduled for release. The goal is to have this new Tor version recommended in the network before the actual release is getting picked up by relay operators or users.

Removing a recommended Tor version comes with trying to balance different goals. There is genuine worth in requiring users and relay operators not to upgrade too often while on the other hand it's beneficial for overall maintenance purposes and network-wide feature roll-out to always recommend just a small number of Tor versions.

The Directory Authorities, with the help of the network-health and community teams, will try to balance the aforementioned goals and remove recommended Tor versions in case:

  • they no longer conform to the specification. That is, if they wouldn't actually interact correctly with the current Tor network.
  • they harm the performance or stability of the current Tor network or the anonymity of users. For example, a version that load balances wrong, or a version that hammers the authorities too much.
  • they have known security problems (packages on deb.torproject.org should be ready at the time the removal of the recommendation hits the Tor network. Ideally, the same should hold e.g. for FreeBSD ports as well. However, that needs to be on a best effort basis as the ports tree is out of our control).
  • they prevent or delay an important network-wide feature roll-out. Generally, this should get coordinated with marking the previous major Tor version as unsupported and end of life (EOL).
  • they are not supported anymore (EOL).

Note: client and server recommendations should be treated differently where beneficial and applicable. That is, a security fix release closing a vulnerability in relay-only code paths should not lead to older client versions getting removed from the recommended Tor versions list and vice versa.

Some of the above-mentioned criteria for removing a recommended Tor version might need additional means of communicating the urgency or importance of that step, be it via blog posts, mailing lists or other communication channels. Specifying those is outside of the scope of this policy. The same goes for related policies and processes governing things like Tor releases or declaring Tor versions to be not supported anymore.