I understand that QubeOS 4.2 was released the 2023-12-18, and that Whonix 16 will reach end-of-life the 2024-01-18. Considering that Whonix 17 can’t be installed on QubesOS 4.1, this gives privacy-dependent users a mere month to upgrade to the new system before being put at risk.
Please consider that some of us use QubesOS in production, and can’t afford the time and/or risks of a full upgrade in such tight delays. A general good practice is to give users at least 6 months for such an upgrade, and I believe it’s been the case with QubesOS in the past.
As I understand it, this situation is the result of an unfortunate mismatch in release schedules. Hovewer, putting QubesOS/Whonix users in such tight spot seems wrong, and arbitrarily punishing. Please consider a workable solution for us, such as extending Whonix16 support by 5 more months, or providing a way to install Whonix17 on QubesOS 4.1.
My understanding from the context given in the link above:
the decision to EOL Whonix-16 has to do with upstream dependencies (namely a patch that won’t make it to Debian 11)
the timing between the release of Qubes OS 4.2 and the EOL of Whonix-16 is unfortunate, but also not something that can be changed
the decision not to release Whonix-17 for Qubes OS 4.1 was made by the Whonix maintainer (not the Qubes OS team)
And (for what is worth) that decision seems well-founded to me, given the current resources available for Whonix developmemt. That’s something best discussed in the Whonix forum though.
On Qubes 4.1.2 sudo release-upgrade brought the Whonix templates up to version 17 soon after it was released.
However since it only supports Qubes 4.2, I suspect that particular upgrade process hasn’t been tested officially. But if it work, it may be a practical solution for some who cannot afford to upgrade to 4.2 in such a tight timeframe
Which is why this topic should have been created on the Whonix forums, not here.
Which is why consider donating to Whonix if you can. They are doing an amazing work for the Community.
Indeed. Just too many combinations for me to keep track of. Needs to be tested and kept tested as packages are upgraded to avoid accidentally breaking R4.1 APT package manager with broken dependencies.
To be clear, it is not an accidental timing mismatch. It is an intentional Whonix Project policy:
In other words, it is not a coincidence that Whonix 16’s EOL happens to be one month after the release of Qubes 4.2. Rather, the Whonix Project’s support policy intentionally sets Whonix 16’s EOL to be exactly one month after the release of Qubes 4.2.
(This is not a value judgment about the Whonix Project’s policy. It is simply a sharing of facts in an effort to clarify a possible misunderstanding.)
While I understand and find changing Whonix policy to a 5 month EOL after new Qubes release legit, I don’t understand reasoning quoted above.
- Using Qubes in production will prevent you from upgrading Qubes, not Whonix. Whonix is already there in installation medium.
- No matter what upgrade is needed, you have to do it at some point and any given point will cause a delay in a production. So, unavoidable.
- Whose production? “Some of us”? Well, this is the last thing the devs would want and like to hear, I imagine.
Conclusion: even legit, suggestion is not justified.
It seems you have been provided with several highly relevant posts, but I will still share my input as a fellow Qubes-Whonix user.
The number one rule with computers is updating your system regularly. For an operating system configuration as important as Qubes-Whonix, updating sooner rather than later is crucial. Therefore, for your sake, I suggest migrating to Qubes 4.2.0 with Whonix 17 as soon as possible, as any previous versions of either operating system are unsupported, or will become so in the near future.
If you personaly had to choose between going for the
release-upgrade or let it be outdated, which one would you go for?
As far as I understand, the unfixed issue in Debian 11 Tor is a denial of service, not something that’d break anonymity. However if they stop patching that could lead to that.
(Thanks to everyone sharing helpful/informative answers)
@fujak2 there is some momentum for Whonix 17 being available on Qubes.
Any updates on this issue? I see, in the qubes-templates-community-testing repo, both Whonix 17 templates:
> whonix-gateway-17 0:4.0.6-202401140407 qubes-templates-community-testing
> whonix-workstation-17 0:4.0.6-202401140407 qubes-templates-community-testing
How stable/polished are they? And if not, can I help with the testing?
Update on the community templates for Whonix-17…
[ Tl;dr summary: they work fine, as far as I can tell ! including using sys-whonix for dom0 updates]
A couple of days ago, I reinstalled my guinea pig T480, which was in shambles after the terrible ordeal of sys-gui-gpu, with R4.1.2, to start testing Whonix-17.
After updates, Fedora & Debian template upgrades, etc., bringing the system up to date, installed the two
whonix-*-17 community templates. No problems whatsoever. Got updates for them immediately, no problem. Updated the tor browser using the Tor Browser Downloader - no problem.
Proceeded (according to the Documentation) to replace/upgrade the Qubes-Whonix bits, and removed the Whonix-*-16 templates.
Have been using the system for more than two days as my daily driver (did not copy/restore the vault and other sensitive stuff though). It feels and behaves normally. Set sys-whonix as “Dom0 update qube” → running
sudo qubes-dom0-update --releasever=4.1 --preserve-terminal shows the normal output (downloading the repo metadata etc.)
Apart for the fact that the templates are in the “Community Testing” repo, not the official one, they seem to be production-ready.
right after reading the EOL-News of whonix-16, an inplace upgrade was done as it is written in the whonix-docs and this is running fine on my 4.1 since one month.
Great to see this solved with the best possible solution. Thanks for the updates @deeplow @barto.