Version 11 (modified by 7 months ago) (diff) | ,
---|
Tor supported platforms policy
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
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.
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.
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
- Anything else debian builds for
Rejected
- PPC (The
MUL
instruction isn't constant-time, thus many common cryptographic operations on these systems are subject to even the most trivial side-channel attacks.) - Anything else with a non-constant-time
MUL
instruction. - Intel P68 microarchitecture (Pentium IV-based Celeron CPUs produced from 2000-2004. The
SHR
/SHL
instructions 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)
- Supported OS X / macOS
- Modern Linux
Maintained
- Android (Should become Target)
- iOS
- 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
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
Target
- LibreSSL (which ones?)
- OpenSSL (stable supported releases, 1.0.1 or later)