Whonix support for Qubes 4.0 has ended

As a final reminder following our previous announcements, Whonix support for Qubes 4.0 ends today, 2022-04-20.

How does Whonix support work?

While Qubes OS releases are supported for six months following each subsequent major or minor release, Whonix templates have their own support policy set by the Whonix Project. This policy requires Whonix template users to stay reasonably close to the cutting edge by upgrading to new stable releases of Qubes OS and Whonix templates within a month of their respective releases. To be precise:

  • One month after a new stable version of Qubes OS is released, Whonix templates are no longer supported on any older release of Qubes OS. This means that users who wish to continue using Whonix templates on Qubes are usually required to upgrade to the latest stable Qubes OS version within one month of its release (unless the deadline is extended, as it has been in this case).

  • One month after new stable versions of Whonix templates are released, older releases of Whonix templates are no longer supported. This means that users who wish to continue using Whonix templates on Qubes are usually required to upgrade to the latest stable Whonix template versions within one month of their release. (This point doesn’t apply to the present situation, since this announcement pertains to a new Qubes OS release, not a new Whonix template release. However, I’m mentioning it here for the sake of completeness, as it’s part of the Whonix support policy.)

What does this mean for you?

If you’re currently using Whonix on Qubes 4.0, you should immediately either upgrade to Qubes 4.1 or discontinue the use of Whonix.

If you’re already on Qubes 4.1, or you don’t use Whonix templates, then you’re all set. This announcement doesn’t change anything for you.


This is a companion discussion topic for the original entry at https://www.qubes-os.org/news/2022/04/20/whonix-support-for-qubes-4-0-has-ended/

That is bad!
Why you can not back-port whonix for Qubes 4.0 users to make the transition smoother.
The momentum of lazy is there but some people have also other priorities than to just update qubes to the shiny newest revision.

Whonix templates are supported by our partner, the Whonix Project. The Whonix Project has set its own support policy for Whonix templates in Qubes.

This policy requires Whonix template users to stay reasonably close to the cutting edge by upgrading to new stable releases of Qubes OS and Whonix templates within a month of their respective releases.

Otherwise, if you install Whonix-16 on Qubes 4.0, it will probably work, but you have no guarantees of strong anonymity from the Whonix team, due to their lack of resources (they would appreciate any help!).

1 Like

I have whonix 16 on qubes 4.0 and it does not want to upgade as the repo is too old it says.
My production qubes 4.0 as accumulated enough bit rot to redo everything from startr with 4.1 qubes, HCL was positive for my machine, but one needs to backup the VMs (pigz to speed it up) and then one needs to do all the stuff of seting it up.
So this would mean I guess two days of Qubes Idol worship at least to get the things done.

I find such attitude so disrespectful and arrogant. Not to speak that in the first case it’s not even about Qubes, but Whonix. Nope, here comes for the devs immediately in the second case. And it’s a manner, not an exception.

Nothing can prevent this to happen again on August 4th.

So I do have a ironic style. So doing Idol worship with Qubes means, that I really care and really go into it to migrate my system, and do some tests I promised to do (testing pigz against gz for archiving and restoring a VM), as I use Qubes since many years for production there is much to do also in order not to loose any data.
There were times, when I needed to boot kali linux to recover my precious data from the smoking debris on my disks.
So doing a fresh install is work. Also I need to dd my disk to a raid server as a fall back in order to be able to recover stuff, if the backup and restore mechanism fails.
So this intense work I call Idol worship, as the work is only needed to worship the idol of operational Qubes. The worship gives no benefit for the purpose (e.g. r&d) one uses computers for.
Others speak of yak (big fury animal) brushing if they need to go a long detour in order to solve a “simple” problem.
So there is nothing “disrespectful and arrogant” it is just funny, at least for me :slight_smile:
Cheers,

luja

Yes, it does: you at least get bug fixes and new features. I can tell you that it’s more joy to use 4.1 than 4.0 because it’s UX is more convenient and has less bugs (waiting for 4.2!). Another feature is security, because 4.0 will stop getting support soon.

Did you consider in-place upgrade?

Of course I considered it, but it utterly failed because of bit rot.
My production Qubes underwent some modifications and migrations,
and the in place upgrade failed as I tried it. If the in place upgrade script
that has many stages of upgrading dom0 and template VMs got improved,
I could give it a try.

What does end of support mean in practice? Whonix 16 is still supported, so for example will Whonix 16 on R4.0 still receive new Tor and other packages since they’re the same for R4.0 and R4.1? But then if an update breaks something or an update from a Qubes OS component breaks something then users will be out of luck?
Or is there a full stop on all package updates when using Whonix 16 on R4.0?

I understand it to mean at least that, if a security vulnerability is discovered that affects Whonix on Qubes 4.0, it will not be fixed, and that’s reason enough either to upgrade to Qubes 4.1 or discontinue use of Whonix on Qubes 4.0.

You’d have to ask @adrelanos the questions about the specific rules regarding package availability.

2 Likes