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.