Tor supported platforms policy
This policy was provisionally adopted by the Network Team on 31 March 2020. It will become 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
1: Target
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.
2: Maintained
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.
3: Unsupported
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.
4: Rejected
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
Target
- x86
- x86_64
- arm (sufficiently recent)
Maintained or unsupported, can't decide:
- mips
Unsupported
- x86 without SSE2. (Should just be a performance thing, because we'll always have portable code)
- Itanium
- SPARC
- newer PowerPC (PPE, Power8+) with constant-time multiplications
- Anything else debian builds for
Rejected
- 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
SHR/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
Target
- Supported Windows (>= 7) and Windows Server (>= 2008)
- MinGW
- MSYS2
- 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
Maintained
- Android (Should become Target)
- Unsupported Windows client versions, where the server version is Target:
- Windows Vista
- iOS
- OS X / macOS supported by Tor Browser (but not Apple)
- FreeBSD
- OpenBSD
- NetBSD
Need to decide:
- Other BSD derivatives
Unsupported
- Hurd
- 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
Rejected
- Windows past EOL
- OS X past EOL
- Anything else not receiving security updates
C Compilers
Target
- GCC (non-ancient)
- clang (non-ancient)
Unsupported
- Everything else that's not rejected
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.
Other dependencies
TLS / Cryptographic Libraries
Target
- LibreSSL (which ones?)
- OpenSSL (stable supported releases, 1.0.1 or later)
Maintained
- NSS (Should become Target in 0.3.6 or later, if it works well enough)
Rust
Rust is currently optional.
Target
- Rust nightly, beta, stable
Maintained
- 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
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:
- Stem
- Chutney
- Fallback Scripts
- sbws (Simple Bandwidth Scanner) Their support policies may vary, depending on our available resources.
Target
- Supported Python 3 Stable Releases
Maintained
- 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
- Unsupported Python Releases
- All Other Python Implementations (PyPy, Tauthon, etc.)