Qubes OS 4.3.2-rc1 is now open for testing
The patch release upgrades the default Fedora template to 44 and the kernel to Linux 7.2. Stable is targeted for the end of September, and the team doesn't expect a second RC.
Qubes OS 4.3.2-rc1 is out. The Qubes team shipped the first release candidate on September 18, and it's a patch release in the truest sense, which meant to consolidate everything published since the last stable build, 4.3.1. Not a rewrite. A consolidation.
Two upgrades stand out. The default Fedora template jumps to Fedora 44, up from 43. The kernel-latest package now carries Linux 7.2. Everything else is a pile of bug fixes accumulated across roughly the last three months.
The team says it doesn't anticipate needing a second RC. It expects stable 4.3.2 around the end of September. The changes, per the project itself, are "relatively minor." That's a calm way to describe a build that's still, technically, not stable.
What this actually is
Under Qubes's own versioning rules, 4.3.2 doesn't open a new line. It's the 4.3 series, taken up to a specific date. An up-to-date 4.3 install is "essentially equivalent" to 4.3.2. A fresh ISO mainly matters if you're reinstalling from scratch or want to sanity-check the installer.
Keep in mind that rc1 is not for your daily driver. It's aimed at advanced or "adventurous" testers willing to chase bugs that might still be lurking.
You have two paths. A clean install exercises more ground, including the install procedure itself, but it demands a full backup first and an immediate dom0 update to pull all available fixes.
The in-place route is simpler but covers less. And since a fully-updated 4.3 install already amounts to nearly the same thing, you have to ask whether testing rc1 this way actually buys you anything.
Two real fixes in the batch
The interesting part is probably the security side. This release window overlaps with two advisories that hit Qubes components directly, and both would already be inside a fully-updated 4.3 or 4.3.2 system.
QSB-119, published September 15, concerns qvm-open-in-vm. Open a file with an attacker-controlled filename through that tool, or via its "Edit in disposable qube" integration, and an attacker might run code in the target qube. The fix lives in qubes-core-agent 4.3.48.
Here's the nuance. Only Debian templates were affected. Fedora packages were shielded by _FORTIFY_SOURCE hardening, which Debian packages missed due to a build-script interaction. The first reporter only got the exploit working in under 3 percent of attempts, and even then needed a path stuffed with format specifiers. Not exactly a plug-and-play attack. Still, worth the fix.
QSB-118 is the more uncomfortable one. Discovered by Tim C., it's a dom0 arbitrary code execution buried in qvm-copy-to-vm's error reporting. sanitize_remote_filename() strips non-ASCII characters and double quotes but leaves shell metaracters in place. That name then gets handed to system() when the error dialog renders.
Copy a file from dom0 to a compromised qube, and that qube can inject a command straight into dom0. dom0 compromise is about as bad as OS-level exploits get. The VM variant escaped untouched because it uses execlp rather than system(). The dom0 fix sits in qubes-core-dom0-linux 4.3.22.
Known issue and how to test
One bug is worth flagging before you dive in. Templates restored from a pre-4.3 backup can keep pointing at their old release repositories. Fresh templates on a clean 4.3.2 system are unaffected. It's the same problem that bit 4.3.1, where the team shipped qubes-dist-upgrade commands as a remedy.
Head here to the downloads page if you want to try the ISO. Testers are asked to file bugs through the issue tracker, and experienced users are encouraged to join the testing team on the Qubes forum.
As for the team's confidence in a clean single-RC path to a stable build. That's exactly what the community testing process exists to verify. The Fedora 44 migration and Linux 7.2 kernel bump are the real test. Give it a few weeks and see if the optimism holds up.
