Qubes OS 4.2.2 has been released!

News
1

We’re pleased to announce the stable release of Qubes OS 4.2.2! This patch release aims to consolidate all the security patches, bug fixes, and other updates that have occurred since the previous stable release. Our goal is to provide a secure and convenient way for users to install (or reinstall) the latest stable Qubes release with an up-to-date ISO. The ISO and associated verification files are available on the downloads page.

What’s new in Qubes 4.2.2?

For more information about the changes included in this version, see the Qubes OS 4.2 release notes and the full list of issues completed since the previous stable release.

Copying and moving files between qubes is less restrictive

Qubes 4.2.2 includes a fix for #8332: File-copy qrexec service is overly restrictive. As explained in the issue comments, we introduced a change in Qubes 4.2.0 that caused inter-qube file-copy/move actions to reject filenames containing, e.g., non-Latin characters and certain symbols. The rationale for this change was to mitigate the security risks associated with unusual unicode characters and invalid encoding in filenames, which some software might handle in an unsafe manner and which might cause confusion for users. Such a change represents a trade-off between security and usability.

After the change went live, we received several user reports indicating more severe usability problems than we had anticipated. Moreover, these problems were prompting users to resort to dangerous workarounds (such as packing files into an archive format prior to copying) that carry far more risk than the original risk posed by the unrestricted filenames. In addition, we realized that this was a backward-incompatible change that should not have been introduced in a minor release in the first place.

Therefore, we have decided, for the time being, to restore the original (pre-4.2) behavior by introducing a new allow-all-names argument for the qubes.Filecopy service. By default, qvm-copy and similar tools will use this less restrictive service (qubes.Filecopy +allow-all-names) whenever they detect any files that would be have been blocked by the more restrictive service (qubes.Filecopy +). If no such files are detected, they will use the more restrictive service.

Users who wish to opt for the more restrictive 4.2.0 and 4.2.1 behavior can do so by modifying their RPC policy rules. To switch a single rule to the more restrictive behavior, change * in the argument column to + (i.e., change “any argument” to “only empty”). To use the more restrictive behavior globally, add the following “deny” rule before all other relevant rules:

qubes.Filecopy    +allow-all-names    @anyvm    @anyvm    deny

For more information, see RPC policies and Qube configuration interface.

How to get Qubes 4.2.2

You have a few different options, depending on your situation:

  • If you’d like to install Qubes OS for the first time or perform a clean reinstallation on an existing system, there’s never been a better time to do so! Simply download the Qubes 4.2.2 ISO and follow our installation guide.

  • If you’re currently on Qubes 4.1, learn how to upgrade to Qubes 4.2.

  • If you’re currently on Qubes 4.2 (including 4.2.0, 4.2.1, and 4.2.2-rc1), update normally (which includes upgrading any EOL templates you might have) in order to make your system essentially equivalent to the stable Qubes 4.2.2 release. No reinstallation or other special action is required.

In all cases, we strongly recommend making a full backup beforehand.

Reminder: new signing key for Qubes 4.2

As a reminder for those upgrading from Qubes 4.1 and earlier, we published the following special announcement in Qubes Canary 032 on 2022-09-14:

We plan to create a new Release Signing Key (RSK) for Qubes OS 4.2. Normally, we have only one RSK for each major release. However, for the 4.2 release, we will be using Qubes Builder version 2, which is a complete rewrite of the Qubes Builder. Out of an abundance of caution, we would like to isolate the build processes of the current stable 4.1 release and the upcoming 4.2 release from each other at the cryptographic level in order to minimize the risk of a vulnerability in one affecting the other. We are including this notice as a canary special announcement since introducing a new RSK for a minor release is an exception to our usual RSK management policy.

As always, we encourage you to authenticate this canary by verifying its PGP signatures. Specific instructions are also included in the canary announcement.

As with all Qubes signing keys, we also encourage you to authenticate the Qubes OS Release 4.2 Signing Key, which is available in the Qubes Security Pack (qubes-secpack) as well as on the downloads page.

What is a patch release?

The Qubes OS Project uses the semantic versioning standard. Version numbers are written as ... Hence, we refer to releases that increment the third number as “patch releases.” A patch release does not designate a separate, new major or minor release of Qubes OS. Rather, it designates its respective major or minor release (in this case, 4.2) inclusive of all updates up to a certain point. (See supported releases for a comprehensive list of major and minor releases.) Installing the initial Qubes 4.2.0 release and fully updating it results in essentially the same system as installing Qubes 4.2.2. You can learn more about how Qubes release versioning works in the version scheme documentation.

This is a companion discussion topic for the original entry at https://www.qubes-os.org/news/2024/07/13/qubes-os-4-2-2-has-been-released/
10 Likes
2

The links to previous versions have disappeared from the download page.

Is this intentional or just an error?

3

That’s intentional, because those releases are no longer supported (EOL):

4

@adw The link you mentioned above leads to a page listing a lot of different versions of old Qubes ISOs. In my opinion, this is no real replacement for the removed information, for several reasons:

  • It is not clear from this page, which were the final versions of the EOLed versions of Qubes, or, at least, it is more difficult to find them there.

  • The versions at this location only cover old 4.x versions of Qubes. The old final versions of 3.2.1, 2.x, and even 1.x have completely disappeared. For historical reasons, and because there might still be some users of these versions, they should remain findable. (Originally, I come from an OpenVMS environment, where support may still go back to the 1980s and old VAX versions. :grin:)

  • For Windows users, setting R4.1.2 to EOL is still not a viable option. As long as issues like #9102, #8328, and others are still open, upgrading to R4.2.2 may not be possible. Hopefully, this problem will go away if and when the work described in #1861 is completed.

  • The discussion at GitHub you mentioned above seems to indicate that currently, it is not clear where the old versions will be made accessible. As long as this is not decided and implemented, the old location should not be removed.

So it would be helpful if at least a link to the old location were still provided.

1 Like
5

There are findable archives of the old Qubes versions - I run one myself.
But unlike on the VAX, Qubes does not support these old versions and there
should not be people still using them.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

1 Like
6

@adw @unman

I am not in touch with @fepitre. He is very busy at the moment and most probably won’t check the forum at all. He kindly hosts historic releases at https://qubes.notset.fr but unfortunately not via rsync. Since the hystoric data already exists, it would be very nice if it was made available via rsync as well. Just in case someone wants to replicate it.

3 Likes
7

Updated regulary several times, udate tool and terminal and rebooted. In /etc/qubes-release still on 4.2.1.

1 Like
8

The “final” versions would be simply be those with the highest version numbers.

That’s exactly what the issue is about.

The devs are aware of the situation.

As far as I knew (before the last few comments in this thread, anyway), there was no “old location” with the pre-4.0 ISOs that we could simply link to. The old pre-4.0 links that were removed were broken links pointing to nothing, because the pre-4.0 ISOs were no longer being mirrored. The purpose of the issue is for someone to create something containing the old ISOs so that we can link to it.

I have just learned (from the last few comments in this thread) that apparently @unman and @fepitre have already created such things. What happens next is up to @unman as the website maintainer.

1 Like
9

Please open a bug report.

10

That’s feasible on my side. I’m currently redoing and migrating lot of stuff so I could check on it during the summer.

5 Likes
11

the same for me, after updates still on 4.2.1

1 Like
12

No need to create a bug report, It’s normal.
The qubes-release-4.2-7.fc37.noarch.rpm package which hosts the Qubes-OS 4.2.2 release is in the current-testing rpm repository. Wait few days and it will be in the stable repository… Or wait to see it listed in the dom0-stable update status.

2 Likes
13

In that case, I guess the bug is that we forgot to migrate the package from testing to stable when we released 4.2.2 as stable, @marmarek.

1 Like
14

My issue is resolved, since yesterday update, I get 4.2.2

3 Likes
15

Yeah, the package that @ludovic mentioned was (silently) moved to the stable rpm repository so everybody’s getting the correct version now.

16

This is completely absurd and nonsensical.

You don’t actually “support” anything.

Do you know what that word means?

It doesn’t mean “I contribute code and answer questions when I feel like it.” It doesn’t mean “we issue updates in accordance with our whims rather than an actual agreement with customers.” It doesn’t mean “what we have a right to expect from an open source ad hoc volunteer project whose creations we pay nothing for.”

The deal is: you do what you want and release it as you want, which generously often means “free and Free.”

We, the users, neither expect, nor have a right to expect, anything whatsoever from you.

The idea of Qubes “supporting” anything is a weird fiction. We don’t have a support relationship. You certainly don’t perform one, and I certainly don’t expect one.

It is the Wild West of open source. We fend for ourselves and so do you. Sometimes things make us happy and sometimes we think they suck. Often there is generous help from you or other users.

It’s totally weird for you to give this particular reason for hiding some code when you don’t need a reason at all. I’m not sure why you do it. Just say “because we want to” and be done with it.

By the way I agree it sucks that it’s now harder to download the one that supports windows. But you don’t have to care what I say because we don’t have a support relationship.

2 Likes
17

Also telling people what they “should” and should not be doing is in no universe your job or appropriate.

Maybe what you mean is they “should not” use those versions if they have certain goals (presumably your exact personal goals you have trouble seeing beyond, or something like “maximizing security”) and are using the computer in a certain way (the exact scenario you imagine, which always necessarily involves internet use etc etc).

2 Likes
18

I think this is not so, and your expectation is not shared by other
users.
If you raise an issue for Qubes 3.2 it will be closed straightaway.
If you raise an issue for Qubes 4.2 it will be recorded and added to the
list of open issues. The issue may be resolved, or not, depending on
importance, direction of development, and resources.
It is in that sense that earlier versions are not supported - this is, I
thought, a normal use of the term, and it was the use that GWeck
instanced when referring to VMS.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

9 Likes
19

Also, not keeping all old ISOs on the main download server is not “hiding code.” First, there’s a difference between code and compiled ISOs. All the code is still available to everyone in the git repos (including all code for prior releases due to the way git keeps all history). Second, just because the old ISOs are no longer on the main download server doesn’t mean anyone is trying to “hide” them. I’m sure everyone would prefer for them to be readily available, but time and resources are always limited, so things always have to be prioritized. It makes sense to prioritize releases that people are actually using (and even many that reached EOL in the past few years) over ancient releases that are of mainly historical interest.

4 Likes
20

Update came today, 23 July.