As discussed in Dev/Fedora, one of the points of contention were that Kicksecure could potentially not keep up with the Fedora release cycle. What I want to ask about is how the release cycle for Fedora could be problematic as a base for Whonix, given that projects with much littler resources can usually keep up without issue. The only exception I believe was secureblue due to an issue with Fedora Atomic 43, but that was fixed and it caught up soon after.
This doesn’t solve the other contentions that are presented by the wiki page, specifically the RHEL conflict of interest and the fact that it would take a long time to actually port, which I’ll leave out of this post. I only aim to address this one point, and if I wanted to talk about more of the points, I would make another thread. I would appreciate if that were to be respected, but I have no authority of what you want to do.
I would imagine keeping pace with Fedora would be less than enjoyable. With our current Debian base, it took us about four and a half months after the release of Debian Trixie before Kicksecure and Whonix 18 (based on Debian Trixie) were released. Now, granted, we were doing a lot in that time (switching from X to Wayland, switching from Xfce to LXQt, creating emerg-shutdown, polishing user-sysmaint-split, adding boot mode support to Qubes OS, etc.), so getting things stable was a challenge. Later releases might be a lot easier, but we could always have another “major overhaul” release in the future.
Fedora releases every six months, so we’d have to push out a new major version every six months to keep pace. That’s four times as fast as what we have now (a new major version every two years or so). If we had another “major overhaul” release with a Fedora-based system, and it took us four and a half months from the time of release, we’d have to start working on the next major release just a month and a half after the last one.
(I’m hoping that replying via email still makes this look okay…)
Fedora does indeed have a release every 6 months, but Fedora versions usually go EOL 13 months after release. While it is still less time than the Debian release cycle, but now the window is only half as long, rather than a quarter. This would definitely be enough for minor overhaul releases, but it would be quite a tight fit for major ones.
In my opinion, it would probably be a good idea to make the base change it’s own major release, and push back every other major change to a later version. That way, you can still make sure users are up to date, while working on and auditing new features. I believe that you and others are more acquainted with Whonix development and it’s release cycle than I am, and I would be happy to hear your thoughts.
In theory, port to the next major version of Debian (once in some sort of freeze or blessed stable) could be speed up a lot if we had parallel “stable-next” or “testing” development and/or support.
For example, if we had Debian 14 / codename “forky” branches, CI build and functionality testing and downloadable images.
As for CI, at the time of writing we only have CI build testing. We don’t have CI functionality testing. (Automated Tests)
(We have partial coverage to Qubes openQA and systemcheck to simplify release testing.)
Dunno which projects you’re comparing with but they might carry a lot less features.
This is a highly debated topic on the Qubes OS Forum, with threads questioning why a security-oriented OS like Qubes uses Fedora for its central domain (dom0), given concerns like corporate influence, origins of key security features, and release stability. Specifically, Fedora is primarily sponsored by Red Hat (owned by IBM), its core security feature SELinux was originally developed by the NSA, and it follows a rapid 6-month release cycle, which can lead to instability or rushed updates in a security-focused context.
Additionally, Qubes’ own release cycle is roughly every 2 years, meaning the Fedora version underpinning dom0 often becomes EOL well before Qubes updates it, leaving a year or more of potential unpatched exposure. That’s a troubling gap for something as critical as Qubes.
I share reservations about Debian’s 2-year major release cycle, as it can lag on bleeding-edge security updates. But 6 months is far too short for a stable, thoroughly tested base in security-focused systems like Whonix, neither is perfect, but Debian’s emphasis on stability makes it a stronger fit overall for minimizing risks in a privacy/anonymity tool.
Aren’t EOL concerns in dom0 generally nonexistent? The Qubes team maintains the security-critical bits (Xen, the kernel, etc.), but the userland being EOL is explicitly not considered a concern. See:
One could make the argument that Qubes actually becomes more secure once dom0 goes EOL, since it means supply chain attacks against Fedora upstream won’t affect Qubes or will at least be extremely easy to spot. The recent Qubes R4.3 release had a dom0 that was EOL by the time R4.3 released, which IMO is how it should be.
Edit: forgot to mention this initially, but obviously it would be bad for Kicksecure or Whonix to use an EOL distro. That’s because we unavoidably have a much, much larger attack surface than Qubes dom0, and can’t security-maintain all of the software presenting that attack surface by ourselves. We have to use a supported distribution so that upstream can do that for us.
You’re right that EOL for dom0 isn’t a major concern, I totally agree, as the minimal, isolated attack surface of dom0 makes upstream EOL less risky.
That said, EOL was just one of my concerns, the others remain debated topics, even if they’re mitigated in dom0’s unique context.
The core issue here isn’t really dom0, it’s whether those factors, or the precedent of Qubes using Fedora for dom0, justify switching Whonix to Fedora. As you noted in your edit, Whonix and Kicksecure have a vastly larger attack surface and rely heavily on upstream for patching thousands of packages. A supported, stable base like Debian is essential for that reason, and Fedora’s shorter cycle wouldn’t align well with the thorough testing needed for a security/anonymity-focused distro.
So, while Qubes’ dom0 setup works for its specific design, it doesn’t translate directly as a recommendation for Whonix. Debian’s greater stability still makes it the better fit overall, despite its own drawbacks.