Clearly define operating system and version coverage

[eloquence]

In order for our maintenance effort to be manageable, we should clearly define:

• which operating systems we support, and at what level (e.g., stable vs. experimental)
• which particular versions or distributions of said operating systems (e.g., "the most recent non-stable release and the two most recent LTS")

We should also define our stance for unsupported operating systems/distributions:

• Do we generally advise users to build from source?
• Do we accept PRs to add support or fix compatibility issues?

[DeltaEpsilon19498]

For Linux distributions, what about supporting derivatives?

https://dangerzone.rocks/ used to list Ubuntu / Debian / Mint. Now the page only says Ubuntu / Debian.

Linux Mint 21,22 are derivatives of Ubuntu. It used to be on the dangerzone.rocks list. Is it still supported under the Ubuntu category?

If Mint is supported, is it just the mainline version, or does this also include LMDE 6, which is Linux Mint based on Debian Bookworm?

What about other derivatives of Ubuntu, like PopOS or ZorinOS?

What about derivatives of debian, like MX Linux or LMDE?

Or are no derivatives of Ubuntu or Debian officially supported or stable supported?

[DeltaEpsilon19498]

For Windows, which specific Windows versions will be supported?

Windows 10 home/pro will stop receiving free security updates on October 2025, but some people / businesses will be able to purchase additional security updates for a limited length of time. Some people may also choose to use Windows 10 Enterprise LTSC 2021, which is supported until January 2027, or choose to use Windows 10 IoT Enterprise LTSC 2021, which is supported until January 2032 (see https://massgrave.dev/windows10_eol). Will those versions also be supported?

What about the Windows 11 computers with the new ARM chips and NPU?

[apyrgio]

Damn, with the release going on, I forgot about this issue. Ok, let's try to explain first what we mean by "supporting a platform", and then list the platforms we support.

When we add support for a new platform (be it a new distribution or a new version), we make sure that we have in place the following:

1. Automated tests in various parts of the project's lifecycle: running when a new change is added, and every night.
   • The automated testing checks the following on each platform: building Dangerzone from source, running it against our test suite, installing Dangerzone from our official repos, etc.
   • This testing happens to a certain extent, e.g., we haven't found an easy way to test Docker on Windows/macOS CI runners.
2. For every new release, we manually QA Dangerzone on our supported platforms (see our release instructions).
   • Manual testing on Linux usually happens for a single version, usually the latest one.
3. For new PRs that introduce big changes, we check them against all of our supported platforms as well, to avoid any regressions.

On the subject of the platforms we support, we list them in our INSTALL.md:

• macOS
• Windows
• Ubuntu 24.10 (oracular)
• Ubuntu 24.04 (noble)
• Ubuntu 22.04 (jammy)
• Ubuntu 20.04 (focal)
• Debian 13 (trixie)
• Debian 12 (bookworm)
• Debian 11 (bullseye)
• Fedora 41
• Fedora 40
• Fedora 39
• Tails
• Qubes OS (beta support)

The rationale behind this list is to support our macOS / Windows users (journalists tend not to use Linux), and then add support for a selected few Linux distros that we feel have a big userbase: Ubuntu, Debian, and Fedora. Qubes and Tails are supported because they are adjacent to SecureDrop and SecureDrop Workstation, and we want these tools to work together at some point.

What about derivatives? I'm afraid that it's too much maintenance burden to support derivatives as well, to the same extent as we support our main platforms. We expect that people can use our repos on such distros, and we always have them in mind before introducing a breaking change. We also welcome issues very much, since often they are a sign that something's wrong with our code, or an external dependency.

---

To your question, Linux Mint was a weird exception, because at some point Micah created packages for it, added a mention in our website, but there were no testcases or manual checks for this platform. Basically, we copied the same .deb to a Linux Mint repo, and that was it. We could continue doing that, but that would not offer the same guarantees as in other support platforms. So, for a while now, Linux Mint users are actually installing Dangerzone from our Ubuntu repos.

What remained was a mention to Linux Mint on our website, which we decided to remove, since it didn't reflect the support status of this platform.

[apyrgio]

For Windows, which specific Windows versions will be supported?

My understanding is that on Windows, we're bounded by Docker Desktop's System Requirements](https://docs.docker.com/desktop/setup/install/windows-install/#system-requirements). Maybe by Python too. I guess a good first step is to reflect this on our installation page.

What about the Windows 11 computers with the new ARM chips and NPU?

Are these becoming a thing? Then it's the same situation as macOS, which recently got ARM chips. If our users start flocking to these laptops, then we'll start building ARM packages as well.

[DeltaEpsilon19498]

I do not know what it is like outside the United States. But for months now, I could walk into my local Best Buy and see the Copilot+PC strongly advertised. And one of their employees said that management was pushing Copilot+ "so hard right now". That was months ago. My understanding is that those computers are ARM-based. See https://www.windowscentral.com/hardware/laptops/arm64-copilot-plus-pc-or-intel-amd-nvidia. The article says that there is an emulation layer to make x86 apps work on it though.

Of course, given the privacy and security concerns regarding the Recall feature, not all journalists may want to use those computers. I do not actually know anyone who uses those computers, but the topic of operating systems tends not to come up in casual conversation.

[almet]

Thanks for opening the discussion on this. I believe the current situation is as follows:

↯ : We follow upstream support
⍈: We only test the latest version
🗹*: The CI is run on the latest version of Windows and macOS, but the Docker-related tests aren't currently checked.

(Unless specified, the architecture is AMD64)

Distro	Supported versions	Checked in the CI	Level of support
Windows	(see notes)	🗹*	stable
macOS intel	current + previous two releases	🗹*	stable
macOS ARM	current + previous two releases	🗹*	stable
Ubuntu	↯	🗹	stable
Debian	↯	🗹	stable
Fedora	↯	🗹	stable
Qubes OS	(see notes)	🗷	beta
Tails	⍈	🗷	stable

Quick notes about this table:

• Qubes OS support is done via the use of other OSes (e.g. Fedora or Debian) for the VMs, so the versions we support are tied to them ;
• For Windows, Docker sets the bottom line:

  Docker only supports Docker Desktop on Windows for those versions of Windows that are still within Microsoft’s servicing timeline. Docker Desktop is not supported on server versions of Windows, such as Windows Server 2019 or Windows Server 2022.

---

In addition to clarifying what needs to be, I believe it could be beneficial to decide if following upstream support is what we want to do for all the OS we support.

[apyrgio]

The support for Qubes OS is "experimental" but I'm not sure why? 🤔 Why Tails support is not tagged as experimental as well, for instance?

Well, it's actually "Beta", and the reason is this: #413
And Tails is considered stable only because it's based on Debian Bookworm. The installation instructions, on the other hand, should be improved at some point.

For macOS, it's not clear what are the requirements in terms of version.

The current situation seems to be the same as Docker's:

Docker supports Docker Desktop on the most recent versions of macOS. That is, the current release of macOS and the previous two releases.

However, we always try to support as more people as possible, even in older hardware, if it's something we can do easily. See this issue where we changed the shipped Python version to support EOL macOS installations.

[almet]

As a follow up on #1004, when we have a clearly defined view of the supported platforms, we should update our README.md with the information and then put all the links in the INSTALL.md file.

[almet]

Thanks Alex, I've updated the support table accordingly. Added a note in our biweekly meeting to clarify the support.