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)