Tor supported platforms policy
This policy was provisionally adopted by the Network Team on 31 March 2020. It became non-provisional on 1 August 2020.
Note: This document only applies to "tor", the network daemon program.
Also note: This reflects aspiration, not promise.
And note finally: These categories are not a value judgment on your platform. They are a warning about the Tor team and the resources we have.
Levels of support
We will make sure this works and works well. CI required, multiple active devs, popular, etc. We try to backport fixes to all supported release series.
When we find out it's broken, we'll try to fix it. To get here, we need at least one person who knows it and is willing to try to help out. We try to backport fixes to all supported release series.
We'll take a clean patch if you write one and we can find somebody to test it. Everything starts here by default. We might backport fixes to one or two supported release series, if they are simple enough.
You need to maintain your own fork if you want this to work. (This is the standard response for hypothetical cpus and operating systems where nobody knows if they exist or nobody has seen one in 20 years. No patches unless somebody can test them somewhere, somehow.)
How to decide support levels
This is rationale, not policy.
If we actually have CI that we respond to very quickly, and we have active developers who know how to build and test for the platform, and we would block a stable release if the platform was not working, then we can make it Target.
A Maintained platform is like a Target platform, except without good CI, without expertise on the Tor team, or without the resource commitment. Conversely, a Maintained platform is like an Unsupported one, except that we think that we can sometimes figure out how to write patches for it, and like to do so when we have free time.
If we have no way to test patches, but we'd take a clean obviously-safe patch if somebody wrote one, then it's Unsupported. Generally, Unsupported is only good for systems that aren't too weird in how they behave.
We should Reject platforms if supporting them can't be done without lots of unverifiable code, or can't be done without making the code ugly. If we would prefer that developers on a platform should fork Tor, then it's Rejected. If (nearly?) all users on a platform are insecure, it's also good candidate for Rejected. So that's the default position for platforms without vendor support.
CPU support levels
- arm (sufficiently recent)
Maintained or unsupported, can't decide:
- x86 without SSE2. (Should just be a performance thing, because we'll always have portable code)
- newer PowerPC (PPE, Power8+) with constant-time multiplications
- Anything else debian builds for
- Processors with non-constant-time
MULinstructions (many common cryptographic operations on these systems are subject to even the most trivial side-channel attacks):
- Older PowerPC (<= PowerPC 970)
- Older ARM (<= 9T, <= Cortex M3)
- VIA Nano 2000 Series
- Intel <= 80486
- See https://bearssl.org/ctmul.html for full details
- Intel P68 microarchitecture (Pentium IV-based Celeron CPUs produced from 2000-2004. The
SHLinstructions aren't constant-time because Intel removed the barrel shifter.)
- Anything else which lacks a barrel shifter.
- Anything without virtual address spaces
- Anything middle-endian
OS Support levels
- Supported Windows (>= 7) and Windows Server (>= 2008)
- Supported OS X / macOS
- except for macOS i386, which is Maintained. Apple will remove support for i386 binaries in macOS 10.15 (2019).
- Modern Linux
- Android (Should become Target)
- Unsupported Windows client versions, where the server version is Target:
- Windows Vista
- OS X / macOS supported by Tor Browser (but not Apple)
Need to decide:
- Other BSD derivatives
- Proprietary unix
- Very old Linux kernels
- most weird old unixes (Solaris, OpenSolaris)
- PureDarwin, OpenDarwin, etc.
- Anything completely non-posixy, other than Windows or iOS
- Windows using Cygwin
- Windows past EOL
- OS X past EOL
- Anything else not receiving security updates
- GCC (non-ancient)
- clang (non-ancient)
- Everything else that's not rejected
- C before C99.
- Systems where pointer size is something other than 32 or 64 bits.
- Systems where int is something other than 32 or 64 bits.
- Systems where you can't sanely define int32_t and int64_t and intptr_t.
- Systems where memset(&ptr, 0, sizeof(ptr)) doesn't yield a null pointer.
- Systems where signed arithmetic is not two's complement
- Systems where time_t is unsigned
- Anything that can't process the the headers for our dependencies and link with them.
- All compilers that are only hypothetically permitted by the C standard.
TLS / Cryptographic Libraries
- LibreSSL (which ones?)
- OpenSSL (stable supported releases, 1.0.1 or later)
- NSS (Should become Target in 0.3.6 or later, if it works well enough)
Rust is currently optional.
- Rust nightly, beta, stable
- Currently, all versions from stable back to 1.31
- The minimum Rust version may change over time as needed for new features, but will always be less than or equal to stable.
- Need to decide on a support policy for old rust versions
Python is optional in Tor: it is used to run some of Tor's tests.
Some other network team products are written in python, for example:
- Fallback Scripts
- sbws (Simple Bandwidth Scanner) Their support policies may vary, depending on our available resources.
- Supported Python 3 Stable Releases
- Python 3 Unstable and Nightly Releases
- Python 2.7
- Note: Between 1 January and 1 April 2020, Python 2.7 is transitioning to Unsupported.
- Unsupported Python Releases
- All Other Python Implementations (PyPy, Tauthon, etc.)