173 lines
6.2 KiB
Markdown
173 lines
6.2 KiB
Markdown
# Support policy for Arti (draft)
|
|
|
|
We intend, in the long term, that Arti should work and provide privacy
|
|
on all major desktop and mobile operating systems. In actuality,
|
|
however, our current resources and infrastructure only allow us to run
|
|
Arti's tests on a subset of the environments that we want to support.
|
|
|
|
Please read this document as a rough statement of intent, not as a formal
|
|
promise. For now, we'll deviate from these policies whenever it we think it
|
|
makes sense, and we'll amend from time to time without notice.
|
|
|
|
## Elements of support
|
|
|
|
For this document, we define the following support tiers.
|
|
|
|
If a configuration is **unsupported**:
|
|
|
|
* We do not typically accept patches related to the configuration.
|
|
* We do not issue security advisories related to the configuration.
|
|
* We close tickets related to the configuration as wont-fix.
|
|
|
|
If a configuration is **community-supported**:
|
|
|
|
* We accept clean patches for improved features on the configuration.
|
|
* We accept clean patches for bugfixes on the configuration.
|
|
* At our discretion, we work on fixing bugs that affect the
|
|
configuration.
|
|
|
|
Additionally, if configuration is **maintained**:
|
|
|
|
* We commit not to knowingly make releases that break the
|
|
configuration.
|
|
* If we learn that the configuration is broken, we prioritize fixing
|
|
it.
|
|
* We write and announce security advisories if we learn about security
|
|
issues in the configuration.
|
|
|
|
|
|
Additionally, if configuration is a **target**:
|
|
|
|
* It is a higher priority for us than other **maintained**
|
|
configurations.
|
|
* We'd like to make it a **tested** configuration, if we have the
|
|
resources. We intend to add more testing to it until it can become
|
|
**tested**.
|
|
|
|
Additionally, if a configuration is **tested**:
|
|
|
|
* We have automated systems to make sure that the configuration
|
|
builds and runs tests correctly.
|
|
* We have one or more team members who "dogfood" the configuration,
|
|
using it ourselves to get rapid notifications about usability
|
|
problems.
|
|
|
|
(Note that no broad configuration can be fully **tested** in all of its
|
|
permutations. For example, our automated tests can only be run on a
|
|
limited set of the number of Linux distributions and versions, when in
|
|
fact there are vast numbers of possible Linux installations whose
|
|
variations might affect our behavior.)
|
|
|
|
|
|
## Operating systems
|
|
|
|
Our top priorities are the following operating systems:
|
|
|
|
* Android (**target**)
|
|
* Linux (**target**, **tested**)
|
|
* OSX (**target**)
|
|
* Windows (**target**)
|
|
* iOS (**target**)
|
|
|
|
We only support modern versions of these operating systems. If the
|
|
upstream providers of the operating system no longer provides security
|
|
patches for it, it is usually **unsupported**. Some old versions may
|
|
be **maintained** or **community-supported**, depending on their
|
|
age and the difficulty of working with them.
|
|
|
|
We currently have automated tests on Linux only. On OSX and Windows, we
|
|
have automated builds, but the tests are not (yet) run. In the long
|
|
run, we aim to have automated builds and testing for all of our these
|
|
platforms.
|
|
|
|
All other modern Free operating systems are **community-supported**:
|
|
we're happy to fix bugs as they're encountered, and we're happy to take
|
|
good clean patches. Some may become **maintained** in the future,
|
|
depending on the level of interest, the size of the userbase, and
|
|
resources available.
|
|
|
|
Other proprietary operating systems are **unsupported**.
|
|
|
|
## CPU Architectures
|
|
|
|
Only X86-64 is currently **tested**.
|
|
|
|
32-bit X86, and 64-bit ARM are **target**.
|
|
|
|
Modern-enough 32-bit ARM is **maintained**.
|
|
|
|
All other CPUs are **community-supported** or **unsupported**.
|
|
|
|
## Dependencies
|
|
|
|
Our _minimal_ dependencies, as listed in our `Cargo.toml` files, are
|
|
expected to work. We have automated tools to make sure that Arti builds
|
|
and passes tests with these minimal dependencies on Linux.
|
|
|
|
We do not guarantee that these minimal dependencies are free of security
|
|
issues: If you use Arti as a library, you need to use tools like `cargo
|
|
audit` to regularly check for reported security advisories with the
|
|
crates that you use.
|
|
|
|
Our _production_ dependencies, as listed in our `Cargo.lock` file and as
|
|
used to build binaries, are what we actually recommend. We will
|
|
actively work ourselves to keep them up-to-date and secure.
|
|
|
|
Dependency versions older than those listed in our `Cargo.toml` files
|
|
are **unsupported**.
|
|
|
|
|
|
## Rust versions
|
|
|
|
We define our "minimum supported rust version" (MSRV) as the oldest
|
|
version of Rust that we expect Arti to build with.
|
|
|
|
We have automated tools to make sure that Arti builds and passes tests
|
|
with our MSRV and our minimal (`Cargo.toml`) dependencies. Production
|
|
dependencies (`Cargo.lock`) are not tested with our MSRV, and may or may
|
|
not work.
|
|
|
|
Our current MSRV is 1.56. We may update our MSRV to a newer version in
|
|
the future: when we do, we'll only require a version released at least
|
|
six months in the past, and we won't update our requirements for no
|
|
reason.
|
|
|
|
Rust versions older than our MSRV are **unsupported**.
|
|
|
|
## Supported versions of Arti
|
|
|
|
For now (pre 1.0.0), only the most recent version of Arti is supported
|
|
at all.
|
|
|
|
In more detail:
|
|
|
|
* The only versions that get any automated testing are the
|
|
latest version from the git `main` branch, and other branches that are
|
|
considered for merge to it.
|
|
* We don't accept patches that aren't written to apply to `main`.
|
|
* If we have to make any urgent bugfix-only releases, we will apply
|
|
those fixes only to the most recently released version of Arti.
|
|
|
|
We will revisit and change this policy in the future.
|
|
|
|
## API compatibility
|
|
|
|
Although we aim to provide a forward-compatible API for some of our
|
|
high-level crates (notably `arti-client`) in the future, we aren't yet
|
|
at a point where we can do that. Between now and Arti 1.0.0, users
|
|
should expect that each Arti release will possibly break API
|
|
compatibility.
|
|
|
|
## Security Advisories
|
|
|
|
We will classify security issues as Research, Critical, High, Medium and
|
|
Low-severity, as per [tor's security policy].
|
|
|
|
For now (pre 1.0.0) we will issue advisories for High and Critical
|
|
security vulnerabilities only.
|
|
|
|
Also (pre 1.0.0) we will not typically issue advisories for older Arti
|
|
releases: we assume that all developers are upgrading regularly.
|
|
|
|
[tor's security policy]: https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/SecurityPolicy
|