Qubes-Whonix Development / Qubes Integration

Patrick · October 5, 2025, 3:53pm

Qubes Global Config: whonix UpdateVM can be set to "None"

opened 10:36AM - 03 Oct 25 UTC

C: Qubes GUI tools C: Whonix P: default needs diagnosis affects-4.2 community template

### Qubes OS release Qubes OS 4.2 ### Brief summary In the global config tool…, Whonix can be set to `None`: <img width="300px" alt="Image" src="https://github.com/user-attachments/assets/85952945-8d22-4302-88f9-9d249d320abf" /> When this is set the policy in `50-config-updates` then becomes broken because it gets `target=None`. ### Steps to reproduce 1. Open Qubes Global Config >> Updates (tab) 2. Change Whonix updateVM to be None 3. Apply ### Expected behavior It should get a deny policy (thus preventing updates in whonix-based templates) or the option to set it as `None` should be set as None. The later makes more sense for me, since the GUI tool is meant to help people with reasonably sane configuration. Fully disabling the UpdatesVM for Whonix feels like something nobody would normally want to achieve. ### Actual behavior Broken policy file in `/etc/qubes/policy.d/50-config-updates.policy` due to `target=None`: ``` # THIS IS AN AUTOMATICALLY GENERATED POLICY FILE. # Any changes made manually may be overwritten by Qubes Configuration Tools. qubes.UpdatesProxy * @tag:whonix-updatevm @default allow target=None qubes.UpdatesProxy * @type:TemplateVM @default allow target=sys-firewall ``` ### Additional information I believe the problematic code is [this line](https://github.com/QubesOS/qubes-desktop-linux-manager/blob/9ca765294d81e65bac266fc2ce9afe94282d43c5/qubes_config/global_config/updates_handler.py#L596), which enters python's `None` directly into the policy file.

Patrick · October 17, 2025, 3:25pm

github.com/QubesOS/qubes-issues

Whonix templates/standalones may bypass Tor due to unconfigured `default_dispvm` property

opened 12:48PM - 15 Oct 25 UTC

rustybird

C: core privacy C: Whonix P: default needs diagnosis affects-4.2 community template

### Qubes OS release R4.2 ### Brief summary qubes-core-admin-addon-whonix […sets](https://github.com/QubesOS/qubes-core-admin-addon-whonix/blob/v4.3.1/qubeswhonix/__init__.py#L51-L79) any Whonix Workstation based AppVM's `default_dispvm` property to a safe value. But the Whonix TemplateVMs themselves and hence StandaloneVMs cloned from them don't have such an explicitly configured value. They will fall back to the global `default_dispvm`, which may not be torified. This would allow these TemplateVMs/StandaloneVMs to bypass Tor, e.g. with `qvm-run-vm @dispvm 'curl -s https://check.torproject.org/api/ip'` ### Steps to reproduce $ qubes-prefs default_dispvm fedora-dvm $ qvm-clone --class=StandaloneVM whonix-workstation-17 standalone ### Expected behavior $ qvm-prefs whonix-workstation-17 | grep default_dispvm default_dispvm - whonix-workstation-17-dvm $ qvm-prefs standalone | grep default_dispvm default_dispvm - whonix-workstation-17-dvm `-` denotes an explicitly configured value. ### Actual behavior $ qvm-prefs whonix-workstation-17 | grep default_dispvm default_dispvm D fedora-dvm $ qvm-prefs standalone | grep default_dispvm default_dispvm D fedora-dvm `D` denotes fallback to a default value.

Patrick · October 22, 2025, 10:40am

github.com/QubesOS/updates-status

qubes-template-whonix-gateway-18 4.3.0-202510212050 (r4.3)

opened 08:50PM - 21 Oct 25 UTC

fepitre-bot

r4.3-testing

Template whonix-gateway-18 4.3.0-202510212050 for Qubes OS r4.3, see comments be…low for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.3 whonix-gateway-18 4.3.0-202510212050 templates-itl` (available 5 days from now) * `Upload-template r4.3 whonix-gateway-18 4.3.0-202510212050 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

github.com/QubesOS/updates-status

qubes-template-whonix-workstation-18 4.3.0-202510212050 (r4.3)

opened 09:14PM - 21 Oct 25 UTC

fepitre-bot

r4.3-testing

Template whonix-workstation-18 4.3.0-202510212050 for Qubes OS r4.3, see comment…s below for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.3 whonix-workstation-18 4.3.0-202510212050 templates-itl` (available 5 days from now) * `Upload-template r4.3 whonix-workstation-18 4.3.0-202510212050 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

Patrick · October 27, 2025, 6:58am

github.com/QubesOS/qubes-issues

Qubes policy editor: unexpected newline removal bug

opened 06:12AM - 27 Oct 25 UTC

adrelanos

P: default

### Qubes OS release R4.3 rc2 ### Brief summary Qubes policy editor is removi…ng newlines from configuration files. Why is that considered an issue? Because it makes configuration files that have not been edited appear as if they have been edited by the user from the perspective of the system package manager (`dnf`). This triggers special handling of configuration files. (`.rpmnew` files.) It's also a common convention on *nix. [1] [1] https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline ### Steps to reproduce I am not sure since I am only reporting and haven't reproduced this personally yet. Might be as simple as: 1. Open a file ins Qubes policy editor. 2. Close file. This means even if no edit was made, the file might still saved and the newline at the end removed. Or maybe. 1. Open a file ins Qubes policy editor. 2. Make an edit. 3. Close file. ### Expected behavior No newlines are removed at the end of the file. ### Actual behavior Newline at the end of the file is being removed. ### Additional information Originally reported by @alimirjamali in qubes-public on matrix. Seemed to be consensus that this is a bug indeed and that it should be fixed.

github.com/QubesOS/qubes-issues

reliably update dom0 qrexec policy configuration files - use `config` instead of `config(noreplace)`

opened 06:58AM - 27 Oct 25 UTC

adrelanos

P: default

### Qubes OS release R4.3 ### Brief summary When Qubes dom0 qrexec configurat…ion files are updated that have been user modified [1], changes by Qubes are sometimes not applied. [1] Also bug https://github.com/QubesOS/qubes-issues/issues/10354 can make configuration files appear user modified while they have not been actually user modified. ### Steps to reproduce 1. Edit a Qubes dom0 qrexec configuration file. 2. Update dom0. ### Expected behavior Users are expecting things to "just work", i.e. in slightly more technical terms, files are updated and merged without loosing user customization. ### Actual behavior Some configuration files might not get not updated. Instead `dnf` will place `.rpmnew` file is placed in the same folder. This is the result of `config(noreplace)`. ### Additional information Suggested changes: * Add a comment to all Qubes dom0 qrexec configuration files that advises the user to use their own configuration file instead of editing an existing configuration file directly. * Use `config` instead of `config(noreplace)`. The idea of using `config` instead of `config(noreplace)` has been floated by @marmarek on Matrix in qubes-public.

Patrick · October 30, 2025, 5:07am

github.com/QubesOS/qubes-core-agent-linux

Start qubes-bind-dirs.service before systemd-tmpfiles-setup.service

main ← ArrayBolt3:arraybolt3/bind-dirs-timing

opened 11:27PM - 23 Oct 25 UTC

ArrayBolt3

+1 -1

tmpfiles.d may contain configuration to "fix" the permissions on some directorie…s (like /var/lib/sdwdate on Whonix-Gateway qubes) in the event an app qube's template is changed and the UIDs/GIDs for some users in the original template do not match the UIDs/GIDs for the same users in the new template. This requires that bind mounts from /rw are set up before systemd-tmpfiles runs, so ensure that the units run in that order.

Patrick · October 31, 2025, 3:03pm

github.com/QubesOS/qubes-core-agent-linux

Use socks5 proxy on Whonix Gateway to fix onion urls resolution

main ← marmarek:dom0-updates-whonix

opened 09:56PM - 22 Oct 25 UTC

marmarek

+16 -0

When sys-whonix is used as updatevm, with repositories set to onion addresses, D…NF (or rather curl) refuse to resolve the addresses, even though it is talking to Tor. See https://github.com/curl/curl/discussions/11125 Fix this by setting socks proxy explicitly. Use socks5h:// protocol to really delegate hostname resolution to the server. Do the same in qvm-template-repo-query (qubes.TemplateSearch and qubes.TemplateDownload services), as they also use dnf and curl. QubesOS/qubes-issues#10253

Patrick · November 21, 2025, 3:32pm

github.com/QubesOS/qubes-issues

Integration tests sometimes show VMs randomly experiencing severe delays, contributing to Whonix test timeouts

opened 06:02AM - 21 Nov 25 UTC

ArrayBolt3

P: default

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) ###… Qubes OS release 4.3 ### Brief summary I've been attempting to fix some integration tests that were failing with Whonix. Marek pointed out on one of these tests that [Whonix seemed to boot extremely slowly](https://github.com/QubesOS/qubes-issues/issues/10349#issue-3549037096) at least one time. When looking at https://openqa.qubes-os.org/tests/159131, I noticed that there were some strange delays happening sporadically to all qubes, not just Whonix qubes. ### Steps to reproduce Unknown, observed in OpenQA. ### Expected behavior VMs should always take about the same amount of time to boot so performance tests can accurately gauge how fast the VMs run. ### Actual behavior VMs sometimes have strange delays during bootup which may make performance tests fail when they shouldn't have. ### Additional information The logs I looked at are https://openqa.qubes-os.org/tests/159131/file/system_tests-var_log.tar.gz * Almost all VMs take between <1 and ~4 seconds to load their kernel (the duration from the "Logfile Opened" line to the `[ 0.000000] Linux version 6.12.54-1.qubes.fc41.x86_64 (mockbuild@edb7235ecafd4997983b05e6aaa61fcf) (gcc (GCC) 14.3.1 20250808 (Red Hat 14.3.1-3), GNU ld version 2.43-2.fc41) #1 SMP PREEMPT_DYNAMIC Thu Oct 23 04:39:22 UTC 2025` or similar line * Out of 107 VM boots, 11 of them had a kernel load time higher than 4 seconds. Of those, 5 were Fedora Linux 42, 3 where Debian 13, 2 were Whonix-Gateway, and 1 was Whonix-Workstation. * Five of these slow kernel loads coincide with >=60-second DispVM runtime, one being Fedora Linux 42, one being Debian 13, two being Whonix-Gateway, and one being Whonix-Workstation. ``` guest-disp2246.log (Fedora Linux 42, 7 second kernel load time, 1 second from "Qubes: done" to disk mount, login prompt, 35 second runtime) guest-disp3748.log (Fedora Linux 42, 6 second kernel load time, 2 seconds from "Qubes: done" to disk mount, login prompt, 66 second runtime) guest-disp5735.log (Fedora Linux 42, 7 second kernel load time, 2 seconds from "Qubes: done" to disk mount, login prompt, 29 second runtime) guest-disp5839.log (Debian 13, 6 second kernel load time, 9 seconds from "Qubes: done" to disk mount, login prompt (barely), 60 second runtime) guest-disp5955.log (Whonix-Gateway 18, 9 second kernel load time, 12 seconds from "Qubes: done" to disk mount, no login prompt, 81 second runtime) guest-disp6231.log (Whonix-Gateway 17, 7 second kernel load time, 3 seconds from "Qubes: done" to disk mount, login prompt, 62 second runtime) guest-disp6497.log (Debian 13, 6 second kernel load time, 8 seconds from "Qubes: done" to disk mount, login prompt (barely), 39 second runtime) guest-disp678.log (Fedora Linux 42, 8 second kernel load time, 4 seconds from "Qubes: done" to disk mount, login prompt (barely), 39 second runtime) guest-disp7152.log (Whonix-Workstation 18, 7 second kernel load time, 6 seconds from "Qubes: done" to disk mount, no login prompt, 70 second runtime) guest-disp9514.log (Debian 13, 5 second kernel load time, 6 seconds from "Qubes: done" to disk mount, login prompt (barely), 43 second runtime) guest-sys-net.log (Fedora Linux 42, 6 second kernel load time, 0 seconds from "Qubes: done" to disk mount, login prompt, hours long runtime for obvious reasons) ```

Patrick · November 29, 2025, 12:32pm

github.com/QubesOS/updates-status

qubes-template-whonix-gateway-18 4.3.0-202511271158 (r4.3)

opened 12:54PM - 27 Nov 25 UTC

fepitre-bot

r4.3-testing

Template whonix-gateway-18 4.3.0-202511271158 for Qubes OS r4.3, see comments be…low for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.3 whonix-gateway-18 4.3.0-202511271158 templates-itl` (available 5 days from now) * `Upload-template r4.3 whonix-gateway-18 4.3.0-202511271158 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

github.com/QubesOS/updates-status

qubes-template-whonix-workstation-18 4.3.0-202511282227 (r4.3)

opened 10:27PM - 28 Nov 25 UTC

fepitre-bot

r4.3-testing

Template whonix-workstation-18 4.3.0-202511282227 for Qubes OS r4.3, see comment…s below for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.3 whonix-workstation-18 4.3.0-202511282227 templates-itl` (available 5 days from now) * `Upload-template r4.3 whonix-workstation-18 4.3.0-202511282227 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

Patrick · December 7, 2025, 10:46am

github.com/QubesOS/qubes-core-admin-addon-whonix

Respect user's choice of netvm and default_dispvm

main ← ben-grande:dvm

opened 02:29PM - 18 Sep 25 UTC

ben-grande

+191 -82

I noticed during preload tests that my Whonix qubes properties were being overri…dden. Setting a feature on the template is not the best option, seen that it doesn't consider multi-VM setups where there can be multiple disposable templates. The order is as follows: - None if current property is None; - Current property if it asks Netvm it is a Gateway, itself it it asks for a DVM and it is a Workstation or current property if it asks for a DVM and it is a Workstation; - Check for features in template chain; and - Fallback to hardcoded values

Patrick · December 7, 2025, 10:47am

github.com/QubesOS/qubes-issues

Whonix based standalone VMs lack anon-vm tag which causes denied notification messages

opened 02:45PM - 14 Oct 24 UTC

closed 03:20AM - 04 Dec 25 UTC

adventureru

C: Whonix P: default diagnosed pr submitted affects-4.2 affects-4.3 community template

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) #…## Qubes OS release 4.2.3 ### Brief summary Creating a standalone Whonix VM causes "Denied whonix.NewStatus+status from `my-standalone-test-qube` to` sys-whonix`" notification messages because the newly created standalone does not have the anon-vm tag upon creation. The problem is solved my manually adding the tag anon-vm. ### Steps to reproduce Create a standalone based on whonix-workstation-17, boot. ### Expected behavior No denied messages, the VM is given appropriate tags upon creation. ### Actual behavior The VM lacks tags that it expects and produces denied notification messages.

Patrick · December 8, 2025, 2:09pm

github.com/QubesOS/updates-status

qubes-template-whonix-gateway-18 4.3.0-202512071252 (r4.3)

opened 01:28PM - 07 Dec 25 UTC

fepitre-bot

r4.3-testing

Template whonix-gateway-18 4.3.0-202512071252 for Qubes OS r4.3, see comments be…low for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.3 whonix-gateway-18 4.3.0-202512071252 templates-itl` (available 5 days from now) * `Upload-template r4.3 whonix-gateway-18 4.3.0-202512071252 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

Success. Needs testing.

github.com/QubesOS/updates-status

qubes-template-whonix-workstation-18 4.3.0-202512071252 (r4.3)

opened 01:56PM - 07 Dec 25 UTC

fepitre-bot

r4.3-failed

Template whonix-workstation-18 4.3.0-202512071252 for Qubes OS r4.3, see comment…s below for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.3 whonix-workstation-18 4.3.0-202512071252 templates-itl` (available 5 days from now) * `Upload-template r4.3 whonix-workstation-18 4.3.0-202512071252 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

Build failed.

Patrick · December 12, 2025, 2:44pm

github.com/QubesOS/updates-status

qubes-template-whonix-workstation-18 4.3.0-202512111204 (r4.3)

opened 12:05PM - 11 Dec 25 UTC

fepitre-bot

r4.3-testing

Template whonix-workstation-18 4.3.0-202512111204 for Qubes OS r4.3, see comment…s below for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.3 whonix-workstation-18 4.3.0-202512111204 templates-itl` (available 5 days from now) * `Upload-template r4.3 whonix-workstation-18 4.3.0-202512111204 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

Patrick · January 25, 2026, 10:32am

github.com/QubesOS/qubes-issues

Keyboard layout switching in AppVMs is broken when using the Plasma X11 session

opened 01:40AM - 13 Jan 26 UTC

ArrayBolt3

C: desktop-linux-kde P: default needs diagnosis affects-4.3

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) ###… Qubes OS release R4.3 ### Brief summary If using the KDE session in dom0, it is not possible to switch keyboard layouts in individual AppVMs by configuring the layouts in dom0, and then using the keyboard layout switching key (by default Meta+Alt+K) to switch layouts. KDE claims that the keyboard layout is being switched, but AppVMs do not receive events signalling the change. ### Steps to reproduce 1. Install KDE Plasma in dom0 by running `sudo qubes-dom0-update kde-settings-qubes`. 2. Log out of dom0. 3. At the dom0 login screen, choose the Plasma (X11) session in LightDM and log in. 4. Open KDE System Settings, enable multiple keyboard layouts, add German as a second layout in addition to English, ensure that the key combo for changing keyboard layouts is set to "Meta+Alt+K" as expected, then click "Apply". 5. Install the `debian-13-minimal` template. 6. Launch XTerm in the `debian-13-minimal` template. 7. While the keyboard layout is in English, type a semicolon into the XTerm window. 8. Press Meta+Alt+K to change the keyboard layout to German, and ensure KDE reports that the keyboard layout has changed. 9. Press the same key you used to type a semicolon while the XTerm window is focused. ### Expected behavior An `ö` character should be typed into XTerm. ### Actual behavior A semicolon is typed into XTerm. ### Additional information If I run `sh -x /usr/lib/qubes/qubes-keymap.sh` in the `debian-13-minimal` XTerm window, I see text printed in the terminal when I first launch the script, but I don't see any new text appear when I press the keyboard layout change shortcut. In contrast, if I configure two keyboard layouts in dom0 using the Xfce session, and then press the keyboard layout change shortcut while `sh -x /usr/lib/qubes/qubes-keymap.sh` is running in `debian-13-minimal`, I see additional text printed every time I press the layout change shortcut. This makes me think dom0 is not sending keyboard layout change events to VMs when the KDE session is being used.

Patrick · January 31, 2026, 8:10am

github.com/QubesOS/qubes-issues

port Whonix documentation from state.sls to state.apply

opened 08:10AM - 31 Jan 26 UTC

adrelanos

P: default

### Qubes OS release R4.3 ### Brief summary port Whonix documentation from `s…tate.sls` to `state.apply` ### Steps to reproduce Search Whonix wiki. ### Expected behavior Using `state.apply`. ### Actual behavior Using `state.sls`. ### The value to a user Consistency with Qubes documentation and conventions. ### Additional information Quote @ben-grande in https://github.com/QubesOS/qubes-issues/issues/2157#issuecomment-3766843709 > Whonix documentation uses `state.sls` today: https://www.whonix.org/wiki/Qubes/Install. I believe it is best to use it (or the newer version `state.apply`, instead of of `highstate` for documentation. The highstate requires a bit of work to check if nothing else will apply. > > The Qubes docs don't use Salt anymore for reinstalling a template: https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to-reinstall-a-template.html ---- Whonix documentation uses `state.sls` in quite a few places. https://www.whonix.org/w/index.php?search=state.sls&title=Special%3ASearch&go=Go ---- [Dev/Qubes](https://www.whonix.org/wiki/Dev/Qubes) ...es R4 This is what <code>sudo qubesctl state.sls qvm.{{projectnameworkstationvm}}</co... [Old Stable and Earlier Releases](https://www.whonix.org/wiki/OldStableandEarlierReleases) ...and failure when running <code>qubesctl state.sls qvm.{{projectnameworkstationvm}}</co... [Qubes/Disposables](https://www.whonix.org/wiki/Qubes/Disposables) ...late. {{CodeSelect|code=sudo qubesctl state.sls qvm.whonix-workstation-dvm}} '''4.'''... [Qubes/Reinstall](https://www.whonix.org/wiki/Qubes/Reinstall) .../ref> {{CodeSelect|code=sudo qubesctl state.sls qvm.{{projectnameworkstationvm}}}}... [Qubes/UpdatesProxy](https://www.whonix.org/wiki/Qubes/UpdatesProxy) .../ref> {{CodeSelect|code=sudo qubesctl state.sls qvm.{{projectnameworkstationvm}}}}... [Template:Qubes Download Install](https://www.whonix.org/wiki/Template:QubesDownloadInstall) .../ref> {{CodeSelect|code=sudo qubesctl state.sls qvm.{{projectnameworkstationvm}}}}... [Template:Qubes Install DVM](https://www.whonix.org/wiki/Template:QubesInstallDVM) ...run. {{CodeSelect|code=sudo qubesctl state.sls qvm.whonix-workstation-dvm}} [Template:Qubes Install Updates over Tor](https://www.whonix.org/wiki/Template:QubesInstallUpdatesoverTor) .../ref> {{CodeSelect|code=sudo qubesctl state.sls qvm.updates-via-whonix}} To undo this... ---- > The Qubes docs don't use Salt anymore for reinstalling a template: https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to-reinstall-a-template.html But Whonix documentation should continue to use salt for installing Templates?

Patrick · February 15, 2026, 4:21pm

Patrick · February 19, 2026, 9:23am

Patrick · February 20, 2026, 7:07pm

Patrick · February 24, 2026, 7:07pm

github.com/QubesOS/updates-status

qubes-template-whonix-gateway-18 4.3.0-202602202037 (r4.3)

opened 09:21PM - 20 Feb 26 UTC

fepitre-bot

r4.3-testing

Template whonix-gateway-18 4.3.0-202602202037 for Qubes OS r4.3, see comments be…low for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.3 whonix-gateway-18 4.3.0-202602202037 templates-itl` (available 5 days from now) * `Upload-template r4.3 whonix-gateway-18 4.3.0-202602202037 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

github.com/QubesOS/updates-status

qubes-template-whonix-workstation-18 4.3.0-202602221542 (r4.3)

opened 03:43PM - 22 Feb 26 UTC

fepitre-bot

r4.3-testing

Template whonix-workstation-18 4.3.0-202602221542 for Qubes OS r4.3, see comment…s below for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.3 whonix-workstation-18 4.3.0-202602221542 templates-itl` (available 5 days from now) * `Upload-template r4.3 whonix-workstation-18 4.3.0-202602221542 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

Patrick · February 28, 2026, 7:05pm

Patrick · March 14, 2026, 8:27am

github.com/QubesOS/qubes-issues

Rare `/tmp/user/1000 owned by uid 0 instead of uid 1000` when libpam-tmpdir is installed on debian-13-xfce

opened 03:29PM - 12 Mar 26 UTC

ArrayBolt3

C: Debian/Ubuntu P: default needs diagnosis affects-4.3

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) ###… Qubes OS release R4.3 ### Brief summary If libpam-tmpdir is installed in a Debian-based qube, every so often an error will appear in the journal, `/tmp/user/1000 owned by uid 0 instead of uid 1000`. When this happens, `/tmp/user/1000` will strangely be owned by UID 1000, but GID 0, despite what the error message shows. This was first noticed on Whonix, but it turns out to be reproducible outside of Whonix as well. ### Steps to reproduce 1. Install `libpam-tmpdir` on debian-13-xfce. 2. Create an AppVM based upon it, named `debian-hammer`. 3. Place the following script in dom0's home folder: ``` #!/bin/bash while true; do qvm-start debian-hammer qvm-run debian-hammer xfce4-terminal >/dev/null 2>&1 & sleep 2 capture="$(qvm-run -u root --pass-io debian-hammer 'journalctl --boot | grep -i "owned by uid"' 2>&1)" if [ -n "${capture}" ]; then printf '%s\n' "${capture}" exit 1 fi qvm-shutdown --wait debian-hammer done ``` 4. Leave the script to run overnight, `debian-hammer`'s xfce4-terminal window will appear and disappear during the test process ### Expected behavior The script should loop forever. ### Actual behavior The script stops looping and prints the error message mentioned above. ### Additional information I have attempted to reproduce this outside of Qubes (using a Debian 13 KVM virtual machine, CLI-only and LXQt variants) without success. The VM endlessly reboots and the error message never shows up in the journal.