From a78075a4429b91aba7e1f1d6ccb1018fd8086605 Mon Sep 17 00:00:00 2001
From: zetigu <81594452+zetigu@users.noreply.github.com>
Date: Thu, 1 Apr 2021 18:18:49 -0400
Subject: [PATCH 001/332] Add instruction for using Btrfs as a qvm-pool

I reformated the article to devide it in 2 section, one concerning LVM pools and the other Btrfs pool.
The synthax should be close to the original.
Awaiting comments.
---
 .../secondary-storage.md                      | 79 ++++++++++++++++++-
 1 file changed, 76 insertions(+), 3 deletions(-)

diff --git a/user/advanced-configuration/secondary-storage.md b/user/advanced-configuration/secondary-storage.md
index 90faca71..8de061cd 100644
--- a/user/advanced-configuration/secondary-storage.md
+++ b/user/advanced-configuration/secondary-storage.md
@@ -20,6 +20,24 @@ You want to store a subset of your AppVMs on the HDD.
 Qubes 4.0 is more flexible than earlier versions about placing different VMs on different disks.
 For example, you can keep templates on one disk and AppVMs on another, without messy symlinks.
 
+You can query qvm-pool to list available storage drivers.
+
+```
+qvm-pool --help-drivers
+```
+qvm-pool driver explaination :
+```
+<file> refers to using a simple file for image storage and lacks a few features.
+<file-reflink> refers to storing images on a filesystem supporting copy on write.
+<linux-kernel> refers to a directory holding kernel images.
+<lvm_thin> refers to LVM managed pools.
+```
+In theory, you can still use file-based disk images ("file" pool driver), but it lacks some features such as you won't be able to do backups without shutting down the qube.
+
+Additionnal storage can also be added on a Btrfs filesystem. A unique feature of Btrfs over LVM is that data can be compressed transparently. The subvolume can also be backuped using snapshots for an other layer protection and Btrfs supports different level of redundancy and is able to be expanded/shrinked easily. Revelant information will be provided after LVM section.
+
+### LVM storage
+
 These steps assume you have already created a separate [volume group](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/vg_admin#VG_create) and [thin pool](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/thinly_provisioned_volume_creation) (not thin volume) for your HDD.
 See also [this example](https://www.linux.com/blog/how-full-encrypt-your-linux-system-lvm-luks) if you would like to create an encrypted LVM pool (but note you can use a single logical volume if preferred, and to use the `-T` option on `lvcreate` to specify it is thin). You can find the commands for this example applied to Qubes at the bottom of this R4.0 section.
 
@@ -39,6 +57,24 @@ Take note of the VG and thin pool names for your HDD, then register it with Qube
 qvm-pool --add <pool_name> lvm_thin -o volume_group=<vg_name>,thin_pool=<thin_pool_name>,revisions_to_keep=2
 ```
 
+### BTRFS storage
+Theses steps assume you have already created a separate Btrfs filesystem for your HDD, that it is encrypted with LUKS and it is mounted. It is recommended to use a subvolume as it enables compression and excess storage can be use for other things.
+
+
+It is possible to use already available Btrfs storage if it is configured. In dom0, available Btrfs storage can be displayed using :
+```
+mount -t btrfs
+```
+To register the storage to qubes :
+
+```shell_session
+# <pool_name> is a freely chosen pool name
+# <dir_path> is the mounted path to the second btrfs storage
+qvm-pool --add <pool_name> file-reflink -o dir_path=<dir_path>,revisions_to_keep=2
+```
+
+#### Using the new pool
+
 Now, you can create qubes in that pool:
 
 ```
@@ -59,9 +95,7 @@ For example:
 qvm-prefs <appvmname_based_on_old_template> template <new_template_name>
 ```
 
-In theory, you can still use file-based disk images ("file" pool driver), but it lacks some features such as you won't be able to do backups without shutting down the qube.
-
-### Example HDD setup
+#### Example HDD setup
 
 Assuming the secondary hard disk is at /dev/sdb (it will be completely erased), you can set it up for encryption by doing in a dom0 terminal (use the same passphrase as the main Qubes disk to avoid a second password prompt at boot):
 
@@ -84,6 +118,8 @@ luks-b20975aa-8318-433d-8508-6c23982c6cde UUID=b20975aa-8318-433d-8508-6c23982c6
 
 Reboot the computer so the new luks device appears at /dev/mapper/luks-b209... and we can then create its pool, by doing this on a dom0 terminal (substitute the b209... UUIDs with yours):
 
+##### For LVM
+
 First create the physical volume
 
 ```
@@ -107,6 +143,40 @@ Finally we will tell Qubes to add a new pool on the just created thin pool
 ```
 qvm-pool --add poolhd0_qubes lvm_thin -o volume_group=qubes,thin_pool=poolhd0,revisions_to_keep=2
 ```
+#### For Btrfs
+
+First create the physical volume
+
+```
+# <label> Btrfs Label
+sudo mkfs.btrfs -L <label> /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde
+```
+
+Then mount the new Btrfs to a temporary path
+
+```
+sudo mount /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde /mnt/new_qube_storage
+```
+Create a subvolume to hold the data. 
+```
+sudo btrfs subvolume create /mnt/new_qube_storage/qubes
+```
+Unmount the temporary Btrfs filesystem
+```
+sudo umount /mnt/new_qube_storage
+```
+Mount the subvolume with compression enabled if desired
+```
+# <compression> zlib|lzo|zstd
+# <subvol> btrfs subvolume "qubes" in this example
+sudo mount /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde /var/lib/qubes_newpool -o compress=<compression>,subvol=qubes
+```
+
+Finally we will tell Qubes to add a new pool on the just created Btrfs subvolume
+
+```
+qvm-pool --add poolhd0_qubes file-reflink -o dir_path=/var/lib/qubes_newpool,revisions_to_keep=2
+```
 
 By default VMs will be created on the main Qubes disk (i.e. a small SSD), to create them on this secondary HDD do the following on a dom0 terminal:
 
@@ -114,5 +184,8 @@ By default VMs will be created on the main Qubes disk (i.e. a small SSD), to cre
 qvm-create -P poolhd0_qubes --label red unstrusted-hdd
 ```
 
+Verify that corresponding lines to /etc/fstab and /etc/cryptab where added to enable auto mounting of the new pool.
+
+
 [Qubes Backup]: /doc/BackupRestore/
 [TemplateVM]: /doc/Templates/

From 8de70db07872ca1f874a384390adc3c8b9d522b0 Mon Sep 17 00:00:00 2001
From: zetigu <81594452+zetigu@users.noreply.github.com>
Date: Fri, 2 Apr 2021 08:46:44 -0400
Subject: [PATCH 002/332] Clarification in introduction

More descriptive advantages of using Btrfs
---
 user/advanced-configuration/secondary-storage.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/advanced-configuration/secondary-storage.md b/user/advanced-configuration/secondary-storage.md
index 8de061cd..fd0594f2 100644
--- a/user/advanced-configuration/secondary-storage.md
+++ b/user/advanced-configuration/secondary-storage.md
@@ -34,7 +34,7 @@ qvm-pool driver explaination :
 ```
 In theory, you can still use file-based disk images ("file" pool driver), but it lacks some features such as you won't be able to do backups without shutting down the qube.
 
-Additionnal storage can also be added on a Btrfs filesystem. A unique feature of Btrfs over LVM is that data can be compressed transparently. The subvolume can also be backuped using snapshots for an other layer protection and Btrfs supports different level of redundancy and is able to be expanded/shrinked easily. Revelant information will be provided after LVM section.
+Additionnal storage can also be added on a Btrfs filesystem. A unique feature of Btrfs over LVM is that data can be compressed transparently. The subvolume can also be backuped using snapshots for an additionnal layer of protection; Btrfs supports differents level of redundancy; it has parity checksum; it is able to be expanded/shrinked. Starting/stoping a VM has less impact and less chances of causing slowdown of the system as some have noted with LVM. Revelant information for general btrfs configuration will be provided after LVM section.
 
 ### LVM storage
 

From 6479d371b9a311f6ea1ffc83b54177311b8bb84f Mon Sep 17 00:00:00 2001
From: zetigu <81594452+zetigu@users.noreply.github.com>
Date: Fri, 2 Apr 2021 08:50:03 -0400
Subject: [PATCH 003/332] Add shell_session to terminal box

Added a shell_session to the ``` of the first line.
---
 .../secondary-storage.md                      | 40 +++++++++----------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/user/advanced-configuration/secondary-storage.md b/user/advanced-configuration/secondary-storage.md
index fd0594f2..c5fd4248 100644
--- a/user/advanced-configuration/secondary-storage.md
+++ b/user/advanced-configuration/secondary-storage.md
@@ -22,11 +22,11 @@ For example, you can keep templates on one disk and AppVMs on another, without m
 
 You can query qvm-pool to list available storage drivers.
 
-```
+``` shell_session
 qvm-pool --help-drivers
 ```
 qvm-pool driver explaination :
-```
+```shell_session
 <file> refers to using a simple file for image storage and lacks a few features.
 <file-reflink> refers to storing images on a filesystem supporting copy on write.
 <linux-kernel> refers to a directory holding kernel images.
@@ -43,7 +43,7 @@ See also [this example](https://www.linux.com/blog/how-full-encrypt-your-linux-s
 
 First, collect some information in a dom0 terminal:
 
-```
+```shell_session
 sudo pvs
 sudo lvs
 ```
@@ -62,7 +62,7 @@ Theses steps assume you have already created a separate Btrfs filesystem for you
 
 
 It is possible to use already available Btrfs storage if it is configured. In dom0, available Btrfs storage can be displayed using :
-```
+```shell_session
 mount -t btrfs
 ```
 To register the storage to qubes :
@@ -77,13 +77,13 @@ qvm-pool --add <pool_name> file-reflink -o dir_path=<dir_path>,revisions_to_keep
 
 Now, you can create qubes in that pool:
 
-```
+```shell_session
 qvm-create -P <pool_name> --label red <vmname>
 ```
 
 It isn't possible to directly migrate an existing qube to the new pool, but you can clone it there, then remove the old one:
 
-```
+```shell_session
 qvm-clone -P <pool_name> <sourceVMname> <cloneVMname>
 qvm-remove <sourceVMname>
 ```
@@ -91,7 +91,7 @@ qvm-remove <sourceVMname>
 If that was a template, or other qube referenced elsewhere (NetVM or such), you will need to adjust those references manually after moving.
 For example:
 
-```
+```shell_session
 qvm-prefs <appvmname_based_on_old_template> template <new_template_name>
 ```
 
@@ -99,20 +99,20 @@ qvm-prefs <appvmname_based_on_old_template> template <new_template_name>
 
 Assuming the secondary hard disk is at /dev/sdb (it will be completely erased), you can set it up for encryption by doing in a dom0 terminal (use the same passphrase as the main Qubes disk to avoid a second password prompt at boot):
 
-```
+```shell_session
 sudo cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sdb
 sudo blkid /dev/sdb
 ```
 
 Note the device's UUID (in this example "b209..."), we will use it as its luks name for auto-mounting at boot, by doing:
 
-```
+```shell_session
 sudo nano /etc/crypttab
 ```
 
 And adding this line (change both "b209..." for your device's UUID from blkid) to crypttab:
 
-```
+```shell_session
 luks-b20975aa-8318-433d-8508-6c23982c6cde UUID=b20975aa-8318-433d-8508-6c23982c6cde none
 ```
 
@@ -122,39 +122,39 @@ Reboot the computer so the new luks device appears at /dev/mapper/luks-b209... a
 
 First create the physical volume
 
-```
+```shell_session
 sudo pvcreate /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde
 ```
 
 Then create the LVM volume group, we will use for example "qubes" as the <vg_name>:
 
-```
+```shell_session
 sudo vgcreate qubes /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde
 ```
 
 And then use "poolhd0" as the <thin_pool_name> (LVM thin pool name):
 
-```
+```shell_session
 sudo lvcreate -T -n poolhd0 -l +100%FREE qubes
 ```
 
 Finally we will tell Qubes to add a new pool on the just created thin pool
 
-```
+```shell_session
 qvm-pool --add poolhd0_qubes lvm_thin -o volume_group=qubes,thin_pool=poolhd0,revisions_to_keep=2
 ```
 #### For Btrfs
 
 First create the physical volume
 
-```
+```shell_session
 # <label> Btrfs Label
 sudo mkfs.btrfs -L <label> /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde
 ```
 
 Then mount the new Btrfs to a temporary path
 
-```
+```shell_session
 sudo mount /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde /mnt/new_qube_storage
 ```
 Create a subvolume to hold the data. 
@@ -162,11 +162,11 @@ Create a subvolume to hold the data.
 sudo btrfs subvolume create /mnt/new_qube_storage/qubes
 ```
 Unmount the temporary Btrfs filesystem
-```
+```shell_session
 sudo umount /mnt/new_qube_storage
 ```
 Mount the subvolume with compression enabled if desired
-```
+```shell_session
 # <compression> zlib|lzo|zstd
 # <subvol> btrfs subvolume "qubes" in this example
 sudo mount /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde /var/lib/qubes_newpool -o compress=<compression>,subvol=qubes
@@ -174,13 +174,13 @@ sudo mount /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde /var/lib/qubes_
 
 Finally we will tell Qubes to add a new pool on the just created Btrfs subvolume
 
-```
+```shell_session
 qvm-pool --add poolhd0_qubes file-reflink -o dir_path=/var/lib/qubes_newpool,revisions_to_keep=2
 ```
 
 By default VMs will be created on the main Qubes disk (i.e. a small SSD), to create them on this secondary HDD do the following on a dom0 terminal:
 
-```
+```shell_session
 qvm-create -P poolhd0_qubes --label red unstrusted-hdd
 ```
 

From 32e728d8a95285bcc96e1c171ff0cf0aacef2dcb Mon Sep 17 00:00:00 2001
From: zetigu <81594452+zetigu@users.noreply.github.com>
Date: Fri, 2 Apr 2021 08:51:33 -0400
Subject: [PATCH 004/332] Add btrfs filesystem show line

Added one btrfs filesystem show line for displaying available btrfs filesystems.
---
 user/advanced-configuration/secondary-storage.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/user/advanced-configuration/secondary-storage.md b/user/advanced-configuration/secondary-storage.md
index c5fd4248..3fbf22b1 100644
--- a/user/advanced-configuration/secondary-storage.md
+++ b/user/advanced-configuration/secondary-storage.md
@@ -64,6 +64,7 @@ Theses steps assume you have already created a separate Btrfs filesystem for you
 It is possible to use already available Btrfs storage if it is configured. In dom0, available Btrfs storage can be displayed using :
 ```shell_session
 mount -t btrfs
+btrfs show filesystem
 ```
 To register the storage to qubes :
 

From 75d18931d11ba8c634b5710ad37d365667a8764b Mon Sep 17 00:00:00 2001
From: zetigu <81594452+zetigu@users.noreply.github.com>
Date: Fri, 2 Apr 2021 09:00:36 -0400
Subject: [PATCH 005/332] Normalize punctuation and create/remove tmp dir

Mostly fix before console text by using ":" without space.
Create/remove /mnt/new_qube_storage
---
 .../secondary-storage.md                      | 27 ++++++++++---------
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/user/advanced-configuration/secondary-storage.md b/user/advanced-configuration/secondary-storage.md
index 3fbf22b1..eedf2526 100644
--- a/user/advanced-configuration/secondary-storage.md
+++ b/user/advanced-configuration/secondary-storage.md
@@ -20,12 +20,12 @@ You want to store a subset of your AppVMs on the HDD.
 Qubes 4.0 is more flexible than earlier versions about placing different VMs on different disks.
 For example, you can keep templates on one disk and AppVMs on another, without messy symlinks.
 
-You can query qvm-pool to list available storage drivers.
+You can query qvm-pool to list available storage drivers:
 
 ``` shell_session
 qvm-pool --help-drivers
 ```
-qvm-pool driver explaination :
+qvm-pool driver explaination:
 ```shell_session
 <file> refers to using a simple file for image storage and lacks a few features.
 <file-reflink> refers to storing images on a filesystem supporting copy on write.
@@ -61,12 +61,12 @@ qvm-pool --add <pool_name> lvm_thin -o volume_group=<vg_name>,thin_pool=<thin_po
 Theses steps assume you have already created a separate Btrfs filesystem for your HDD, that it is encrypted with LUKS and it is mounted. It is recommended to use a subvolume as it enables compression and excess storage can be use for other things.
 
 
-It is possible to use already available Btrfs storage if it is configured. In dom0, available Btrfs storage can be displayed using :
+It is possible to use already available Btrfs storage if it is configured. In dom0, available Btrfs storage can be displayed using:
 ```shell_session
 mount -t btrfs
 btrfs show filesystem
 ```
-To register the storage to qubes :
+To register the storage to qubes:
 
 ```shell_session
 # <pool_name> is a freely chosen pool name
@@ -121,8 +121,7 @@ Reboot the computer so the new luks device appears at /dev/mapper/luks-b209... a
 
 ##### For LVM
 
-First create the physical volume
-
+First create the physical volume:
 ```shell_session
 sudo pvcreate /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde
 ```
@@ -139,41 +138,43 @@ And then use "poolhd0" as the <thin_pool_name> (LVM thin pool name):
 sudo lvcreate -T -n poolhd0 -l +100%FREE qubes
 ```
 
-Finally we will tell Qubes to add a new pool on the just created thin pool
+Finally we will tell Qubes to add a new pool on the just created thin pool:
 
 ```shell_session
 qvm-pool --add poolhd0_qubes lvm_thin -o volume_group=qubes,thin_pool=poolhd0,revisions_to_keep=2
 ```
 #### For Btrfs
 
-First create the physical volume
+First create the physical volume:
 
 ```shell_session
 # <label> Btrfs Label
 sudo mkfs.btrfs -L <label> /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde
 ```
 
-Then mount the new Btrfs to a temporary path
+Then mount the new Btrfs to a temporary path:
 
 ```shell_session
+sudo mkdir -p /mnt/new_qube_storage
 sudo mount /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde /mnt/new_qube_storage
 ```
-Create a subvolume to hold the data. 
+Create a subvolume to hold the data:
 ```
 sudo btrfs subvolume create /mnt/new_qube_storage/qubes
 ```
-Unmount the temporary Btrfs filesystem
+Unmount the temporary Btrfs filesystem:
 ```shell_session
 sudo umount /mnt/new_qube_storage
+rmdir /mnt/new_qube_storage
 ```
-Mount the subvolume with compression enabled if desired
+Mount the subvolume with compression enabled if desired:
 ```shell_session
 # <compression> zlib|lzo|zstd
 # <subvol> btrfs subvolume "qubes" in this example
 sudo mount /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde /var/lib/qubes_newpool -o compress=<compression>,subvol=qubes
 ```
 
-Finally we will tell Qubes to add a new pool on the just created Btrfs subvolume
+Finally we will tell Qubes to add a new pool on the just created Btrfs subvolume:
 
 ```shell_session
 qvm-pool --add poolhd0_qubes file-reflink -o dir_path=/var/lib/qubes_newpool,revisions_to_keep=2

From 5d676db9f1823948f54b78729ceac597ef82c7a8 Mon Sep 17 00:00:00 2001
From: "Dr. Gerhard Weck" <GerhardWeck@onlinehome.de>
Date: Thu, 26 May 2022 17:02:31 +0200
Subject: [PATCH 006/332] Update app-menu-shortcut-troubleshooting.md

---
 .../app-menu-shortcut-troubleshooting.md      | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/user/troubleshooting/app-menu-shortcut-troubleshooting.md b/user/troubleshooting/app-menu-shortcut-troubleshooting.md
index 8d66d937..718b5764 100644
--- a/user/troubleshooting/app-menu-shortcut-troubleshooting.md
+++ b/user/troubleshooting/app-menu-shortcut-troubleshooting.md
@@ -115,3 +115,22 @@ Actual command lines for the menu shortcuts involve `qvm-run` command which star
 Examples: `qvm-run -q -a --service -- %VMNAME% qubes.StartApp+7-Zip-7-Zip_File_Manager` or `qvm-run -q -a --service -- %VMNAME% qubes.StartApp+firefox`
 
 Note that you can create a shortcut that points to a .desktop file in your app qube with e.g. `qvm-run -q -a --service -- personal qubes.StartApp+firefox`.
+
+While this works well for standard applications, creating a menu entry for Windows application running under wine may need an additional step in order to establish the necessary environment in wine. Installing software under wine may create the needed `.desktop` file in the target Linux VM. This file is expected to be in the directory `~/.local/share/applications`, but it may be that it is stored in a subdirectory thereof, determined by the Windows menu structure, where it may not be found. The solution is to copy or move this file from its location to `~/.local/share/applications`.  The name of this file has to be the name used in the `.desktop` file in dom0. So if the shortcut in dom0 points to  `qvm-run -q -a --service -- personal qubes.StartApp+Excel`, the correspondig file in the AppVM has to be called `Excel.desktop`.
+
+If necessary, you can create the `.desktop` file neeeded to start the wine application manually. For Excel, e.g., it will look like this
+
+~~~
+[Desktop Entry]
+Version=1.0
+Type=Application
+Terminal=false
+X-Qubes-VmName=personal
+Icon=/usr/share/icons/hicolor/48x48/apps/Excel.png
+Name=Microsoft Excel
+Categories=X-Qubes-VM;
+Exec=env WINEPREFIX="/home/user/.wine" /usr/bin/wine C:\\\\windows\\\\command\\\\start.exe /Unix /home/user/.wine/dosdevices/c:/users/user/Start\\ Menu/Programs/Microsoft\ Excel.lnk
+StartupWMClass=Excel.exe
+~~~
+
+The rather complicated line `Exec=...` points to an entry in the Windows menu structure calling Excel, not to the executable itself.

From dc0819594baa7b2e4ecb28672495e49ba975cb04 Mon Sep 17 00:00:00 2001
From: qubesbugreport <112062467+qubesbugreport@users.noreply.github.com>
Date: Thu, 1 Sep 2022 07:32:52 +0200
Subject: [PATCH 007/332] Use sentence case instead of title case

As required by the style guide
---
 user/how-to-guides/how-to-use-usb-devices.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/user/how-to-guides/how-to-use-usb-devices.md b/user/how-to-guides/how-to-use-usb-devices.md
index e515231f..c3db0601 100644
--- a/user/how-to-guides/how-to-use-usb-devices.md
+++ b/user/how-to-guides/how-to-use-usb-devices.md
@@ -28,9 +28,9 @@ Examples of valid cases for USB-passthrough:
 (If you are thinking to use a two-factor-authentication device, [there is an app for that](/doc/u2f-proxy/).
 But it has some [issues](https://github.com/QubesOS/qubes-issues/issues/4661).)
 
-## Attaching And Detaching a USB Device
+## Attaching and detaching a USB device
 
-### With Qubes Device Manager
+### With Qubes device manager
 
 Click the device-manager-icon: ![device manager icon](/attachment/doc/media-removable.png)
 A list of available devices appears.
@@ -48,7 +48,7 @@ Hover on the attached device to display a list of running VMs.
 The one to which your device is connected will have an eject button ![eject icon](/attachment/doc/media-eject.png) next to it.
 Click that and your device will be detached.
 
-### With The Command Line Tool
+### With the command line tool
 
 In dom0, you can use `qvm-usb` from the commandline to attach and detach devices.
 
@@ -87,14 +87,14 @@ sys-usb:2-5     058f:3822 058f_USB_2.0_Camera
 sys-usb:2-1     03f0:0641 PixArt_Optical_Mouse
 ```
 
-## Maintenance And Customisation
+## Maintenance and customisation
 
-### Creating And Using a USB qube
+### Creating and using a USB qube
 
 If you've selected to install a usb-qube during system installation, everything is already set up for you in `sys-usb`.
 If you've later decided to create a usb-qube, please follow [this guide](/doc/usb-qubes/).
 
-### Installation Of `qubes-usb-proxy`
+### Installation of `qubes-usb-proxy`
 
 To use this feature, the `qubes-usb-proxy` package needs to be installed in the templates used for the USB qube and qubes you want to connect USB devices to.
 This section exists for reference or in case something broke and you need to reinstall `qubes-usb-proxy`.
@@ -111,13 +111,13 @@ If you receive this error: `ERROR: qubes-usb-proxy not installed in the VM`, you
   sudo apt-get install qubes-usb-proxy
   ```
 
-### Using USB Keyboards And Other Input Devices
+### Using USB keyboards and other input devices
 
 **Warning:** especially keyboards need to be accepted by default when using them to login! Please make sure you carefully read and understood the **[security considerations](/doc/device-handling-security/#usb-security)** before continuing!
 
 Mouse and keyboard setup are part of [setting up a USB qube](/doc/usb-qubes/).
 
-### Finding The Right USB Controller
+### Finding the right USB controller
 
 Some USB devices are not compatible with the USB pass-through method Qubes employs.
 In situations like these, you can try to pass through the entire USB controller to a qube as PCI device.

From 2b24640962d12880aa91c93a478d0b71d4553444 Mon Sep 17 00:00:00 2001
From: qubesbugreport <112062467+qubesbugreport@users.noreply.github.com>
Date: Thu, 1 Sep 2022 08:00:33 +0200
Subject: [PATCH 008/332] Add instructions for using Qube Manager

Using the Qube Manager to determine USB controller and address
---
 user/how-to-guides/how-to-use-usb-devices.md | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/user/how-to-guides/how-to-use-usb-devices.md b/user/how-to-guides/how-to-use-usb-devices.md
index c3db0601..f845f89e 100644
--- a/user/how-to-guides/how-to-use-usb-devices.md
+++ b/user/how-to-guides/how-to-use-usb-devices.md
@@ -123,6 +123,10 @@ Some USB devices are not compatible with the USB pass-through method Qubes emplo
 In situations like these, you can try to pass through the entire USB controller to a qube as PCI device.
 However, with this approach one cannot attach single USB devices but has to attach the whole USB controller with whatever USB devices are connected to it.
 
+You can find your controller and its BDF address using either of two methods described below. Using the command-line tools lsusb and readlink or by using the Qube Manager GUI. It is possible that on some system configurations the readlink method produces output which is different from the example below, while the Qube Manager method allows one to easily determine the correct controller and BDF address.
+
+#### Method 1: Using lsusb and readlink
+
 If you have multiple USB controllers, you must first figure out which PCI device is the right controller.
 
 First, find out which USB bus the device is connected to (note that these steps need to be run from a terminal inside your USB qube):
@@ -155,6 +159,8 @@ This should output something like:
 ../../../devices/pci-0/pci0000:00/0000:00:1a.0/usb3
 ```
 
+If the output format does not match this example, or you are unsure if it contains the correct BDF address, you can try finding the address using method 2 using the Qube Manager instead.
+
 Now you see the path and the text between `/pci0000:00/0000:` and `/usb3` i.e. `00:1a.0` is the BDF address. Strip the address and pass it to the [`qvm-pci` tool](/doc/how-to-use-pci-devices/) to attach the controller to the targetVM.
 
 For example, On R 4.0 the command would look something like
@@ -162,3 +168,17 @@ For example, On R 4.0 the command would look something like
 ```
 qvm-pci attach --persistent personal dom0:00_1a.0
 ```
+
+#### Method 2: Using the Qube Manager
+
+Open the Qube Manager, then right click on one of the VMs and open the settings. Go to the tab "Devices".
+
+Here you should see your available devices along with their BDF addresses. Look for the lines containing "USB controller".
+
+They should look something like: `01:00.0 USB controller: Name of manufacturer`
+
+The first part is the BDF address, in this example: `01:00.0`
+
+If, for example, you have 2 USB controllers in your system because you added one you should see 2 such lines and you can probably guess which controller is the one on the mainboard and which one you added. For example, if you have a mainboard with an Intel chipset, it is possible that all of the mainboard devices show as "Intel Corporation" while the added controller shows another name of manufacturer.
+
+Now you should be able to tell which is the correct BDF address of the mainboard USB controller or the added USB controller.

From ec619b4806c7dd9136687b29d8934e3806847e24 Mon Sep 17 00:00:00 2001
From: Adam Stankiewicz <sheerun@sher.pl>
Date: Sun, 4 Sep 2022 12:40:44 +0200
Subject: [PATCH 009/332] doc: Replace highstate occurences with apply

---
 user/advanced-topics/salt.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/user/advanced-topics/salt.md b/user/advanced-topics/salt.md
index fdd88a40..d23dda4b 100644
--- a/user/advanced-topics/salt.md
+++ b/user/advanced-topics/salt.md
@@ -61,7 +61,7 @@ enforcing the state in a particular area.
 It exposes some *imperative* functions for the administrator.
 For example, there is a `system` module that has a `system.halt` function that,
 when issued, will immediately halt a domain.
-There is another function called `state.highstate` which will synchronize the
+There is another function called `state.apply` which will synchronize the
 state of the system with the administrator's configuration/desires.
 
 ### Configuration
@@ -184,7 +184,7 @@ $ qubesctl top.disable my-new-vm
 To apply the states to dom0 and all VMs:
 
 ```
-$ qubesctl --all state.highstate
+$ qubesctl --all state.apply
 ```
 
 (More information on the `qubesctl` command further down.)
@@ -232,7 +232,7 @@ usage: qubesctl [-h] [--show-output] [--force-color] [--skip-dom0]
                 ...
 
 positional arguments:
-  command            Salt command to execute (e.g., state.highstate)
+  command            Salt command to execute (e.g., state.apply)
 
 optional arguments:
   -h, --help         show this help message and exit
@@ -246,7 +246,7 @@ optional arguments:
   --all              Target all non-disposables (templates and app qubes)
 ```
 
-To apply a state to all templates, call `qubesctl --templates state.highstate`.
+To apply a state to all templates, call `qubesctl --templates state.apply`.
 
 The actual configuration is applied using `salt-ssh` (running over `qrexec`
 instead of `ssh`).
@@ -325,7 +325,7 @@ $ qubesctl top.enable my-new-vm
 To apply the state:
 
 ```
-$ qubesctl state.highstate
+$ qubesctl state.apply
 ```
 
 ### Example of Configuring a VM's System from Dom0
@@ -357,7 +357,7 @@ $ qubesctl top.enable mc-everywhere
 And apply the configuration:
 
 ```
-$ qubesctl --all state.highstate
+$ qubesctl --all state.apply
 ```
 
 ## All Qubes-specific States
@@ -559,7 +559,7 @@ VM which provides network to the given VM
 The output for each VM is logged in `/var/log/qubes/mgmt-VM_NAME.log`.
 
 If the log does not contain useful information:
-1. Run `sudo qubesctl --skip-dom0 --target=VM_NAME state.highstate`
+1. Run `sudo qubesctl --skip-dom0 --target=VM_NAME state.apply`
 2. When your VM is being started (yellow) press Ctrl-z on qubesctl.
 3. Open terminal in disp-mgmt-VM_NAME.
 4. Look at /etc/qubes-rpc/qubes.SaltLinuxVM - this is what is
@@ -571,7 +571,7 @@ If the log does not contain useful information:
     $ salt-ssh "$target_vm" $salt_command
     ```
 
-  Adjust $target_vm (VM_NAME) and $salt_command (state.highstate).
+  Adjust $target_vm (VM_NAME) and $salt_command (state.apply).
 6. Execute them, fix problems, repeat.
 
 ## Known Pitfalls

From 9eb7926ffe515a044d0f4ec31ca9eecb5c54bc09 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Wed, 23 Nov 2022 17:34:08 -0800
Subject: [PATCH 010/332] Update and improve Emergency backup restore v4 page

- Update formatting and style to be consistent with the rest of the docs
- Improve language
- Clarify instructions
- Improve organization
---
 .../backup-emergency-restore-v4.md            | 109 ++++++++----------
 1 file changed, 47 insertions(+), 62 deletions(-)

diff --git a/user/how-to-guides/backup-emergency-restore-v4.md b/user/how-to-guides/backup-emergency-restore-v4.md
index 19367a24..38df4b12 100644
--- a/user/how-to-guides/backup-emergency-restore-v4.md
+++ b/user/how-to-guides/backup-emergency-restore-v4.md
@@ -12,13 +12,17 @@ title: Emergency backup recovery (v4)
 This page describes how to perform an emergency restore of a backup created on
 Qubes R4.X (which uses backup format version 4).
 
-The Qubes backup system has been designed with emergency disaster recovery in
-mind. No special Qubes-specific tools are required to access data backed up by
-Qubes. In the event a Qubes system is unavailable, you can access your data on
-any GNU/Linux system with the following procedure.
+The Qubes backup system is designed with emergency disaster recovery in mind. No
+special Qubes-specific tools are required to access data backed up by Qubes. In
+the event a Qubes system is unavailable, you can access your data on any
+GNU/Linux system by following the instructions on this page.
 
-Required `scrypt` Utility
--------------------------
+**Important:** You may wish to store a copy of these instructions with your
+Qubes backups. All Qubes documentation, including this page, is available in
+plain text format in the the [qubes-doc](https://github.com/QubesOS/qubes-doc)
+Git repository.
+
+## Required `scrypt` utility
 
 In Qubes 4.X, backups are encrypted and integrity-protected with
 [scrypt](https://www.tarsnap.com/scrypt.html). You will need a copy of this
@@ -34,8 +38,8 @@ easier scripting, which means you'll need to enter the passphrase for each file
 separately, instead of using `echo ... | scrypt`.
 
 Here are instructions for obtaining a compiled `scrypt` binary. This example
-uses an RPM-based system (Fedora), but the same general procedure should work
-on any GNU/Linux system.
+uses an RPM-based system (Fedora), but the same general procedure should work on
+any GNU/Linux system.
 
  1. If you're not on Qubes 4.X, [import and authenticate the Release 4 Signing
     Key](/security/verifying-signatures/#how-to-import-and-authenticate-release-signing-keys).
@@ -46,7 +50,7 @@ on any GNU/Linux system.
 
         [user@restore ~]$ dnf download scrypt
 
-    or, if that doesn't work:
+    Or, if that doesn't work:
 
         [user@restore ~]$ curl -O https://yum.qubes-os.org/r4.0/current/vm/fc28/rpm/scrypt-1.2.1-1.fc28.x86_64.rpm
 
@@ -66,17 +70,19 @@ on any GNU/Linux system.
 
         [user@restore ~]$ rpmdev-extract scrypt-*.rpm
 
- 6. (Optional) Create an alias for the new binary.
-
-        [user@restore ~]$ alias scrypt="scrypt-*/usr/bin/scrypt"
-
-Emergency Recovery Instructions
--------------------------------
+## Emergency recovery instructions
 
 **Note:** In the following example, the backup file is both *encrypted* and
 *compressed*.
 
- 1. Untar the main backup file.
+ 1. (Optional) If you're working with binaries that you saved with your backup,
+    such as `scrypt` or `bzip2`, you can make things easier by aliasing those
+    binaries now, e.g.,
+
+        [user@restore ~]$ alias scrypt="/home/user/scrypt-*"
+        [user@restore ~]$ alias bzip2="/home/user/bzip2-*"
+
+ 2. Untar the main backup file.
 
         [user@restore ~]$ tar -i -xvf qubes-backup-2015-06-05T123456
         backup-header
@@ -90,32 +96,15 @@ Emergency Recovery Instructions
         vm1/whitelisted-appmenus.list.000.enc
         dom0-home/dom0user.000.enc
 
-    **To extract only specific VMs:** Each VM in the backup file has its path
-    listed in `qubes.xml.000.enc`. Decrypt it. (In this example, the password is
-    `password`.)
-
-        [user@restore ~]$ cat backup-header | grep backup-id
-        backup-id=20190128T123456-1234
-        [user@restore ~]$ scrypt dec -P qubes.xml.000.enc qubes.xml.000
-        Please enter passphrase: 20190128T123456-1234!qubes.xml.000!password
-        [user@restore ~]$ tar -i -xvf qubes.xml.000
-
-    Now that you have the decrypted `qubes.xml.000` file, search for the
-    `backup-path` property inside of it. With the `backup-path`, extract only
-    the files necessary for your VM (`vmX`).
-
-        [user@restore ~]$ tar -i -xvf qubes-backup-2015-06-05T123456 \
-            backup-header backup-header.hmac vmX/
-
- 2. Set the backup passphrase environment variable. While this isn't strictly
-    required, it will be handy later and will avoid saving the passphrase in
-    the shell's history.
+ 3. Set the backup passphrase environment variable. While this isn't strictly
+    required, it will be handy later and will avoid saving the passphrase in the
+    shell's history.
 
         [user@restore ~]$ read -r backup_pass
 
- 3. Verify the integrity of `backup-header`. For compatibility reasons,
-    `backup-header.hmac` is an encrypted *and integrity protected*
-    version of `backup-header`.
+ 4. Verify the integrity of `backup-header`. For compatibility reasons,
+    `backup-header.hmac` is an encrypted *and integrity protected* version of
+    `backup-header`.
 
         [user@restore ~]$ set +H
         [user@restore ~]$ echo "backup-header!$backup_pass" |\
@@ -123,28 +112,31 @@ Emergency Recovery Instructions
             diff -qs backup-header backup-header.verified
         Files backup-header and backup-header.verified are identical
 
-    **Note:** If this command fails, it may be that the backup was tampered
-    with or is in a different format. In the latter case, look inside
-    `backup-header` at the `version` field. If it contains a value other than
-    `version=4`, go to the instructions for that format version:
+    **Note:** If this command fails, it may be that the backup was tampered with
+    or is in a different format. In the latter case, look inside `backup-header`
+    at the `version` field. If it contains a value other than `version=4`, go to
+    the instructions for that format version:
     - [Emergency Backup Recovery without Qubes (v2)](/doc/backup-emergency-restore-v2/)
     - [Emergency Backup Recovery without Qubes (v3)](/doc/backup-emergency-restore-v3/)
 
- 4. Read `backup-header`:
+ 5. Read `backup-header`.
 
         [user@restore ~]$ cat backup-header
         version=4
         encrypted=True
         compressed=True
         compression-filter=gzip
-        backup_id=20161020T123455-1234
+        hmac-algorithm=scrypt
+        backup-id=20161020T123455-1234
 
- 5. Set `backup_id` to the value in the last line of `backup-header`:
+ 6. Set `backup_id` to the value in the last line of `backup-header`. (Note that
+    there is a hyphen in `backup-id` in the file, whereas there is an underscore
+    in `backup_id` in the variable you're setting.)
 
         [user@restore ~]$ backup_id=20161020T123455-1234
 
- 6. Verify the integrity of your data, decrypt, decompress, and extract
-    `private.img`:
+ 7. Choose a qube whose data you wish to restore. Verify the data's integrity,
+    decrypt it, decompress it, and extract it.
 
         [user@restore ~]$ find vm1 -name 'private.img.*.enc' | sort -V | while read f_enc; do \
             f_dec=${f_enc%.enc}; \
@@ -157,24 +149,17 @@ Emergency Recovery Instructions
 
     **Note:** If your backup was compressed with a program other than `gzip`,
     you must substitute the correct compression program in the command above.
-    This information is contained in `backup-header` (see step 4). For example,
-    if your backup is compressed with `bzip2`, use `bzip2 -d` instead in the
-    command above.
+    This information is contained in `backup-header` (see step 5). For example,
+    if your backup is compressed with `bzip2`, use `bzip2 -d` instead of `gzip
+    -d` in the command above.
 
- 7. Mount `private.img` and access your data.
+ 8. Enter the decrypted directory, mount `private.img`, and access your data.
 
+        [user@restore ~]$ cd vm1/
         [user@restore vm1]$ sudo mkdir /mnt/img
         [user@restore vm1]$ sudo mount -o loop vm1/private.img /mnt/img/
         [user@restore vm1]$ cat /mnt/img/home/user/your_data.txt
         This data has been successfully recovered!
 
- 8. Success! If you wish to recover data from more than one VM in your backup,
-    simply repeat steps 6 and 7 for each additional VM.
-
-    **Note:** You may wish to store a copy of these instructions with your
-    Qubes backups in the event that you fail to recall the above procedure
-    while this web page is inaccessible. All Qubes documentation, including
-    this page, is available in plain text format in the following Git
-    repository:
-
-        https://github.com/QubesOS/qubes-doc.git
+Success! If you wish to recover data from more than one qube in your backup,
+simply repeat steps 7 and 8 for each additional qube.

From b6c99d486bf7fb38f9958dabb56107cf20223e7d Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Wed, 23 Nov 2022 17:53:29 -0800
Subject: [PATCH 011/332] Fix typo

---
 user/how-to-guides/backup-emergency-restore-v4.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/how-to-guides/backup-emergency-restore-v4.md b/user/how-to-guides/backup-emergency-restore-v4.md
index 38df4b12..026de11f 100644
--- a/user/how-to-guides/backup-emergency-restore-v4.md
+++ b/user/how-to-guides/backup-emergency-restore-v4.md
@@ -19,8 +19,8 @@ GNU/Linux system by following the instructions on this page.
 
 **Important:** You may wish to store a copy of these instructions with your
 Qubes backups. All Qubes documentation, including this page, is available in
-plain text format in the the [qubes-doc](https://github.com/QubesOS/qubes-doc)
-Git repository.
+plain text format in the [qubes-doc](https://github.com/QubesOS/qubes-doc) Git
+repository.
 
 ## Required `scrypt` utility
 

From 39342e8c98066603839d7f77ce0416e4af439b75 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Wed, 23 Nov 2022 17:55:04 -0800
Subject: [PATCH 012/332] Clarify example

---
 user/how-to-guides/backup-emergency-restore-v4.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/how-to-guides/backup-emergency-restore-v4.md b/user/how-to-guides/backup-emergency-restore-v4.md
index 026de11f..1caa526b 100644
--- a/user/how-to-guides/backup-emergency-restore-v4.md
+++ b/user/how-to-guides/backup-emergency-restore-v4.md
@@ -135,8 +135,8 @@ any GNU/Linux system.
 
         [user@restore ~]$ backup_id=20161020T123455-1234
 
- 7. Choose a qube whose data you wish to restore. Verify the data's integrity,
-    decrypt it, decompress it, and extract it.
+ 7. Choose a qube whose data you wish to restore (in this example, `vm1`).
+    Verify the data's integrity, decrypt it, decompress it, and extract it.
 
         [user@restore ~]$ find vm1 -name 'private.img.*.enc' | sort -V | while read f_enc; do \
             f_dec=${f_enc%.enc}; \

From c5314bed7f3001996c10458145cc5ba4a0ebaad8 Mon Sep 17 00:00:00 2001
From: zenkuro <42751749+zenkuro@users.noreply.github.com>
Date: Thu, 5 Jan 2023 22:57:18 -0500
Subject: [PATCH 013/332] Eetend VPN troubleshooting by notify-send case

There are guides and scripts on internet that are helping to configure and run VPN service on QubesOS
This record provides explanation how to identify and what to do to fix possible issues with notify-send that being used by this guides.
---
 user/troubleshooting/vpn-troubleshooting.md | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/user/troubleshooting/vpn-troubleshooting.md b/user/troubleshooting/vpn-troubleshooting.md
index d63bbe0c..d06eb5d1 100644
--- a/user/troubleshooting/vpn-troubleshooting.md
+++ b/user/troubleshooting/vpn-troubleshooting.md
@@ -31,3 +31,20 @@ After suspend/resume, OpenVPN may not automatically reconnect. In order to get i
 After setting up OpenVPN and restarting the VM, you may be repeatedly getting the popup "Ready to start link", but the VPN isn't connected.
 
 To figure out the root of the problem, check the VPN logs in `/var/logs/syslog`. The log may reveal issues like missing OpenVPN libraries, which you can then install.
+
+## `notify-send` induced failure
+[Some VPN guides](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md) use complex scripts that by themselves include call of `notify-send`, yet some images may not contain this tool or may not have it working properly.
+For instance calling `notify-send` on `fedora-36` template VM gives:
+```
+Failed to execute child process “dbus-launch” (No such file or directory)
+```
+
+To check this tool is working properly run:
+```bash
+sudo notify-send "$(hostname): Test notify-send OK" --icon=network-idle
+```
+You should see `info` message appear on the top of your scree.
+If that is the case then, `notify-send` is not the issue.
+If it is not, and you have an error of some sort you can:
+1. Remove all calls of `notify-send` from scripts you are using to start VPN
+2. Use other template VM that have `notify-send` working or find proper guide and make your current template VM run `notify-send` work properly.

From a65a507db57fc5166163f05c4f1244edcd5bf3fa Mon Sep 17 00:00:00 2001
From: zenkuro <42751749+zenkuro@users.noreply.github.com>
Date: Sat, 7 Jan 2023 02:47:34 -0500
Subject: [PATCH 014/332] Update vpn-troubleshooting.md

Fix typo
---
 user/troubleshooting/vpn-troubleshooting.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/troubleshooting/vpn-troubleshooting.md b/user/troubleshooting/vpn-troubleshooting.md
index d06eb5d1..4671066c 100644
--- a/user/troubleshooting/vpn-troubleshooting.md
+++ b/user/troubleshooting/vpn-troubleshooting.md
@@ -43,7 +43,7 @@ To check this tool is working properly run:
 ```bash
 sudo notify-send "$(hostname): Test notify-send OK" --icon=network-idle
 ```
-You should see `info` message appear on the top of your scree.
+You should see `info` message appear on the top of your screen.
 If that is the case then, `notify-send` is not the issue.
 If it is not, and you have an error of some sort you can:
 1. Remove all calls of `notify-send` from scripts you are using to start VPN

From edbfa3c9b6fc133af765687e796520118cd7f3dc Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Tue, 11 Apr 2023 16:35:19 -0700
Subject: [PATCH 015/332] Update
 user/how-to-guides/backup-emergency-restore-v4.md

Co-authored-by: Rusty Bird <rustybird@net-c.com>
---
 user/how-to-guides/backup-emergency-restore-v4.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/how-to-guides/backup-emergency-restore-v4.md b/user/how-to-guides/backup-emergency-restore-v4.md
index 1caa526b..ce04ba70 100644
--- a/user/how-to-guides/backup-emergency-restore-v4.md
+++ b/user/how-to-guides/backup-emergency-restore-v4.md
@@ -79,7 +79,7 @@ any GNU/Linux system.
     such as `scrypt` or `bzip2`, you can make things easier by aliasing those
     binaries now, e.g.,
 
-        [user@restore ~]$ alias scrypt="/home/user/scrypt-*"
+        [user@restore ~]$ alias scrypt="$PWD/scrypt-*/usr/bin/scrypt"
         [user@restore ~]$ alias bzip2="/home/user/bzip2-*"
 
  2. Untar the main backup file.

From f43e54f3a5736f9ce972e0d4889dd42cc0dfff4d Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Tue, 11 Apr 2023 16:42:34 -0700
Subject: [PATCH 016/332] Remove unnecessary example and step

Per @rustybird's suggestions on #1279
---
 user/how-to-guides/backup-emergency-restore-v4.md | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/user/how-to-guides/backup-emergency-restore-v4.md b/user/how-to-guides/backup-emergency-restore-v4.md
index ce04ba70..f3ca1129 100644
--- a/user/how-to-guides/backup-emergency-restore-v4.md
+++ b/user/how-to-guides/backup-emergency-restore-v4.md
@@ -76,11 +76,10 @@ any GNU/Linux system.
 *compressed*.
 
  1. (Optional) If you're working with binaries that you saved with your backup,
-    such as `scrypt` or `bzip2`, you can make things easier by aliasing those
-    binaries now, e.g.,
+    such as `scrypt`, you can make things easier by aliasing those binaries now,
+    e.g.,
 
         [user@restore ~]$ alias scrypt="$PWD/scrypt-*/usr/bin/scrypt"
-        [user@restore ~]$ alias bzip2="/home/user/bzip2-*"
 
  2. Untar the main backup file.
 
@@ -155,10 +154,9 @@ any GNU/Linux system.
 
  8. Enter the decrypted directory, mount `private.img`, and access your data.
 
-        [user@restore ~]$ cd vm1/
-        [user@restore vm1]$ sudo mkdir /mnt/img
-        [user@restore vm1]$ sudo mount -o loop vm1/private.img /mnt/img/
-        [user@restore vm1]$ cat /mnt/img/home/user/your_data.txt
+        [user@restore]$ sudo mkdir /mnt/img
+        [user@restore]$ sudo mount -o loop vm1/private.img /mnt/img/
+        [user@restore]$ cat /mnt/img/home/user/your_data.txt
         This data has been successfully recovered!
 
 Success! If you wish to recover data from more than one qube in your backup,

From 3b550699afcd692e63c1a554a1dfdf6619f93aa7 Mon Sep 17 00:00:00 2001
From: Rusty Bird <rustybird@net-c.com>
Date: Thu, 13 Apr 2023 06:47:22 +0000
Subject: [PATCH 017/332] Emergency backup restore v4 tweaks

---
 .../backup-emergency-restore-v4.md            | 76 ++++++++++---------
 1 file changed, 41 insertions(+), 35 deletions(-)

diff --git a/user/how-to-guides/backup-emergency-restore-v4.md b/user/how-to-guides/backup-emergency-restore-v4.md
index f3ca1129..54844e96 100644
--- a/user/how-to-guides/backup-emergency-restore-v4.md
+++ b/user/how-to-guides/backup-emergency-restore-v4.md
@@ -66,44 +66,33 @@ any GNU/Linux system.
 
         [user@restore ~]$ sudo dnf install rpmdevtools
 
- 5. Extract the `scrypt` binary from the RPM.
+ 5. Extract the `scrypt` binary from the RPM and make it conveniently
+    available.
 
         [user@restore ~]$ rpmdev-extract scrypt-*.rpm
+        [user@restore ~]$ alias scrypt="$PWD/scrypt-*/usr/bin/scrypt"
 
 ## Emergency recovery instructions
 
 **Note:** In the following example, the backup file is both *encrypted* and
 *compressed*.
 
- 1. (Optional) If you're working with binaries that you saved with your backup,
-    such as `scrypt`, you can make things easier by aliasing those binaries now,
-    e.g.,
+ 1. Untar the backup metadata from the main backup file.
 
-        [user@restore ~]$ alias scrypt="$PWD/scrypt-*/usr/bin/scrypt"
-
- 2. Untar the main backup file.
-
-        [user@restore ~]$ tar -i -xvf qubes-backup-2015-06-05T123456
+        [user@restore ~]$ tar -i -xvf qubes-backup-2015-06-05T123456 \
+            backup-header backup-header.hmac qubes.xml.000.enc
         backup-header
         backup-header.hmac
         qubes.xml.000.enc
-        vm1/private.img.000.enc
-        vm1/private.img.001.enc
-        vm1/private.img.002.enc
-        vm1/icon.png.000.enc
-        vm1/firewall.xml.000.enc
-        vm1/whitelisted-appmenus.list.000.enc
-        dom0-home/dom0user.000.enc
 
- 3. Set the backup passphrase environment variable. While this isn't strictly
+ 2. Set the backup passphrase environment variable. While this isn't strictly
     required, it will be handy later and will avoid saving the passphrase in the
     shell's history.
 
         [user@restore ~]$ read -r backup_pass
 
- 4. Verify the integrity of `backup-header`. For compatibility reasons,
-    `backup-header.hmac` is an encrypted *and integrity protected* version of
-    `backup-header`.
+ 3. Verify the integrity of `backup-header` using `backup-header.hmac` (an
+    encrypted *and integrity protected* version of `backup-header`).
 
         [user@restore ~]$ set +H
         [user@restore ~]$ echo "backup-header!$backup_pass" |\
@@ -118,7 +107,7 @@ any GNU/Linux system.
     - [Emergency Backup Recovery without Qubes (v2)](/doc/backup-emergency-restore-v2/)
     - [Emergency Backup Recovery without Qubes (v3)](/doc/backup-emergency-restore-v3/)
 
- 5. Read `backup-header`.
+ 4. Read `backup-header`.
 
         [user@restore ~]$ cat backup-header
         version=4
@@ -128,36 +117,53 @@ any GNU/Linux system.
         hmac-algorithm=scrypt
         backup-id=20161020T123455-1234
 
- 6. Set `backup_id` to the value in the last line of `backup-header`. (Note that
+ 5. Set `backup_id` to the value in the last line of `backup-header`. (Note that
     there is a hyphen in `backup-id` in the file, whereas there is an underscore
     in `backup_id` in the variable you're setting.)
 
         [user@restore ~]$ backup_id=20161020T123455-1234
 
- 7. Choose a qube whose data you wish to restore (in this example, `vm1`).
-    Verify the data's integrity, decrypt it, decompress it, and extract it.
+ 6. Verify and decrypt, decompress, and extract the `qubes.xml` file.
 
-        [user@restore ~]$ find vm1 -name 'private.img.*.enc' | sort -V | while read f_enc; do \
-            f_dec=${f_enc%.enc}; \
-            echo "$backup_id!$f_dec!$backup_pass" | scrypt dec -P $f_enc || break; \
-            done | gzip -d | tar -xv
-        vm1/private.img
+        [user@restore ~]$ echo "$backup_id!qubes.xml.000!$backup_pass" |\
+            scrypt dec -P qubes.xml.000.enc | gzip -d | tar -xv
+        qubes.xml
 
     If this pipeline fails, it is likely that the backup is corrupted or has
     been tampered with.
 
     **Note:** If your backup was compressed with a program other than `gzip`,
     you must substitute the correct compression program in the command above.
-    This information is contained in `backup-header` (see step 5). For example,
+    This information is contained in `backup-header` (see step 4). For example,
     if your backup is compressed with `bzip2`, use `bzip2 -d` instead of `gzip
     -d` in the command above.
 
- 8. Enter the decrypted directory, mount `private.img`, and access your data.
+ 7. Search inside of `qubes.xml` for the `backup-path` property of the qube
+    whose data you wish to restore. Using the value of this property (e.g.
+    `vm123`), untar the necessary data files:
 
-        [user@restore]$ sudo mkdir /mnt/img
-        [user@restore]$ sudo mount -o loop vm1/private.img /mnt/img/
-        [user@restore]$ cat /mnt/img/home/user/your_data.txt
+        [user@restore ~]$ tar -i -xvf qubes-backup-2015-06-05T123456 vm123
+
+ 8. Verify and decrypt the backed up data, decompress it, and extract it.
+
+        [user@restore ~]$ find vm123 -name 'private.img.*.enc' | sort -V | while read f_enc; do \
+            f_dec=${f_enc%.enc}; \
+            echo "$backup_id!$f_dec!$backup_pass" | scrypt dec -P $f_enc || break; \
+            done | gzip -d | tar -xv
+        vm123/private.img
+
+    If this pipeline fails, it is likely that the backup is corrupted or has
+    been tampered with.
+
+    Also see the note in step 6 about substituting a different compression
+    program for `gzip`.
+
+ 9. Mount `private.img` and access your data.
+
+        [user@restore ~]$ sudo mkdir /mnt/img
+        [user@restore ~]$ sudo mount -o loop vm123/private.img /mnt/img/
+        [user@restore ~]$ cat /mnt/img/home/user/your_data.txt
         This data has been successfully recovered!
 
 Success! If you wish to recover data from more than one qube in your backup,
-simply repeat steps 7 and 8 for each additional qube.
+simply repeat steps 7, 8, and 9 for each additional qube.

From 034976f80fe61562412a2ae3d18fb7adb7093f77 Mon Sep 17 00:00:00 2001
From: Rusty Bird <rustybird@net-c.com>
Date: Fri, 14 Apr 2023 16:28:59 +0000
Subject: [PATCH 018/332] Use vm123/ with a trailing slash like in the
 backup-path value

---
 user/how-to-guides/backup-emergency-restore-v4.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/user/how-to-guides/backup-emergency-restore-v4.md b/user/how-to-guides/backup-emergency-restore-v4.md
index 54844e96..2cf18a51 100644
--- a/user/how-to-guides/backup-emergency-restore-v4.md
+++ b/user/how-to-guides/backup-emergency-restore-v4.md
@@ -140,13 +140,13 @@ any GNU/Linux system.
 
  7. Search inside of `qubes.xml` for the `backup-path` property of the qube
     whose data you wish to restore. Using the value of this property (e.g.
-    `vm123`), untar the necessary data files:
+    `vm123/`), untar the necessary data files:
 
-        [user@restore ~]$ tar -i -xvf qubes-backup-2015-06-05T123456 vm123
+        [user@restore ~]$ tar -i -xvf qubes-backup-2015-06-05T123456 vm123/
 
  8. Verify and decrypt the backed up data, decompress it, and extract it.
 
-        [user@restore ~]$ find vm123 -name 'private.img.*.enc' | sort -V | while read f_enc; do \
+        [user@restore ~]$ find vm123/ -name 'private.img.*.enc' | sort -V | while read f_enc; do \
             f_dec=${f_enc%.enc}; \
             echo "$backup_id!$f_dec!$backup_pass" | scrypt dec -P $f_enc || break; \
             done | gzip -d | tar -xv

From 35b16e2e372a80ccd81e9c4e4d5b87a56a507a49 Mon Sep 17 00:00:00 2001
From: Rusty Bird <rustybird@net-c.com>
Date: Fri, 14 Apr 2023 16:29:00 +0000
Subject: [PATCH 019/332] Mention installing the compression program

---
 user/how-to-guides/backup-emergency-restore-v4.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/user/how-to-guides/backup-emergency-restore-v4.md b/user/how-to-guides/backup-emergency-restore-v4.md
index 2cf18a51..ea47708f 100644
--- a/user/how-to-guides/backup-emergency-restore-v4.md
+++ b/user/how-to-guides/backup-emergency-restore-v4.md
@@ -136,7 +136,8 @@ any GNU/Linux system.
     you must substitute the correct compression program in the command above.
     This information is contained in `backup-header` (see step 4). For example,
     if your backup is compressed with `bzip2`, use `bzip2 -d` instead of `gzip
-    -d` in the command above.
+    -d` in the command above. You might need to install a package of the same
+    name (in this example, `bzip2`) through your distribution's package manager.
 
  7. Search inside of `qubes.xml` for the `backup-path` property of the qube
     whose data you wish to restore. Using the value of this property (e.g.

From 51d387a9fe935781d741eafcec818472d4e235a0 Mon Sep 17 00:00:00 2001
From: Rusty Bird <rustybird@net-c.com>
Date: Sat, 15 Apr 2023 10:45:27 +0000
Subject: [PATCH 020/332] Add xmlstarlet command

Also update the backup filename's date to avoid anachronisms in the
resulting example qube list (e.g. a backup of fedora-37 in 2015)
---
 .../backup-emergency-restore-v4.md            | 38 ++++++++++++++++---
 1 file changed, 33 insertions(+), 5 deletions(-)

diff --git a/user/how-to-guides/backup-emergency-restore-v4.md b/user/how-to-guides/backup-emergency-restore-v4.md
index ea47708f..b42d400b 100644
--- a/user/how-to-guides/backup-emergency-restore-v4.md
+++ b/user/how-to-guides/backup-emergency-restore-v4.md
@@ -79,7 +79,7 @@ any GNU/Linux system.
 
  1. Untar the backup metadata from the main backup file.
 
-        [user@restore ~]$ tar -i -xvf qubes-backup-2015-06-05T123456 \
+        [user@restore ~]$ tar -i -xvf qubes-backup-2023-04-05T123456 \
             backup-header backup-header.hmac qubes.xml.000.enc
         backup-header
         backup-header.hmac
@@ -139,11 +139,39 @@ any GNU/Linux system.
     -d` in the command above. You might need to install a package of the same
     name (in this example, `bzip2`) through your distribution's package manager.
 
- 7. Search inside of `qubes.xml` for the `backup-path` property of the qube
-    whose data you wish to restore. Using the value of this property (e.g.
-    `vm123/`), untar the necessary data files:
+ 7. Search inside of the `qubes.xml` file for the `backup-path` of the qube
+    whose data you wish to restore. If you install the `xmlstarlet` package, the
+    following command will convert `qubes.xml` to a friendlier listing for this
+    purpose:
 
-        [user@restore ~]$ tar -i -xvf qubes-backup-2015-06-05T123456 vm123/
+        [user@restore ~]$ xmlstarlet sel -T -t -m //domain \
+            -v 'concat(.//property[@name="name"], " ", .//feature[@name="backup-path"])' \
+            -n qubes.xml
+        
+        anon-whonix
+        debian-11
+        default-mgmt-dvm
+        disp2345
+        fedora-37
+        fedora-37-dvm
+        personal vm123/
+        sys-firewall
+        sys-net
+        sys-usb
+        untrusted
+        vault vm321/
+        whonix-gw-16
+        whonix-ws-16
+        whonix-ws-16-dvm
+        work
+
+    The example output above shows that the backup file includes a qube named
+    `personal` and a qube named `vault`, with `backup-path` values of `vm123/`
+    and `vm321/` respectively. (Every other listed qube was not selected to be
+    included in the backup file.) Use the corresponding value to untar the
+    necessary data files of the qube:
+
+        [user@restore ~]$ tar -i -xvf qubes-backup-2023-04-05T123456 vm123/
 
  8. Verify and decrypt the backed up data, decompress it, and extract it.
 

From 0251ed63d5d63474d5ce9dadedec3b270448ba50 Mon Sep 17 00:00:00 2001
From: Rusty Bird <rustybird@net-c.com>
Date: Sat, 15 Apr 2023 11:08:35 +0000
Subject: [PATCH 021/332] Update to a plausible timestamp in the backup ID too

---
 user/how-to-guides/backup-emergency-restore-v4.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/how-to-guides/backup-emergency-restore-v4.md b/user/how-to-guides/backup-emergency-restore-v4.md
index b42d400b..0d318b5e 100644
--- a/user/how-to-guides/backup-emergency-restore-v4.md
+++ b/user/how-to-guides/backup-emergency-restore-v4.md
@@ -115,13 +115,13 @@ any GNU/Linux system.
         compressed=True
         compression-filter=gzip
         hmac-algorithm=scrypt
-        backup-id=20161020T123455-1234
+        backup-id=20230405T123455-1234
 
  5. Set `backup_id` to the value in the last line of `backup-header`. (Note that
     there is a hyphen in `backup-id` in the file, whereas there is an underscore
     in `backup_id` in the variable you're setting.)
 
-        [user@restore ~]$ backup_id=20161020T123455-1234
+        [user@restore ~]$ backup_id=20230405T123455-1234
 
  6. Verify and decrypt, decompress, and extract the `qubes.xml` file.
 

From d4778384da7ae12bec3cd691b88cacb8900d9090 Mon Sep 17 00:00:00 2001
From: Rusty Bird <rustybird@net-c.com>
Date: Sat, 15 Apr 2023 16:05:47 +0000
Subject: [PATCH 022/332] Add sys-whonix to example qube list

---
 user/how-to-guides/backup-emergency-restore-v4.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/user/how-to-guides/backup-emergency-restore-v4.md b/user/how-to-guides/backup-emergency-restore-v4.md
index 0d318b5e..92b4866c 100644
--- a/user/how-to-guides/backup-emergency-restore-v4.md
+++ b/user/how-to-guides/backup-emergency-restore-v4.md
@@ -158,6 +158,7 @@ any GNU/Linux system.
         sys-firewall
         sys-net
         sys-usb
+        sys-whonix
         untrusted
         vault vm321/
         whonix-gw-16

From 4992cf406e67450134cf07c3987b823b5f044bcd Mon Sep 17 00:00:00 2001
From: noskb <63541981+noskb@users.noreply.github.com>
Date: Tue, 25 Apr 2023 02:07:22 +0000
Subject: [PATCH 023/332] Modernize uefi-troubleshooting.md

Remove workarounds that no longer function and modernize those that remain
---
 user/troubleshooting/uefi-troubleshooting.md | 280 +++++--------------
 1 file changed, 65 insertions(+), 215 deletions(-)

diff --git a/user/troubleshooting/uefi-troubleshooting.md b/user/troubleshooting/uefi-troubleshooting.md
index a364ee89..7c3834de 100644
--- a/user/troubleshooting/uefi-troubleshooting.md
+++ b/user/troubleshooting/uefi-troubleshooting.md
@@ -3,178 +3,42 @@ lang: en
 layout: doc
 permalink: /doc/uefi-troubleshooting/
 ref: 177
-title: UEFI troubleshooting
+title: UEFI Troubleshooting
 ---
 
-## Successfully installed in legacy mode, but had to change some kernel parameters
 
-If you've installed successfully in legacy mode but had to change some kernel parameters for it to work, you should try installing in UEFI mode with the same parameters.
+
+## Successfully installed in legacy mode, but had to change some xen parameters
+
+**Note**: If you make changes, you must boot from "Partition 1" explicitly from UEFI boot menu.
 
 **Change the xen configuration on a USB media**
 
 01. Attach the usb disk, mount the EFI partition (second partition available on the disk)
-02. Open a terminal and enter the command `sudo su -`. Use your preferred text editor (e.g `nano`) to edit your xen config (`EFI/BOOT/BOOTX64.cfg`):
+02. Open a terminal and enter the command `sudo su -`. Use your preferred text editor (e.g `vi`) to edit your xen config (`EFI/BOOT/grub.cfg`):
 
     ```
-    nano EFI/BOOT/BOOTX64.cfg
+    vi EFI/BOOT/grub.cfg
     ```
 
-03. Change the `kernel` key to add your kernel parameters on the boot entry of your choice
+03. Change the `multiboot2 /images/pxeboot/xen.gz` line to add your xen parameters on the boot entry of your choice
 04. Install using your modified boot entry
 
 **Change xen configuration directly in an iso image**
 01. Set up a loop device (replacing `X` with your ISO's version name): `losetup -P /dev/loop0 Qubes-RX-x86_64.iso`
 02. Mount the loop device: `sudo mount /dev/loop0p2 /mnt`
-03. Edit `EFI/BOOT/BOOTX64.cfg` to add your params to the `kernel` configuration key
+03. Edit `EFI/BOOT/grub.cfg` to add your params to the `multiboot2 /images/pxeboot/xen.gz` line
 04. Save your changes, unmount and dd to usb device
 
 ## Installation freezes before displaying installer
 
-If you have an Nvidia card, see also [Nvidia Troubleshooting](https://github.com/Qubes-Community/Contents/blob/master/docs/troubleshooting/nvidia-troubleshooting.md#disabling-nouveau).
+If you have an Nvidia card, see [Nvidia Troubleshooting](https://github.com/Qubes-Community/Contents/blob/master/docs/troubleshooting/nvidia-troubleshooting.md#disabling-nouveau).
 
-### Removing `noexitboot` and `mapbs`
-
-Some systems can freeze with the default UEFI install options.
-You can try the following to remove `noexitboot` and `mapbs`.
-
-1. Follow the [steps here](/doc/uefi-troubleshooting/#successfully-installed-in-legacy-mode-but-had-to-change-some-kernel-parameters) to edit the `[qubes-verbose]` section of your installer's `BOOTX64.cfg`.
-   You want to comment out the `mapbs` and `noexitboot` lines.
-   The end result should look like this:
-
-   ~~~
-   [qubes-verbose]
-   options=console=vga efi=attr=uc
-   # noexitboot=1
-   # mapbs=1
-   kernel=vmlinuz inst.stage2=hd:LABEL=Qubes-R4.0-x86_64 i915.alpha_support=1
-   ramdisk=initrd.img
-   ~~~
-
-2. Boot the installer and continue to install as normal, but don't reboot the system at the end when prompted.
-3. Go to `tty2` (Ctrl-Alt-F2).
-4. Use your preferred text editor (`nano` works) to edit `/mnt/sysimage/boot/efi/EFI/qubes/xen.cfg`, verifying the `noexitboot` and `mapbs` lines are not present.
-This is also a good time to make permanent any other changes needed to get the installer to work, such as `nouveau.modeset=0`.
-   For example:
-
-   ~~~
-   [4.14.18-1.pvops.qubes.x86_64]
-   options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode=scan efi=attr=uc
-   ~~~
-
-5. Go back to `tty6` (Ctrl-Alt-F6) and click `Reboot`.
-6. Continue with setting up default templates and logging in to Qubes.
-
-### Changing `options=console=` parameter to `none`
-
-If removing `noexitboot` and `mapbs` did not help, you can try changing the `options=console=` parameter to `none`. The detailed solution can be found in the comments of [this GitHub issue](https://github.com/QubesOS/qubes-issues/issues/5383)
-
-1. Follow the [steps here](/doc/uefi-troubleshooting/#successfully-installed-in-legacy-mode-but-had-to-change-some-kernel-parameters) to edit the `[qubes-verbose]` section of your installer's `BOOTX64.cfg`.
-   You want to change `options=console=vga` to `options=console=none`.
-   The end result should look like this:
-
-   ~~~
-   [qubes-verbose]
-   options=console=none efi=attr=uc
-   noexitboot=1
-   mapbs=1
-   kernel=vmlinuz inst.stage2=hd:LABEL=Qubes-R4.0-x86_64 i915.alpha_support=1
-   ramdisk=initrd.img
-   ~~~
-
-2. Boot the installer and continue to install as normal
-
-### Disable EFI runtime services
-
-On some early, buggy UEFI implementations, you may need to disable EFI under Qubes completely.
-This can sometimes be done by switching to legacy mode in your BIOS/UEFI configuration.
-If that's not an option there, or legacy mode does not work either, you can try the following to add `efi=no-rs`.
-Consider this approach as a last resort, because it will make every Xen update a manual process.
-
-1. Follow the [steps here](/doc/uefi-troubleshooting/#successfully-installed-in-legacy-mode-but-had-to-change-some-kernel-parameters) to edit the `[qubes-verbose]` section of your installer's `xen.cfg`.
-   You want to modify the `efi=attr=uc` setting and comment out the `mapbs` and `noexitboot` lines.
-   The end result should look like this:
-
-   ~~~
-   [qubes-verbose]
-   options=console=vga efi=no-rs
-   # noexitboot=1
-   # mapbs=1
-   kernel=vmlinuz inst.stage2=hd:LABEL=Qubes-R4.0-x86_64 i915.alpha_support=1
-   ramdisk=initrd.img
-   ~~~
-
-2. Boot the installer and continue to install as normal, until towards the end when you will receive a warning about being unable to create the EFI boot entry.
-   Click continue, but don't reboot the system at the end when prompted.
-3. Go to `tty2` (Ctrl-Alt-F2).
-4. Use your preferred text editor (`nano` works) to edit `/mnt/sysimage/boot/efi/EFI/qubes/xen.cfg`, adding the `efi=no-rs` option to the end of the `options=` line.
-   For example:
-
-   ~~~
-   [4.14.18-1.pvops.qubes.x86_64]
-   options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode=scan efi=no-rs
-   ~~~
-
-5. Execute the following commands:
-
-   ~~~
-   cp -R /mnt/sysimage/boot/efi/EFI/qubes /mnt/sysimage/boot/efi/EFI/BOOT
-   mv /mnt/sysimage/boot/efi/EFI/BOOT/xen-*.efi /mnt/sysimage/boot/efi/EFI/BOOT/BOOTX64.efi
-   mv /mnt/sysimage/boot/efi/EFI/BOOT/xen.cfg /mnt/sysimage/boot/efi/EFI/BOOT/BOOTX64.cfg
-   ~~~
-
-6. Go back to `tty6` (Ctrl-Alt-F6) and click `Reboot`.
-7. Continue with setting up default templates and logging in to Qubes.
-
-Whenever there is a kernel or Xen update for Qubes, you will need to follow [these steps](/doc/uefi-troubleshooting/#boot-device-not-recognized-after-installing) because your system is using the fallback UEFI bootloader in `[...]/EFI/BOOT` instead of directly booting to the Qubes entry under `[...]/EFI/qubes`.
 
 ## Installation from USB stick hangs on black screen
 
 Some laptops cannot read from an external boot device larger than 8GB. If you encounter a black screen when performing an installation from a USB stick, ensure you are using a USB drive less than 8GB, or a partition on that USB lesser than 8GB and of format FAT32.
 
-## Installation completes successfully but then boot loops or hangs on black screen
-
-There is a [common bug in UEFI implementation](http://xen.markmail.org/message/f6lx2ab4o2fch35r) affecting mostly Lenovo systems, but probably some others too.
-While some systems need `mapbs` and/or `noexitboot` disabled to boot, others require them enabled at all times.
-Although these are enabled by default in the installer, they are disabled after the first stage of a successful install.
-You can re-enable them either as part of the install process:
-
-1. Perform installation normally, but don't reboot the system at the end yet.
-2. Go to `tty2` (Ctrl-Alt-F2).
-3. Enable `mapbs` and/or `noexitboot` on the just installed system.
-   Edit `/mnt/sysimage/boot/efi/EFI/qubes/xen.cfg` (you can use `vi` or `nano` editor) and add to every kernel section:
-
-    ```
-    mapbs=1
-    noexitboot=1
-    ```
-
-    **Note:** You must add these parameters on two separate new lines (one
-    parameter on each line) at the end of each section that includes a kernel
-    line (i.e., all sections except the first one, since it doesn't have a
-    kernel line).
-
-4. Go back to `tty6` (Ctrl-Alt-F6) and click `Reboot`.
-5. Continue with setting up default templates and logging in to Qubes.
-
-Or if you have already rebooted after the first stage install and have encountered this issue, by:
-
-1. Boot into [rescue mode](/doc/uefi-troubleshooting/#accessing-installer-rescue-mode-on-uefi).
-2. Enable `mapbs` and/or `noexitboot` on the just installed system.
-   Edit `/mnt/sysimage/boot/efi/EFI/qubes/xen.cfg` (you can use `vi` or `nano` editor) and add to every kernel section:
-
-    ```
-    mapbs=1
-    noexitboot=1
-    ```
-
-    **Note:** You must add these parameters on two separate new lines (one
-    parameter on each line) at the end of each section that includes a kernel
-    line (i.e., all sections except the first one, since it doesn't have a
-    kernel line).
-
-3. Type `reboot`.
-4. Continue with setting up default templates and logging in to Qubes.
-
 ## Installation completes successfully but then system crash/restarts on next boot
 
 Some Dell systems and probably others have [another bug in UEFI firmware](http://markmail.org/message/amw5336otwhdxi76).
@@ -187,7 +51,7 @@ You can re-enable it either as part of the install process:
 3. Execute:
 
     ```
-    sed -i -e 's/^options=.*/\0 efi=attr=uc/' /mnt/sysimage/boot/efi/EFI/qubes/xen.cfg
+    sed -i -e 's/ucode=scan/\0 efi=attr=uc/' /mnt/sysimage/boot/efi/EFI/qubes/grub.cfg
     ```
 
 4. Go back to `tty6` (Ctrl-Alt-F6) and click `Reboot`.
@@ -195,87 +59,73 @@ You can re-enable it either as part of the install process:
 
 Or if you have already rebooted after the first stage install and have encountered this issue, by:
 
-1. Boot into [rescue mode](/doc/uefi-troubleshooting/#accessing-installer-rescue-mode-on-uefi).
-2. Execute:
+1. Boot Qubes OS install media into [rescue mode](/doc/uefi-troubleshooting/#accessing-installer-rescue-mode-on-uefi)
+
+2. Press '3' to go to the shell
+
+3. Find and mount the EFI system partition. (replace `/dev/sda` with your disk name. If unsure, use the `lsblk` command to display a list of disks):
+    ```
+    fdisk -l /dev/sda | grep EFI
+    ```
+    The output should look like this:
+    ```
+    /dev/sda1   2048    1230847 1228800 600M EFI System
+    ```
+    Then mount it:
+    ```
+    mkdir -p /mnt/sysimage/boot/efi
+    mount /dev/sda1 /mnt/sysimage/boot/efi
+    ```
+4. Execute:
 
     ```
-    sed -i -e 's/^options=.*/\0 efi=attr=uc/' /mnt/sysimage/boot/efi/EFI/qubes/xen.cfg
+    sed -i -e 's/ucode=scan/\0 efi=attr=uc/' /mnt/sysimage/boot/efi/EFI/qubes/grub.cfg
     ```
 
-3. Type `reboot`.
-4. Continue with setting up default templates and logging in to Qubes.
+5. Type `reboot`.
+6. Continue with setting up default templates and logging in to Qubes.
 
 ## Boot device not recognized after installing
 
 Some firmware will not recognize the default Qubes EFI configuration.
 As such, it will have to be manually edited to be bootable.
-This will need to be done after every kernel and Xen update to ensure you use the most recently installed versions.
 
-1. Copy the `/boot/efi/EFI/qubes/` directory to `/boot/efi/EFI/BOOT/` (the contents of `/boot/efi/EFI/BOOT` should be identical to `/boot/efi/EFI/qubes` besides what is described in steps 2 and 3):
+1. Boot Qubes OS install media into [rescue mode](/doc/uefi-troubleshooting/#accessing-installer-rescue-mode-on-uefi)
+
+2. Press '3' to go to the shell
+
+3. Find and mount the EFI system partition. (replace `/dev/sda` with your disk name. If unsure, use the `lsblk` command to display a list of disks):
+    ```
+    fdisk -l /dev/sda | grep EFI
+    ```
+    The output should look like this:
+    ```
+    /dev/sda1   2048    1230847 1228800 600M EFI System
+    ```
+    Then mount it:
+    ```
+    mkdir -p /mnt/sysimage/boot/efi
+    mount /dev/sda1 /mnt/sysimage/boot/efi
+    ```
+    
+4. Copy `grubx64.efi` to the fallback path:
+    
+    ```
+    cp /mnt/sysimage/boot/efi/EFI/qubes/grubx64.efi /mnt/sysimage/boot/efi/EFI/BOOT/bootx64.efi
+    ```
+    
+5. Type `reboot`
+
+## "Qubes" boot option is missing after removing / attaching a disk or updating the BIOS
+1. Boot Qubes OS install media into [rescue mode](/doc/uefi-troubleshooting/#accessing-installer-rescue-mode-on-uefi)
+
+2. Press '3' to go to the shell
+3. Create boot entry in EFI firmware (replace `/dev/sda` with your disk name and `-p 1` with `/boot/efi` partition number):
 
     ```
-    cp -r /boot/efi/EFI/qubes/. /boot/efi/EFI/BOOT
-    ```
-
-2. Rename `/boot/efi/EFI/BOOT/xen.cfg` to `/boot/efi/EFI/BOOT/BOOTX64.cfg`:
-
-    ```
-    mv /boot/efi/EFI/BOOT/xen.cfg /boot/efi/EFI/BOOT/BOOTX64.cfg
-    ```
-
-3. Copy `/boot/efi/EFI/qubes/xen-*.efi` to `/boot/efi/EFI/qubes/xen.efi` and `/boot/efi/EFI/BOOT/BOOTX64.efi`.
-   For example, with Xen 4.8.3 (you may need to confirm file overwrite):
-
-    ```
-    cp /boot/efi/EFI/qubes/xen-4.8.3.efi /boot/efi/EFI/qubes/xen.efi
-    cp /boot/efi/EFI/qubes/xen-4.8.3.efi /boot/efi/EFI/BOOT/BOOTX64.efi
-    ```
-
-## Installation finished but "Qubes" boot option is missing and xen.cfg is empty / Installation fails with "failed to set new efi boot target"
-
-In some cases installer fails to finish EFI setup and leave the system without a Qubes-specific EFI configuration.
-In such a case you need to finish those parts manually.
-You can do that just after installation (switch to `tty2` with Ctrl-Alt-F2), or by booting from installation media in [rescue mode](/doc/uefi-troubleshooting/#accessing-installer-rescue-mode-on-uefi).
-
-1. Examine `/boot/efi/EFI/qubes` (if using Qubes installation media, it's in `/mnt/sysimage/boot/efi/EFI/qubes`). You should see 4 files there:
-
-    - xen.cfg (empty, size 0)
-    - xen-(xen-version).efi
-    - vmlinuz-(kernel-version)
-    - initramfs-(kernel-version).img
-
-2. Copy `xen-(xen-version).efi` to `xen.efi`:
-
-    ```
-    cd /mnt/sysimage/boot/efi/EFI/qubes
-    cp xen-*.efi xen.efi
-    ```
-
-3. Create xen.cfg with this content (adjust kernel version, and filesystem
-   locations, below values are based on default installation of Qubes 3.2):
-
-    ```
-    [global]
-    default=4.4.14-11.pvops.qubes.x86_64
-
-    [4.4.14-11.pvops.qubes.x86_64]
-    options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M
-    kernel=vmlinuz-4.4.14-11.pvops.qubes.x86_64 root=/dev/mapper/qubes_dom0-root rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.preliminary_hw_support=1 rhgb quiet
-    ramdisk=initramfs-4.4.14-11.pvops.qubes.x86_64.img
-    ```
-
-4. Create boot entry in EFI firmware (replace `/dev/sda` with your disk name and `-p 1` with `/boot/efi` partition number):
-
-    ```
-    efibootmgr -v -c -u -L Qubes -l /EFI/qubes/xen.efi -d /dev/sda -p 1 "placeholder /mapbs /noexitboot"
+    efibootmgr -v -c -u -L Qubes -l /EFI/qubes/grubx64.efi -d /dev/sda -p 1 
     ```
 
 ## Accessing installer Rescue mode on UEFI
 
-In UEFI mode, the installer does not have a boot menu, but boots directly into the installation wizard.
-To get into Rescue mode, you need to switch to tty2 (Ctrl+Alt+F2) and then execute:
-
-~~~
-pkill -9 anaconda
-anaconda --rescue
-~~~
+Choose "Rescue a Qubes OS system" from grub2 boot menu.

From 33e4d73db89e8a9c7fa23a496495e8906164bb60 Mon Sep 17 00:00:00 2001
From: Kamil Aronowski <kamil.aronowski@yahoo.com>
Date: Fri, 12 May 2023 16:44:43 +0200
Subject: [PATCH 024/332] Update 2 attachments in the "Getting started" guide

Several attachments have been already added to the qubes-attachments
repository but remained unused. This change makes 2 of them be present
in the "Getting started" guide.
---
 introduction/getting-started.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/introduction/getting-started.md b/introduction/getting-started.md
index 1ac922d5..93833e45 100644
--- a/introduction/getting-started.md
+++ b/introduction/getting-started.md
@@ -80,7 +80,7 @@ random web surfing in a different qube, you wouldn't want to accidentally enter
 your banking password in the latter! The colored frames help to avoid such
 mistakes.
 
-[![snapshot_40.png](/attachment/doc/r4.0-snapshot_40.png)](/attachment/doc/r4.0-snapshot_40.png)
+[![snapshot_41.png](/attachment/doc/r4.1-snapshot_40.png)](/attachment/doc/r4.1-snapshot_40.png)
 
 Most Qubes users associate red with what's untrusted and dangerous (like a red
 light: stop! danger!), green with what's safe and trusted, and yellow and
@@ -142,7 +142,7 @@ To see all of your qubes at the same time, you can use the **Qube Manager** (go
 to the App Menu → Qubes Tools → Qube Manager), which displays the states of
 all the qubes in your system, even the ones that aren't running.
 
-[![r4.0-qubes-manager.png](/attachment/doc/r4.0-qubes-manager.png)](/attachment/doc/r4.0-qubes-manager.png)
+[![r4.1-qubes-manager.png](/attachment/doc/r4.1-qubes-manager.png)](/attachment/doc/r4.1-qubes-manager.png)
 
 #### Command-line interface
 

From a830998985770cc4e91fafa843c1c7be1e0126b4 Mon Sep 17 00:00:00 2001
From: Piotr Bartman <prbartman@invisiblethingslab.com>
Date: Sat, 20 May 2023 23:29:24 +0200
Subject: [PATCH 025/332] migration to fido2: update docs

---
 developer/general/gsod.md                     |   2 +-
 introduction/intro.md                         |   4 +-
 user/how-to-guides/how-to-use-usb-devices.md  |   2 +-
 user/security-in-qubes/ctap-proxy.md          | 143 ++++++++++++++++++
 .../device-handling-security.md               |   2 +-
 user/security-in-qubes/u2f-proxy.md           | 135 -----------------
 user/security-in-qubes/yubi-key.md            |   4 +-
 user/templates/minimal-templates.md           |   4 +-
 8 files changed, 152 insertions(+), 144 deletions(-)
 create mode 100644 user/security-in-qubes/ctap-proxy.md
 delete mode 100644 user/security-in-qubes/u2f-proxy.md

diff --git a/developer/general/gsod.md b/developer/general/gsod.md
index d02b5163..ab8c0086 100644
--- a/developer/general/gsod.md
+++ b/developer/general/gsod.md
@@ -59,7 +59,7 @@ Below is an example of the content (which is already [documented](/doc/)) that t
 - Passwordless root
 - Anti Evil Maid
 - Split GPG
-- U2F proxy
+- CTAP proxy
 - YubiKey
 - Whonix
 - How to install and use a VPN in Qubes
diff --git a/introduction/intro.md b/introduction/intro.md
index aa89a5cd..142d4095 100644
--- a/introduction/intro.md
+++ b/introduction/intro.md
@@ -136,9 +136,9 @@ title: Introduction
     </p>
   </div>
   <div class="col-lg-4 col-md-4 col-xs-12">
-    <h3>U2F proxy</h3>
+    <h3>CTAP proxy</h3>
     <p>
-      Operate <a href="/doc/u2f-proxy/">Qubes U2F proxy</a> to use your
+      Operate <a href="/doc/ctap-proxy/">Qubes CTAP proxy</a> to use your
       two-factor authentication devices without exposing your web browser to the
       full USB stack.
     </p>
diff --git a/user/how-to-guides/how-to-use-usb-devices.md b/user/how-to-guides/how-to-use-usb-devices.md
index e515231f..0618bb04 100644
--- a/user/how-to-guides/how-to-use-usb-devices.md
+++ b/user/how-to-guides/how-to-use-usb-devices.md
@@ -25,7 +25,7 @@ Examples of valid cases for USB-passthrough:
 - [external audio devices](/doc/external-audio/)
 - [optical drives](/doc/recording-optical-discs/) for recording
 
-(If you are thinking to use a two-factor-authentication device, [there is an app for that](/doc/u2f-proxy/).
+(If you are thinking to use a two-factor-authentication device, [there is an app for that](/doc/ctap-proxy/).
 But it has some [issues](https://github.com/QubesOS/qubes-issues/issues/4661).)
 
 ## Attaching And Detaching a USB Device
diff --git a/user/security-in-qubes/ctap-proxy.md b/user/security-in-qubes/ctap-proxy.md
new file mode 100644
index 00000000..6ba1f696
--- /dev/null
+++ b/user/security-in-qubes/ctap-proxy.md
@@ -0,0 +1,143 @@
+---
+lang: en
+layout: doc
+permalink: /doc/ctap-proxy/
+ref: 167
+title: CTAP proxy
+---
+
+The [Qubes CTAP Proxy](https://github.com/QubesOS/qubes-app-u2f) is a secure proxy intended to make use of CTAP two-factor authentication devices with web browsers without exposing the browser to the full USB stack, not unlike the [USB keyboard and mouse proxies](/doc/usb/) implemented in Qubes.
+
+## What is CTAP, U2F, FIDO2?
+
+CTAP, U2F, and FIDO2 are all related to authentication protocols and standards developed by the FIDO Alliance. CTAP has two versions: CTAP1 and CTAP2:
+
+1. [CTAP1/U2F](https://en.wikipedia.org/wiki/Universal_2nd_Factor) (Universal 2nd Factor): U2F is an earlier protocol developed by the FIDO Alliance as part of the FIDO U2F standard. It provides a strong second-factor authentication method using dedicated hardware security keys. U2F allows users to authenticate to online services by simply plugging in a U2F-compliant security key and pressing a button, providing a higher level of security compared to traditional passwords.
+
+2. [CTAP2](https://en.wikipedia.org/wiki/Client_to_Authenticator_Protocol) (Client to Authenticator Protocol): CTAP2 is a protocol within the FIDO2 framework that enables communication between a client device (e.g., a computer or smartphone) and an authenticator (e.g., a hardware device). CTAP allows for secure and convenient authentication using public key cryptography and strong authentication factors. 
+
+3. [FIDO2](https://en.wikipedia.org/wiki/FIDO_Alliance): FIDO2 is a set of standards and protocols developed by the FIDO Alliance for passwordless and strong authentication. It combines two main components: CTAP (Client to Authenticator Protocol) and WebAuthn (Web Authentication API). FIDO2 enables users to authenticate to online services using various authentication methods, such as biometrics, PINs, or hardware tokens, instead of relying on passwords.
+
+The aim of these protocols is to introduce additional control which provides [good protection](https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/) in cases in which the passphrase is stolen (e.g. by phishing or keylogging).
+While passphrase compromise may not be obvious to the user, a physical device that cannot be duplicated must be stolen to be used outside the owner's control.
+Nonetheless, it is important to note at the outset that CTAP cannot guarantee security when the host system is compromised (e.g. a malware-infected operating system under an adversary's control).
+
+The CTAP specification defines protocols for multiple layers from USB to the browser API, and the whole stack is intended to be used with web applications (most commonly websites) in browsers.
+In most cases, authenticators are USB dongles.
+The protocol is very simple, allowing the devices to store very little state inside (so the tokens may be reasonably cheap) while simultaneously authenticating a virtually unlimited number of services (so each person needs only one token, not one token per application).
+The user interface is usually limited to a single LED and a button that is pressed to confirm each transaction, so the devices themselves are also easy to use.
+Both CTAP1 and CTAP2 share the same underlying transports: USB Human Interface Device (USB HID), Near Field Communication (NFC), and Bluetooth Smart / Bluetooth Low Energy Technology (BLE).
+
+Currently, the most common form of two-step authentication consists of a numeric code that the user manually types into a web application.
+These codes are typically generated by an app on the user's smartphone or sent via SMS.
+By now, it is well-known that this form of two-step authentication is vulnerable to phishing and man-in-the-middle attacks due to the fact that the application requesting the two-step authentication code is typically not itself authenticated by the user.
+(In other words, users can accidentally give their codes to attackers because they do not always know who is really requesting the code.) In the CTAP model, by contrast, the browser ensures that the token receives valid information about the web application requesting authentication, so the token knows which application it is authenticating (for details, see [here](https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.html#site-specific-public-private-key-pairs)).
+Nonetheless, [some attacks are still possible](https://www.wired.com/story/chrome-yubikey-phishing-webusb/) even with CTAP (more on this below).
+
+## The Qubes approach to CTAP
+
+In a conventional setup, web browsers and the USB stack (to which the authenticator is connected) are all running in the same monolithic OS.
+Since the CTAP model assumes that the browser is trustworthy, any browser in the OS is able to access any key stored on the authenticator.
+The user has no way to know which keys have been accessed by which browsers for which services.
+If any of the browsers are compromised, it should be assumed that all the token's keys have been compromised.
+(This problem can be mitigated, however, if the CTAP device has a special display to show the user what's being authenticated.) Moreover, since the USB stack is in the same monolithic OS, the system is vulnerable to attacks like [BadUSB](https://www.blackhat.com/us-14/briefings.html#badusb-on-accessories-that-turn-evil).
+
+In Qubes OS, by contrast, it is possible to securely compartmentalise the browser in one qube and the USB stack in another so that they are always kept separate from each other.
+The Qubes CTAP Proxy then allows the token connected to the USB stack in one qube to communicate with the browser in a separate qube.
+We operate under the assumption that the USB stack is untrusted from the point of view of the browser and also that the browser is not to be trusted blindly by the token.
+Therefore, the token is never in the same qube as the browser.
+Our proxy forwards only the data necessary to actually perform the authentication, leaving all unnecessary data out, so it won't become a vector of attack.
+This is depicted in the diagram below (click for full size).
+
+[![Qubes CTAP Proxy diagram](/attachment/doc/ctap.svg)](/attachment/doc/ctap.svg)
+
+The Qubes CTAP Proxy has two parts: the frontend and the backend.
+The frontend runs in the same qube as the browser and presents a fake USB-like HID device using `uhid`.
+The backend runs in `sys-usb` and behaves like a browser.
+This is done using the `fido2` reference library.
+All of our code was written in Python.
+The standard [qrexec](/doc/qrexec3/) policy is responsible for directing calls to the appropriate domains.
+
+The `vault` qube with a dashed line in the bottom portion of the diagram depicts future work in which we plan to implement the Qubes CTAP Proxy with a software token in an isolated qube rather than a physical hardware token.
+This is similar to the manner in which [Split GPG](/doc/split-gpg/) allows us to emulate the smart card model without physical smart cards.
+
+One very important assumption of protocol is that the browser verifies every request sent to the authenticator --- in particular, that the web application sending an authentication request matches the application that would be authenticated by answering that request (in order to prevent, e.g., a phishing site from sending an authentication request for your bank's site).
+With the WebUSB feature in Chrome, however, a malicious website can [bypass](https://www.wired.com/story/chrome-yubikey-phishing-webusb/) this safeguard by connecting directly to the token instead of using the browser's CTAP API.
+
+The Qubes CTAP Proxy also prevents this class of attacks by implementing an additional verification layer.
+This verification layer allows you to enforce, for example, that the web browser in your `twitter` qube can only access the CTAP key associated with `https://twitter.com`.
+This means that if anything in your `twitter` qube were compromised --- the browser or even the OS itself --- it would still not be able to access the CTAP keys on your token for any other websites or services, like your email and bank accounts.
+This is another significant security advantage over monolithic systems.
+(For details and instructions, see the [Advanced usage](#advanced-usage-per-qube-key-access) section below.)
+
+For even more protection, you can combine this with the [Qubes firewall](/doc/firewall/) to ensure, for example, that the browser in your `banking` qube accesses only one website (your bank's website).
+By configuring the Qubes firewall to prevent your `banking` qube from accessing any other websites, you reduce the risk of another website compromising the browser in an attempt to bypass CTAP authentication.
+
+## Installation
+
+These instructions assume that there is a `sys-usb` qube that holds the USB stack, which is the default configuration in most Qubes OS installations.
+
+In dom0:
+
+```
+$ sudo qubes-dom0-update qubes-ctap-dom0
+$ qvm-service --enable work qubes-ctap-proxy
+```
+
+The above assumes a `work` qube in which you would like to enable ctap. Repeat the `qvm-service` command for all qubes that should have the proxy enabled.  Alternatively, you can add `qubes-ctap-proxy` in VM settings -> Services in the Qube Manager of each qube you would like to enable the service.
+
+In Fedora templates:
+
+```
+$ sudo dnf install qubes-ctap
+```
+
+In Debian templates:
+
+```
+$ sudo apt install qubes-ctap
+```
+
+As usual with software updates, shut down the templates after installation, then restart `sys-usb` and all qubes that use the proxy.
+After that, you may use your CTAP authenticator (but see [Browser support](#template-and-browser-support) below).
+
+## Advanced usage: per-qube key access
+
+If you are using Qubes 4.0, you can further compartmentalise your CTAP keys by restricting each qube's access to specific keys.
+For example, you could make it so that your `twitter` qube (and, therefore, all web browsers in your `twitter` qube) can access only the key on your CTAP token for `https://twitter.com`, regardless of whether any of the web browsers in your `twitter` qube or the `twitter` qube itself are compromised.
+If your `twitter` qube makes an authentication request for your bank website, it will be denied at the Qubes policy level.
+
+To enable this, create a file in dom0 named `/etc/qubes/policy.d/30-user-ctapproxy.policy` with the following content:
+
+```
+policy.RegisterArgument +ctap.GetAssertion sys-usb @anyvm allow target=dom0
+```
+
+Next, empty the contents of `/etc/qubes-rpc/policy/ctap.GetAssertion` so that it is a blank file.
+Do not delete the file itself.
+(If you do, the default file will be recreated the next time you update, so it will no longer be empty.) Finally, follow your web application's instructions to enroll your token and use it as usual.
+(This enrollment process depends on the web application and is in no way specific to Qubes CTAP.)
+
+The default model is to allow a qube to access all and only the keys that were enrolled by that qube.
+For example, if your `banking` qube enrolls your banking key, and your `twitter` qube enrolls your Twitter key, then your `banking` qube will have access to your banking key but not your Twitter key, and your `twitter` qube will have access to your Twitter key but not your banking key.
+
+## Non-default USB qube name
+
+If your USB qube is named differently than `sys-usb`, then do the following in the appropriate template(s):
+
+```
+systemctl enable qubes-ctapproxy@USB_QUBE.service
+systemctl disable qubes-ctapproxy@sys-usb.service
+```
+
+Replace `USB_QUBE` with the actual USB qube name.
+
+Do not forget to change the sys-usb qube name in the policy `/etc/qubes/policy.d/30-user-ctapproxy.policy`.
+
+## Template and browser support
+
+The large number of possible combinations of template (Fedora 37, 38; Debian 10, 11) and browser (multiple Google Chrome versions, multiple Chromium versions, multiple Firefox versions) made it impractical for us to test every combination that users are likely to attempt with the Qubes CTAP Proxy.
+In some cases, you may be the first person to try a particular combination.
+Consequently, (and as with any new feature), users will inevitably encounter bugs.
+We ask for your patience and understanding in this regard.
+As always, please [report any bugs you encounter](/doc/issue-tracking/).
diff --git a/user/security-in-qubes/device-handling-security.md b/user/security-in-qubes/device-handling-security.md
index 2301020f..233b1ab3 100644
--- a/user/security-in-qubes/device-handling-security.md
+++ b/user/security-in-qubes/device-handling-security.md
@@ -71,4 +71,4 @@ Locking the screen (with a traditional password) does not solve the problem, bec
 One possibility is to set up the screen locker to require an additional step to unlock (i.e., two-factor authentication).
 One way to achieve this is to use a [YubiKey](/doc/YubiKey/), or some other hardware token, or even to manually enter a one-time password.
 
-Support for [two factor authentication](/news/2018/09/11/qubes-u2f-proxy/) was recently added, though there are [issues](https://github.com/QubesOS/qubes-issues/issues/4661).
+Support for [two factor authentication](/news/2018/09/11/qubes-ctap-proxy/) was recently added, though there are [issues](https://github.com/QubesOS/qubes-issues/issues/4661).
diff --git a/user/security-in-qubes/u2f-proxy.md b/user/security-in-qubes/u2f-proxy.md
deleted file mode 100644
index 81c0520b..00000000
--- a/user/security-in-qubes/u2f-proxy.md
+++ /dev/null
@@ -1,135 +0,0 @@
----
-lang: en
-layout: doc
-permalink: /doc/u2f-proxy/
-ref: 167
-title: U2F proxy
----
-
-The [Qubes U2F Proxy](https://github.com/QubesOS/qubes-app-u2f) is a secure proxy intended to make use of U2F two-factor authentication devices with web browsers without exposing the browser to the full USB stack, not unlike the [USB keyboard and mouse proxies](/doc/usb/) implemented in Qubes.
-
-## What is U2F?
-
-[U2F](https://en.wikipedia.org/wiki/U2F), which stands for "Universal 2nd Factor", is a framework for authentication using hardware devices (U2F tokens) as "second factors", i.e. *what you have* as opposed to *what you know*, like a passphrase.
-This additional control provides [good protection](https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/) in cases in which the passphrase is stolen (e.g. by phishing or keylogging).
-While passphrase compromise may not be obvious to the user, a physical device that cannot be duplicated must be stolen to be used outside of the owner's control.
-Nonetheless, it is important to note at the outset that U2F cannot guarantee security when the host system is compromised (e.g. a malware-infected operating system under an adversary's control).
-
-The U2F specification defines protocols for multiple layers from USB to the browser API, and the whole stack is intended to be used with web applications (most commonly websites) in browsers.
-In most cases, tokens are USB dongles.
-The protocol is very simple, allowing the devices to store very little state inside (so the tokens may be reasonably cheap) while simultaneously authenticating a virtually unlimited number of services (so each person needs only one token, not one token per application).
-The user interface is usually limited to a single LED and a button that is pressed to confirm each transaction, so the devices themselves are also easy to use.
-
-Currently, the most common form of two-step authentication consists of a numeric code that the user manually types into a web application.
-These codes are typically generated by an app on the user's smartphone or sent via SMS.
-By now, it is well-known that this form of two-step authentication is vulnerable to phishing and man-in-the-middle attacks due to the fact that the application requesting the two-step authentication code is typically not itself authenticated by the user.
-(In other words, users can accidentally give their codes to attackers because they do not always know who is really requesting the code.) In the U2F model, by contrast, the browser ensures that the token receives valid information about the web application requesting authentication, so the token knows which application it is authenticating (for details, see [here](https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.html#site-specific-public-private-key-pairs)).
-Nonetheless, [some attacks are still possible](https://www.wired.com/story/chrome-yubikey-phishing-webusb/) even with U2F (more on this below).
-
-## The Qubes approach to U2F
-
-In a conventional setup, web browsers and the USB stack (to which the U2F token is connected) are all running in the same monolithic OS.
-Since the U2F model assumes that the browser is trustworthy, any browser in the OS is able to access any key stored on the U2F token.
-The user has no way to know which keys have been accessed by which browsers for which services.
-If any of the browsers are compromised, it should be assumed that all of the token's keys have been compromised.
-(This problem can be mitigated, however, if the U2F device has a special display to show the user what's being authenticated.) Moreover, since the USB stack is in the same monolithic OS, the system is vulnerable to attacks like [BadUSB](https://www.blackhat.com/us-14/briefings.html#badusb-on-accessories-that-turn-evil).
-
-In Qubes OS, by contrast, it is possible to securely compartmentalise the browser in one qube and the USB stack in another so that they are always kept separate from each other.
-The Qubes U2F Proxy then allows the token connected to the USB stack in one qube to communicate with the browser in a separate qube.
-We operate under the assumption that the USB stack is untrusted from the point of view of the browser and also that the browser is not to be trusted blindly by the token.
-Therefore, the token is never in the same qube as the browser.
-Our proxy forwards only the data necessary to actually perform the authentication, leaving all unnecessary data out, so it won't become a vector of attack.
-This is depicted in the diagram below (click for full size).
-
-[![Qubes U2F Proxy diagram](/attachment/doc/u2f.svg)](/attachment/doc/u2f.svg)
-
-The Qubes U2F Proxy has two parts: the frontend and the backend.
-The frontend runs in the same qube as the browser and presents a fake USB-like HID device using `uhid`.
-The backend runs in `sys-usb` and behaves like a browser.
-This is done using the `u2flib_host` reference library.
-All of our code was written in Python.
-The standard [qrexec](/doc/qrexec3/) policy is responsible for directing calls to the appropriate domains.
-
-The `vault` qube with a dashed line in the bottom portion of the diagram depicts future work in which we plan to implement the Qubes U2F Proxy with a software token in an isolated qube rather than a physical hardware token.
-This is similar to the manner in which [Split GPG](/doc/split-gpg/) allows us to emulate the smart card model without physical smart cards.
-
-One very important assumption of U2F is that the browser verifies every request sent to the U2F token --- in particular, that the web application sending an authentication request matches the application that would be authenticated by answering that request (in order to prevent, e.g., a phishing site from sending an authentication request for your bank's site).
-With the WebUSB feature in Chrome, however, a malicious website can [bypass](https://www.wired.com/story/chrome-yubikey-phishing-webusb/) this safeguard by connecting directly to the token instead of using the browser's U2F API.
-
-The Qubes U2F Proxy also prevents this class of attacks by implementing an additional verification layer.
-This verification layer allows you to enforce, for example, that the web browser in your `twitter` qube can only access the U2F key associated with `https://twitter.com`.
-This means that if anything in your `twitter` qube were compromised --- the browser or even the OS itself --- it would still not be able to access the U2F keys on your token for any other websites or services, like your email and bank accounts.
-This is another significant security advantage over monolithic systems.
-(For details and instructions, see the [Advanced usage](#advanced-usage-per-qube-key-access) section below.)
-
-For even more protection, you can combine this with the [Qubes firewall](/doc/firewall/) to ensure, for example, that the browser in your `banking` qube accesses only one website (your bank's website).
-By configuring the Qubes firewall to prevent your `banking` qube from accessing any other websites, you reduce the risk of another website compromising the browser in an attempt to bypass U2F authentication.
-
-## Installation
-
-These instructions assume that there is a `sys-usb` qube that holds the USB stack, which is the default configuration in most Qubes OS installations.
-
-In dom0:
-
-```
-$ sudo qubes-dom0-update qubes-u2f-dom0
-$ qvm-service --enable work qubes-u2f-proxy
-```
-
-The above assumes a `work` qube in which you would like to enable u2f. Repeat the `qvm-service` command for all qubes that should have the proxy enabled.  Alternatively, you can add `qubes-u2f-proxy` in VM settings -> Services in the Qube Manager of each qube you would like to enable the service.
-
-In Fedora templates:
-
-```
-$ sudo dnf install qubes-u2f
-```
-
-In Debian templates:
-
-```
-$ sudo apt install qubes-u2f
-```
-
-As usual with software updates, shut down the templates after installation, then restart `sys-usb` and all qubes that use the proxy.
-After that, you may use your U2F token (but see [Browser support](#template-and-browser-support) below).
-
-## Advanced usage: per-qube key access
-
-If you are using Qubes 4.0, you can further compartmentalise your U2F keys by restricting each qube's access to specific keys.
-For example, you could make it so that your `twitter` qube (and, therefore, all web browsers in your `twitter` qube) can access only the key on your U2F token for `https://twitter.com`, regardless of whether any of the web browsers in your `twitter` qube or the `twitter` qube itself are compromised.
-If your `twitter` qube makes an authentication request for your bank website, it will be denied at the Qubes policy level.
-
-To enable this, create a file in dom0 named `/etc/qubes/policy.d/30-user-u2fproxy.policy` with the following content:
-
-```
-policy.RegisterArgument +u2f.Authenticate sys-usb @anyvm allow target=dom0
-```
-
-Next, empty the contents of `/etc/qubes-rpc/policy/u2f.Authenticate` so that it is a blank file.
-Do not delete the file itself.
-(If you do, the default file will be recreated the next time you update, so it will no longer be empty.) Finally, follow your web application's instructions to enroll your token and use it as usual.
-(This enrollment process depends on the web application and is in no way specific to Qubes U2F.)
-
-The default model is to allow a qube to access all and only the keys that were enrolled by that qube.
-For example, if your `banking` qube enrolls your banking key, and your `twitter` qube enrolls your Twitter key, then your `banking` qube will have access to your banking key but not your Twitter key, and your `twitter` qube will have access to your Twitter key but not your banking key.
-
-## Non-default USB qube name
-
-If your USB qube is named differently than `sys-usb`, then do the following in the appropriate template(s):
-
-```
-systemctl enable qubes-u2fproxy@USB_QUBE.service
-systemctl disable qubes-u2fproxy@sys-usb.service
-```
-
-Replace `USB_QUBE` with the actual USB qube name.
-
-Do not forget to change the sys-usb qube name in the policy `/etc/qubes/policy.d/30-user-u2fproxy.policy`.
-
-## Template and browser support
-
-The large number of possible combinations of template (Fedora 27, 28; Debian 8, 9) and browser (multiple Google Chrome versions, multiple Chromium versions, multiple Firefox versions) made it impractical for us to test every combination that users are likely to attempt with the Qubes U2F Proxy.
-In some cases, you may be the first person to try a particular combination.
-Consequently (and as with any new feature), users will inevitably encounter bugs.
-We ask for your patience and understanding in this regard.
-As always, please [report any bugs you encounter](/doc/issue-tracking/).
diff --git a/user/security-in-qubes/yubi-key.md b/user/security-in-qubes/yubi-key.md
index 8e231592..a4cdfc68 100644
--- a/user/security-in-qubes/yubi-key.md
+++ b/user/security-in-qubes/yubi-key.md
@@ -22,8 +22,8 @@ Most use cases for the YubiKey can be achieved exactly as described by the
 manufacturer or other instructions found online. One usually just needs to
 attach the YubiKey to the corresponding app qube to get the same result (see the
 documentation on how to use [USB devices](/doc/how-to-use-usb-devices/) in Qubes
-OS accordingly). The recommended way for using U2F in Qubes is described
-[here](https://www.qubes-os.org/doc/u2f-proxy/).
+OS accordingly). The recommended way for using CTAP in Qubes is described
+[here](https://www.qubes-os.org/doc/ctap-proxy/).
 
 ## Multi-factor login for Qubes OS
 
diff --git a/user/templates/minimal-templates.md b/user/templates/minimal-templates.md
index 8d63fbc4..43349d95 100644
--- a/user/templates/minimal-templates.md
+++ b/user/templates/minimal-templates.md
@@ -192,7 +192,7 @@ are:
 Also, there are packages to provide additional services:
 
 - `qubes-gpg-split`: For implementing split GPG.
-- `qubes-u2f`: For implementing secure forwarding of U2F messages.
+- `qubes-ctap`: For implementing secure forwarding of CTAP messages.
 - `qubes-pdf-converter`: For implementing safe conversion of PDFs.
 - `qubes-img-converter`: For implementing safe conversion of images.
 - `qubes-snapd-helper`: If you want to use snaps in qubes.
@@ -287,7 +287,7 @@ are:
 Also, there are packages to provide additional services:
 
 - `qubes-gpg-split`: For implementing split GPG.
-- `qubes-u2f`: For implementing secure forwarding of U2F messages.
+- `qubes-ctap`: For implementing secure forwarding of CTAP messages.
 - `qubes-pdf-converter`: For implementing safe conversion of PDFs.
 - `qubes-img-converter`: For implementing safe conversion of images.
 - `qubes-snapd-helper`: If you want to use snaps in qubes.

From 8b64b9d555bd43ae95b51c60050bfddaaa3f4eb3 Mon Sep 17 00:00:00 2001
From: Piotr Bartman <prbartman@invisiblethingslab.com>
Date: Sun, 21 May 2023 13:41:02 +0200
Subject: [PATCH 026/332] migration to fido2: redirect_from

---
 user/security-in-qubes/ctap-proxy.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/user/security-in-qubes/ctap-proxy.md b/user/security-in-qubes/ctap-proxy.md
index 6ba1f696..59e65f32 100644
--- a/user/security-in-qubes/ctap-proxy.md
+++ b/user/security-in-qubes/ctap-proxy.md
@@ -2,6 +2,7 @@
 lang: en
 layout: doc
 permalink: /doc/ctap-proxy/
+redirect_from: /doc/u2f-proxy/
 ref: 167
 title: CTAP proxy
 ---

From 3a3a39cd5ff44620f1c791e3bf09f8e78a43acaa Mon Sep 17 00:00:00 2001
From: Piotr Bartman <prbartman@invisiblethingslab.com>
Date: Mon, 29 May 2023 23:58:24 +0200
Subject: [PATCH 027/332] migration to fido2: backward compatible policies
 names

---
 user/security-in-qubes/ctap-proxy.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/security-in-qubes/ctap-proxy.md b/user/security-in-qubes/ctap-proxy.md
index 59e65f32..92e127dc 100644
--- a/user/security-in-qubes/ctap-proxy.md
+++ b/user/security-in-qubes/ctap-proxy.md
@@ -111,10 +111,10 @@ If your `twitter` qube makes an authentication request for your bank website, it
 To enable this, create a file in dom0 named `/etc/qubes/policy.d/30-user-ctapproxy.policy` with the following content:
 
 ```
-policy.RegisterArgument +ctap.GetAssertion sys-usb @anyvm allow target=dom0
+policy.RegisterArgument +u2f.Authenticate sys-usb @anyvm allow target=dom0
 ```
 
-Next, empty the contents of `/etc/qubes-rpc/policy/ctap.GetAssertion` so that it is a blank file.
+Next, empty the contents of `/etc/qubes-rpc/policy/u2f.Authenticate` so that it is a blank file.
 Do not delete the file itself.
 (If you do, the default file will be recreated the next time you update, so it will no longer be empty.) Finally, follow your web application's instructions to enroll your token and use it as usual.
 (This enrollment process depends on the web application and is in no way specific to Qubes CTAP.)

From f24299be1ebdd81a5acb6af66967104955ae885a Mon Sep 17 00:00:00 2001
From: Oni <git@oni.blue>
Date: Wed, 7 Jun 2023 05:59:45 -0400
Subject: [PATCH 028/332] Use 'qvm-template' to uninstall templates

The 'dnf remove' command no longer removes templates and mentions "No
Match" when using <package-name-spec>. The 'qvm-template' command will
remove templates from both package installation and
cloning. 'qvm-template' also warns about qubes dependent on the template
which reduces the need for the user to preemptively check that
relationship.

In its implementation, 'qvm-template' imports and calls 'qvm-remove'
to remove the template. 'qvm-template' was selected as the command to
present as it provides a more consistent interface when installing,
listing, and removing among other commands.
---
 user/templates/templates.md | 27 +++++++++------------------
 1 file changed, 9 insertions(+), 18 deletions(-)

diff --git a/user/templates/templates.md b/user/templates/templates.md
index f3740dec..30e40635 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -144,28 +144,19 @@ Please see [How to Install Software](/doc/how-to-install-software).
 
 ## Uninstalling
 
-If you want to remove a template you must make sure that it is not being used.
-You should check that the template is not being used by any qubes,
-and also that it is not set as the default template.
-
-The procedure for uninstalling a template depends on how it was created.
-
-If the template was originaly created by cloning another template, then you can
-delete it the same way as you would any other qube. In the Qube Manager,
-right-click on the template and select **Delete qube**. (If you're not sure,
-you can safely try this method first to see if it works.)
-
-If, on the other hand, the template came pre-installed or was installed by
-installing a template package in dom0, per the instructions
-[above](#installing), then you must execute the following type of command in
-dom0 in order to uninstall it:
+To remove a template, the graphical `Qube Manager` (Qubes Menu > Qubes Tools > Qube Manager) may be used. Right-click the template to be uninstalled and click "Delete qube" to begin removal.
 
+Alternatively, to remove a template via the command line in dom0:
 ```
-$ sudo dnf remove qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>
+$ qvm-template remove <TEMPLATE_NAME>
 ```
 
-`qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>` is the name of the desired
-template package.
+\<TEMPLATE_NAME> is the first column from the output of:
+```
+$ qvm-template list --installed
+```
+
+In either case, if another qube is based on the template, the template will remain installed and a list of the dependent qubes will be displayed. [Switch](#switching) the dependent qubes to another template before attempting the removal again.
 
 You may see warning messages like the following:
 

From e1abb55e638ce29bf8ae17f504a83b4ba024e101 Mon Sep 17 00:00:00 2001
From: Oni <git@oni.blue>
Date: Mon, 19 Jun 2023 06:26:18 -0400
Subject: [PATCH 029/332] Retire template removal warning messages

This section was added in response to:

https://github.com/QubesOS/qubes-issues/issues/6432

Seven months later, 'qvm-template' became the installation redirection
target:

https://github.com/QubesOS/qubes-core-admin-linux/pull/80

Now that 'dnf remove' is not being called directly, these warnings
should not be an issue.
---
 user/templates/templates.md | 26 --------------------------
 1 file changed, 26 deletions(-)

diff --git a/user/templates/templates.md b/user/templates/templates.md
index 30e40635..a15bfc16 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -158,32 +158,6 @@ $ qvm-template list --installed
 
 In either case, if another qube is based on the template, the template will remain installed and a list of the dependent qubes will be displayed. [Switch](#switching) the dependent qubes to another template before attempting the removal again.
 
-You may see warning messages like the following:
-
-```
-warning: file /var/lib/qubes/vm-templates/fedora-XX/whitelisted-appmenus.list: remove failed: No such file or directory
-warning: file /var/lib/qubes/vm-templates/fedora-XX/vm-whitelisted-appmenus.list: remove failed: No such file or directory
-warning: file /var/lib/qubes/vm-templates/fedora-XX/root.img.part.04: remove failed: No such file or directory
-warning: file /var/lib/qubes/vm-templates/fedora-XX/root.img.part.03: remove failed: No such file or directory
-warning: file /var/lib/qubes/vm-templates/fedora-XX/root.img.part.02: remove failed: No such file or directory
-warning: file /var/lib/qubes/vm-templates/fedora-XX/root.img.part.01: remove failed: No such file or directory
-warning: file /var/lib/qubes/vm-templates/fedora-XX/root.img.part.00: remove failed: No such file or directory
-warning: file /var/lib/qubes/vm-templates/fedora-XX/netvm-whitelisted-appmenus.list: remove failed: No such file or directory
-warning: file /var/lib/qubes/vm-templates/fedora-XX/icon.png: remove failed: No such file or directory
-warning: file /var/lib/qubes/vm-templates/fedora-XX/clean-volatile.img.tar: remove failed: No such file or directory
-warning: file /var/lib/qubes/vm-templates/fedora-XX/apps.templates: remove failed: No such file or directory
-warning: file /var/lib/qubes/vm-templates/fedora-XX/apps.tempicons: remove failed: No such file or directory
-warning: file /var/lib/qubes/vm-templates/fedora-XX/apps: remove failed: No such file or directory
-warning: file /var/lib/qubes/vm-templates/fedora-XX: remove failed: No such file or directory
-```
-
-These are normal and expected. Nothing is wrong, and no action is required to
-address these warnings.
-
-If the uninstallation command doesn't work, pay close attention to
-any error message: it may tell you what qube is using the template,
-or if the template is default. In other cases, please see [VM Troubleshooting](/doc/vm-troubleshooting/).
-
 If the Applications Menu entry doesn't go away after you uninstall a template,
 execute the following type of command in dom0:
 

From 781780f07e7bd24618bfef64e650f482fd914b16 Mon Sep 17 00:00:00 2001
From: Oni <git@oni.blue>
Date: Mon, 19 Jun 2023 06:59:06 -0400
Subject: [PATCH 030/332] Redirect Qubes Menu issues with template
 uninstallation

Manually removing Qubes Menu entries is covered on the linked page.
---
 user/templates/templates.md | 14 +-------------
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/user/templates/templates.md b/user/templates/templates.md
index a15bfc16..7bd6a9a3 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -158,19 +158,7 @@ $ qvm-template list --installed
 
 In either case, if another qube is based on the template, the template will remain installed and a list of the dependent qubes will be displayed. [Switch](#switching) the dependent qubes to another template before attempting the removal again.
 
-If the Applications Menu entry doesn't go away after you uninstall a template,
-execute the following type of command in dom0:
-
-```
-$ rm ~/.local/share/applications/<TEMPLATE_NAME>
-```
-
-Applications Menu entries for backups of removed qubes can also be found in
-`/usr/local/share/applications/` of dom0.
-
-```
-$ rm /usr/local/share/applications/<TEMPLATE_NAME>
-```
+If the template's entry in the Qubes Menu is not removed with its uninstallation, consult the [troubleshooting page](/doc/app-menu-shortcut-troubleshooting/#fixing-shortcuts).
 
 ## Reinstalling
 

From 1e7a9f7437f6428e9fba97be3dea67de172a80b3 Mon Sep 17 00:00:00 2001
From: Oni <git@oni.blue>
Date: Mon, 19 Jun 2023 08:42:59 -0400
Subject: [PATCH 031/332] Address two potential issues raised when removing a
 template

Mentioned the final confirmation step asked for by the `Qube Manager`
to type the template's name. However, before this final confirmation
is displayed, issues may be raised. Deleting templates may run afoul
of dependent qubes and the "default_template" global
property. Instructions to resolve via switching are linked.
---
 user/templates/templates.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/templates/templates.md b/user/templates/templates.md
index 7bd6a9a3..651c7a88 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -144,7 +144,7 @@ Please see [How to Install Software](/doc/how-to-install-software).
 
 ## Uninstalling
 
-To remove a template, the graphical `Qube Manager` (Qubes Menu > Qubes Tools > Qube Manager) may be used. Right-click the template to be uninstalled and click "Delete qube" to begin removal.
+To remove a template, the graphical `Qube Manager` (Qubes Menu > Qubes Tools > Qube Manager) may be used. Right-click the template to be uninstalled and click "Delete qube" to begin removal. If no issues are found, a dialog box will request the template's name be typed as a final confirmation. Upon completion, the template will be deleted.
 
 Alternatively, to remove a template via the command line in dom0:
 ```
@@ -156,7 +156,7 @@ $ qvm-template remove <TEMPLATE_NAME>
 $ qvm-template list --installed
 ```
 
-In either case, if another qube is based on the template, the template will remain installed and a list of the dependent qubes will be displayed. [Switch](#switching) the dependent qubes to another template before attempting the removal again.
+In either case, issues with template removal may be raised. If an issue is raised, the template will remain installed and a list of concerns displayed. "Global property default_template" requires [switching](#switching) the default_template property to another template. "Template for" can be resolved by [switching](#switching) the dependent qubes' template. Once the issues are addressed, attempt the removal again.
 
 If the template's entry in the Qubes Menu is not removed with its uninstallation, consult the [troubleshooting page](/doc/app-menu-shortcut-troubleshooting/#fixing-shortcuts).
 

From 6e15603483b02bef6ae8f76fca78be3bc93b353e Mon Sep 17 00:00:00 2001
From: Rusty Bird <rustybird@net-c.com>
Date: Tue, 20 Jun 2023 13:52:30 +0000
Subject: [PATCH 032/332] Clarify reading the passphrase

https://forum.qubes-os.org/t/getting-stuck-on-emergency-backup-recovery/18520/5
https://forum.qubes-os.org/t/getting-stuck-on-emergency-backup-recovery/18520/6
---
 user/how-to-guides/backup-emergency-restore-v4.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/user/how-to-guides/backup-emergency-restore-v4.md b/user/how-to-guides/backup-emergency-restore-v4.md
index 92b4866c..8688f5b0 100644
--- a/user/how-to-guides/backup-emergency-restore-v4.md
+++ b/user/how-to-guides/backup-emergency-restore-v4.md
@@ -91,6 +91,8 @@ any GNU/Linux system.
 
         [user@restore ~]$ read -r backup_pass
 
+    Type in your passphrase (it will be visible on screen!) and press Enter.
+
  3. Verify the integrity of `backup-header` using `backup-header.hmac` (an
     encrypted *and integrity protected* version of `backup-header`).
 

From 0aee55a8dd6b29a0a55006532c046b56e04c5416 Mon Sep 17 00:00:00 2001
From: Rusty Bird <rustybird@net-c.com>
Date: Tue, 20 Jun 2023 13:52:31 +0000
Subject: [PATCH 033/332] Use ls instead of cat to show example data

https://forum.qubes-os.org/t/getting-stuck-on-emergency-backup-recovery/18520/5
---
 user/how-to-guides/backup-emergency-restore-v4.md | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/user/how-to-guides/backup-emergency-restore-v4.md b/user/how-to-guides/backup-emergency-restore-v4.md
index 8688f5b0..d4baa698 100644
--- a/user/how-to-guides/backup-emergency-restore-v4.md
+++ b/user/how-to-guides/backup-emergency-restore-v4.md
@@ -194,8 +194,9 @@ any GNU/Linux system.
 
         [user@restore ~]$ sudo mkdir /mnt/img
         [user@restore ~]$ sudo mount -o loop vm123/private.img /mnt/img/
-        [user@restore ~]$ cat /mnt/img/home/user/your_data.txt
-        This data has been successfully recovered!
+        [user@restore ~]$ ls /mnt/img/home/user/
+        example_data_file.txt
+        ...
 
 Success! If you wish to recover data from more than one qube in your backup,
 simply repeat steps 7, 8, and 9 for each additional qube.

From bd763623ca0702cd1bb360b1e5c830be195d3536 Mon Sep 17 00:00:00 2001
From: taradiddles <taradiddles@users.noreply.github.com>
Date: Tue, 15 Aug 2023 09:34:37 +0300
Subject: [PATCH 034/332] Update qubes-community links to point to the forum

---
 developer/general/documentation-style-guide.md     |  2 +-
 .../building-guides/building-archlinux-template.md |  2 +-
 .../building-non-fedora-template.md                |  2 +-
 .../building-guides/building-whonix-template.md    |  2 +-
 external/configuration-guides/change-time-zone.md  |  2 +-
 external/configuration-guides/disk-trim.md         |  2 +-
 external/configuration-guides/external-audio.md    |  2 +-
 external/configuration-guides/fetchmail.md         |  2 +-
 .../configuration-guides/install-nvidia-driver.md  |  2 +-
 external/configuration-guides/multiboot.md         |  2 +-
 external/configuration-guides/multimedia.md        |  2 +-
 external/configuration-guides/mutt.md              |  2 +-
 .../configuration-guides/network-bridge-support.md |  2 +-
 external/configuration-guides/network-printer.md   |  2 +-
 external/configuration-guides/postfix.md           |  2 +-
 external/configuration-guides/rxvt.md              |  2 +-
 external/configuration-guides/tips-and-tricks.md   |  9 ---------
 external/configuration-guides/vpn.md               |  2 +-
 external/configuration-guides/w3m.md               |  2 +-
 external/configuration-guides/zfs.md               |  2 +-
 external/customization-guides/dark-theme.md        |  2 +-
 .../fedora-minimal-template-customization.md       |  2 +-
 .../customization-guides/language-localization.md  |  2 +-
 .../removing-templatevm-packages.md                |  2 +-
 .../windows-template-customization.md              |  2 +-
 external/os-guides/centos.md                       |  2 +-
 external/os-guides/gentoo.md                       |  2 +-
 external/os-guides/linux-hvm-tips.md               |  2 +-
 external/os-guides/netbsd.md                       |  2 +-
 external/os-guides/pentesting.md                   |  9 ---------
 external/os-guides/pentesting/blackarch.md         |  2 +-
 external/os-guides/pentesting/kali.md              |  2 +-
 external/os-guides/pentesting/ptf.md               |  2 +-
 external/os-guides/ubuntu.md                       |  2 +-
 .../privacy-guides/anonymizing-your-mac-address.md |  2 +-
 external/privacy-guides/signal.md                  |  2 +-
 external/privacy-guides/tails.md                   |  2 +-
 external/privacy-guides/torvm.md                   |  2 +-
 external/privacy-guides/whonix.md                  |  2 +-
 .../security-guides/multifactor-authentication.md  |  2 +-
 external/security-guides/security-guidelines.md    |  2 +-
 external/security-guides/split-bitcoin.md          |  2 +-
 .../troubleshooting/application-troubleshooting.md |  2 +-
 .../troubleshooting/intel-igfx-troubleshooting.md  |  2 +-
 .../troubleshooting/macbook-troubleshooting.md     |  2 +-
 external/troubleshooting/nvidia-troubleshooting.md |  2 +-
 external/troubleshooting/sony-vaio-tinkering.md    |  2 +-
 external/troubleshooting/tails-troubleshooting.md  |  2 +-
 .../troubleshooting/thinkpad-troubleshooting.md    |  2 +-
 introduction/faq.md                                |  4 ++--
 user/advanced-topics/standalones-and-hvms.md       |  2 +-
 user/how-to-guides/how-to-organize-your-qubes.md   |  8 ++++----
 user/how-to-guides/how-to-use-optical-discs.md     |  2 +-
 user/security-in-qubes/anti-evil-maid.md           |  4 ++--
 user/security-in-qubes/firewall.md                 |  2 +-
 user/templates/minimal-templates.md                | 14 +++++++-------
 .../installation-troubleshooting.md                |  4 ++--
 user/troubleshooting/pci-troubleshooting.md        |  2 +-
 user/troubleshooting/uefi-troubleshooting.md       |  2 +-
 59 files changed, 69 insertions(+), 87 deletions(-)
 delete mode 100644 external/configuration-guides/tips-and-tricks.md
 delete mode 100644 external/os-guides/pentesting.md

diff --git a/developer/general/documentation-style-guide.md b/developer/general/documentation-style-guide.md
index 84881663..4b4334e8 100644
--- a/developer/general/documentation-style-guide.md
+++ b/developer/general/documentation-style-guide.md
@@ -262,7 +262,7 @@ Duplicating documentation is almost always a bad idea. There are many reasons fo
 
 ### Core vs. external documentation
 
-Core documentation resides in the [Qubes OS Project's official repositories](https://github.com/QubesOS/), mainly in [qubes-doc](https://github.com/QubesOS/qubes-doc). External documentation can be anywhere else (such as forums, community websites, and blogs), but there is an especially large collection in the [Qubes Community](https://github.com/Qubes-Community) project. External documentation should not be submitted to [qubes-doc](https://github.com/QubesOS/qubes-doc). If you've written a piece of documentation that is not appropriate for [qubes-doc](https://github.com/QubesOS/qubes-doc), we encourage you to submit it to the [Qubes Community](https://github.com/Qubes-Community) project instead. However, *linking* to external documentation from [qubes-doc](https://github.com/QubesOS/qubes-doc) is perfectly fine. Indeed, the maintainers of the [Qubes Community](https://github.com/Qubes-Community) project should regularly submit PRs against the documentation index (see [How to edit the documentation index](/doc/how-to-edit-the-documentation/#how-to-edit-the-documentation-index)) to add and update Qubes Community links in the ["External documentation"](/doc/#external-documentation) section of the documentation table of contents.
+Core documentation resides in the [Qubes OS Project's official repositories](https://github.com/QubesOS/), mainly in [qubes-doc](https://github.com/QubesOS/qubes-doc). External documentation can be anywhere else (such as forums, community websites, and blogs), but there is an especially large collection in the [Qubes Forum](https://forum.qubes-os.org/docs). External documentation should not be submitted to [qubes-doc](https://github.com/QubesOS/qubes-doc). If you've written a piece of documentation that is not appropriate for [qubes-doc](https://github.com/QubesOS/qubes-doc), we encourage you to submit it to the [Qubes Forum](https://forum.qubes-os.org/docs) instead. However, *linking* to external documentation from [qubes-doc](https://github.com/QubesOS/qubes-doc) is perfectly fine. Indeed, the maintainers of the [Qubes Forum](https://forum.qubes-os.org/) should regularly submit PRs against the documentation index (see [How to edit the documentation index](/doc/how-to-edit-the-documentation/#how-to-edit-the-documentation-index)) to add and update Qubes Community links in the ["External documentation"](/doc/#external-documentation) section of the documentation table of contents.
 
 The main difference between **core** (or **official**) and **external** (or **community** or **unofficial**) documentation is whether it documents software that is officially written and maintained by the Qubes OS Project. The purpose of this distinction is to keep the core docs maintainable and high-quality by limiting them to the software output by the Qubes OS Project. In other words, we take responsibility for documenting all of the software we put out into the world, but it doesn't make sense for us to take on the responsibility of documenting or maintaining documentation for anything else. For example, Qubes OS may use a popular Linux distribution for an official [TemplateVM](/doc/templates/). However, it would not make sense for a comparatively small project like ours, with modest funding and a lean workforce, to attempt to document software belonging to a large, richly-funded project with an army of paid and volunteer contributors, especially when they probably already have documentation of their own. This is particularly true when it comes to Linux in general. Although many users who are new to Qubes are also new to Linux, it makes absolutely no sense for our comparatively tiny project to try to document Linux in general when there is already a plethora of documentation out there.
 
diff --git a/external/building-guides/building-archlinux-template.md b/external/building-guides/building-archlinux-template.md
index d6bce239..9894d001 100644
--- a/external/building-guides/building-archlinux-template.md
+++ b/external/building-guides/building-archlinux-template.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/building-archlinux-template/
 - /doc/BuildingArchlinuxTemplate/
 - /wiki/BuildingArchlinuxTemplate/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/building/building-archlinux-template.md
+redirect_to: https://forum.qubes-os.org/t/19052
 ref: 116
 title: Building Arch Linux template
 ---
diff --git a/external/building-guides/building-non-fedora-template.md b/external/building-guides/building-non-fedora-template.md
index 9bc8490e..a07b726f 100644
--- a/external/building-guides/building-non-fedora-template.md
+++ b/external/building-guides/building-non-fedora-template.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/building-non-fedora-template/
 - /doc/BuildingNonFedoraTemplate/
 - /wiki/BuildingNonFedoraTemplate/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/building/building-non-fedora-template.md
+redirect_to: https://forum.qubes-os.org/t/18972
 ref: 117
 title: Building non-Fedora template
 ---
diff --git a/external/building-guides/building-whonix-template.md b/external/building-guides/building-whonix-template.md
index 23e29760..a0bbb0e7 100644
--- a/external/building-guides/building-whonix-template.md
+++ b/external/building-guides/building-whonix-template.md
@@ -4,7 +4,7 @@ layout: doc
 redirect_from:
 - /doc/building-whonix-template/
 - /en/doc/building-whonix-template/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/building/building-whonix-template.md
+redirect_to: https://forum.qubes-os.org/t/18981
 ref: 115
 title: Building Whonix templates
 ---
diff --git a/external/configuration-guides/change-time-zone.md b/external/configuration-guides/change-time-zone.md
index a7666f47..e0cc6bb4 100644
--- a/external/configuration-guides/change-time-zone.md
+++ b/external/configuration-guides/change-time-zone.md
@@ -3,7 +3,7 @@ lang: en
 layout: doc
 redirect_from:
 - /doc/change-time-zone/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/change-time-zone.md
+redirect_to: https://forum.qubes-os.org/t/18983
 ref: 109
 title: Changing your time zone
 ---
diff --git a/external/configuration-guides/disk-trim.md b/external/configuration-guides/disk-trim.md
index 60bc1aa7..c8102a07 100644
--- a/external/configuration-guides/disk-trim.md
+++ b/external/configuration-guides/disk-trim.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/disk-trim/
 - /doc/DiskTRIM/
 - /wiki/DiskTRIM/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/disk-trim.md
+redirect_to: https://forum.qubes-os.org/t/19054
 ref: 104
 title: Disk TRIM
 ---
diff --git a/external/configuration-guides/external-audio.md b/external/configuration-guides/external-audio.md
index 4fe19b8b..64392b87 100644
--- a/external/configuration-guides/external-audio.md
+++ b/external/configuration-guides/external-audio.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/external-audio/
 - /doc/ExternalAudio/
 - /wiki/ExternalAudio/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/external-audio.md
+redirect_to: https://forum.qubes-os.org/t/18984
 ref: 100
 title: External audio
 ---
diff --git a/external/configuration-guides/fetchmail.md b/external/configuration-guides/fetchmail.md
index 84d9e772..4f13adcc 100644
--- a/external/configuration-guides/fetchmail.md
+++ b/external/configuration-guides/fetchmail.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/fetchmail/
 - /doc/Fetchmail/
 - /wiki/Fetchmail/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/fetchmail.md
+redirect_to: https://forum.qubes-os.org/t/18985
 ref: 114
 title: Fetchmail
 ---
diff --git a/external/configuration-guides/install-nvidia-driver.md b/external/configuration-guides/install-nvidia-driver.md
index 8c997052..d1b1e967 100644
--- a/external/configuration-guides/install-nvidia-driver.md
+++ b/external/configuration-guides/install-nvidia-driver.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/install-nvidia-driver/
 - /doc/InstallNvidiaDriver/
 - /wiki/InstallNvidiaDriver/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/install-nvidia-driver.md
+redirect_to: https://forum.qubes-os.org/t/18987
 ref: 96
 title: How to install an Nvidia driver
 ---
diff --git a/external/configuration-guides/multiboot.md b/external/configuration-guides/multiboot.md
index 2d7e1841..92aec5bf 100644
--- a/external/configuration-guides/multiboot.md
+++ b/external/configuration-guides/multiboot.md
@@ -1,7 +1,7 @@
 ---
 lang: en
 layout: doc
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/multiboot.md
+redirect_to: https://forum.qubes-os.org/t/18988
 ref: 112
 title: Multibooting
 ---
diff --git a/external/configuration-guides/multimedia.md b/external/configuration-guides/multimedia.md
index 24369540..5941f17b 100644
--- a/external/configuration-guides/multimedia.md
+++ b/external/configuration-guides/multimedia.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/multimedia/
 - /doc/Multimedia/
 - /wiki/Multimedia/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/multimedia.md
+redirect_to: https://forum.qubes-os.org/t/19055
 ref: 105
 title: How to make a multimedia template
 ---
diff --git a/external/configuration-guides/mutt.md b/external/configuration-guides/mutt.md
index 6ba929df..1b057c17 100644
--- a/external/configuration-guides/mutt.md
+++ b/external/configuration-guides/mutt.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/mutt/
 - /doc/Mutt/
 - /wiki/Mutt/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/mutt.md
+redirect_to: https://forum.qubes-os.org/t/18989
 ref: 106
 title: Mutt
 ---
diff --git a/external/configuration-guides/network-bridge-support.md b/external/configuration-guides/network-bridge-support.md
index 5a460a6e..ea84f401 100644
--- a/external/configuration-guides/network-bridge-support.md
+++ b/external/configuration-guides/network-bridge-support.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/network-bridge-support/
 - /doc/NetworkBridgeSupport/
 - /wiki/NetworkBridgeSupport/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/network-bridge-support.md
+redirect_to: https://forum.qubes-os.org/t/18990
 ref: 113
 title: Network bridge support
 ---
diff --git a/external/configuration-guides/network-printer.md b/external/configuration-guides/network-printer.md
index b29ae5ed..848ab9f1 100644
--- a/external/configuration-guides/network-printer.md
+++ b/external/configuration-guides/network-printer.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/network-printer/
 - /doc/NetworkPrinter/
 - /wiki/NetworkPrinter/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/network-printer.md
+redirect_to: https://forum.qubes-os.org/t/19056
 ref: 108
 title: Network printer
 ---
diff --git a/external/configuration-guides/postfix.md b/external/configuration-guides/postfix.md
index 1ee8be06..03b2c7e3 100644
--- a/external/configuration-guides/postfix.md
+++ b/external/configuration-guides/postfix.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/postfix/
 - /doc/Postfix/
 - /wiki/Postfix/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/postfix.md
+redirect_to: https://forum.qubes-os.org/t/18991
 ref: 107
 title: Postfix
 ---
diff --git a/external/configuration-guides/rxvt.md b/external/configuration-guides/rxvt.md
index 9c47538b..b34dd736 100644
--- a/external/configuration-guides/rxvt.md
+++ b/external/configuration-guides/rxvt.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/rxvt/
 - /doc/Rxvt/
 - /wiki/Rxvt/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/rxvt.md
+redirect_to: https://forum.qubes-os.org/t/18992
 ref: 103
 title: Rxvt
 ---
diff --git a/external/configuration-guides/tips-and-tricks.md b/external/configuration-guides/tips-and-tricks.md
deleted file mode 100644
index 099e51ab..00000000
--- a/external/configuration-guides/tips-and-tricks.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-lang: en
-layout: doc
-redirect_from:
-- /doc/tips-and-tricks/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/tips-and-tricks.md
-ref: 110
-title: Tips and tricks
----
diff --git a/external/configuration-guides/vpn.md b/external/configuration-guides/vpn.md
index 5431af63..f0cd50d8 100644
--- a/external/configuration-guides/vpn.md
+++ b/external/configuration-guides/vpn.md
@@ -7,7 +7,7 @@ redirect_from:
 - /en/doc/vpn/
 - /doc/VPN/
 - /wiki/VPN/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md
+redirect_to: https://forum.qubes-os.org/t/19061
 ref: 102
 title: VPN
 ---
diff --git a/external/configuration-guides/w3m.md b/external/configuration-guides/w3m.md
index 50f3642c..c2b701eb 100644
--- a/external/configuration-guides/w3m.md
+++ b/external/configuration-guides/w3m.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/mutt/
 - /doc/W3m/
 - /wiki/W3m/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/w3m.md
+redirect_to: https://forum.qubes-os.org/t/18993
 ref: 101
 title: Reducing the fingerprint of the text-based web browser w3m
 ---
diff --git a/external/configuration-guides/zfs.md b/external/configuration-guides/zfs.md
index 55fb87b2..4d2bf1cd 100644
--- a/external/configuration-guides/zfs.md
+++ b/external/configuration-guides/zfs.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/zfs/
 - /doc/ZFS/
 - /wiki/ZFS/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/zfs.md
+redirect_to: https://forum.qubes-os.org/t/18994
 ref: 111
 title: ZFS
 ---
diff --git a/external/customization-guides/dark-theme.md b/external/customization-guides/dark-theme.md
index 2494fca9..364f926f 100644
--- a/external/customization-guides/dark-theme.md
+++ b/external/customization-guides/dark-theme.md
@@ -3,7 +3,7 @@ lang: en
 layout: doc
 redirect_from:
 - /doc/dark-theme/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/customization/dark-theme.md
+redirect_to: https://forum.qubes-os.org/t/18997
 ref: 74
 title: Dark theme
 ---
diff --git a/external/customization-guides/fedora-minimal-template-customization.md b/external/customization-guides/fedora-minimal-template-customization.md
index d9773499..fbb2dc1c 100644
--- a/external/customization-guides/fedora-minimal-template-customization.md
+++ b/external/customization-guides/fedora-minimal-template-customization.md
@@ -3,7 +3,7 @@ lang: en
 layout: doc
 redirect_from:
 - /en/doc/fedora-minimal-template-customization/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/customization/fedora-minimal-template-customization.md
+redirect_to: https://forum.qubes-os.org/t/18999
 ref: 76
 title: Fedora minimal template customization
 ---
diff --git a/external/customization-guides/language-localization.md b/external/customization-guides/language-localization.md
index 61015d39..00d729c3 100644
--- a/external/customization-guides/language-localization.md
+++ b/external/customization-guides/language-localization.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/language-localization/
 - /doc/LanguageLocalization/
 - /wiki/LanguageLocalization/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/customization/language-localization.md
+redirect_to: https://forum.qubes-os.org/t/19001
 ref: 73
 title: Language localization
 ---
diff --git a/external/customization-guides/removing-templatevm-packages.md b/external/customization-guides/removing-templatevm-packages.md
index 23efe5a7..7c12637c 100644
--- a/external/customization-guides/removing-templatevm-packages.md
+++ b/external/customization-guides/removing-templatevm-packages.md
@@ -3,7 +3,7 @@ lang: en
 layout: doc
 redirect_from:
 - /doc/removing-templatevm-packages/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/customization/removing-templatevm-packages.md
+redirect_to: https://forum.qubes-os.org/t/19002
 ref: 75
 title: Removing template packages
 ---
diff --git a/external/customization-guides/windows-template-customization.md b/external/customization-guides/windows-template-customization.md
index ac368c23..48e0a345 100644
--- a/external/customization-guides/windows-template-customization.md
+++ b/external/customization-guides/windows-template-customization.md
@@ -3,7 +3,7 @@ lang: en
 layout: doc
 redirect_from:
 - /doc/windows-template-customization/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/customization/windows-template-customization.md
+redirect_to: https://forum.qubes-os.org/t/19005
 ref: 72
 title: Windows template customization
 ---
diff --git a/external/os-guides/centos.md b/external/os-guides/centos.md
index 68c43e11..149dac25 100644
--- a/external/os-guides/centos.md
+++ b/external/os-guides/centos.md
@@ -3,7 +3,7 @@ lang: en
 layout: doc
 redirect_from:
 - /doc/templates/centos/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/os/centos.md
+redirect_to: https://forum.qubes-os.org/t/19006
 ref: 81
 title: CentOS template
 ---
diff --git a/external/os-guides/gentoo.md b/external/os-guides/gentoo.md
index ac9f89c2..1b2b9607 100644
--- a/external/os-guides/gentoo.md
+++ b/external/os-guides/gentoo.md
@@ -3,7 +3,7 @@ lang: en
 layout: doc
 redirect_from:
 - /doc/templates/gentoo/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/os/gentoo.md
+redirect_to: https://forum.qubes-os.org/t/19007
 ref: 221
 title: Gentoo template
 ---
diff --git a/external/os-guides/linux-hvm-tips.md b/external/os-guides/linux-hvm-tips.md
index 7b1c0e3d..33c45dd1 100644
--- a/external/os-guides/linux-hvm-tips.md
+++ b/external/os-guides/linux-hvm-tips.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/linux-hvm-tips/
 - /doc/LinuxHVMTips/
 - /wiki/LinuxHVMTips/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/os/linux-hvm-tips.md
+redirect_to: https://forum.qubes-os.org/t/19008
 ref: 82
 title: Linux HVM tips
 ---
diff --git a/external/os-guides/netbsd.md b/external/os-guides/netbsd.md
index 9e37cc5f..2d825bb7 100644
--- a/external/os-guides/netbsd.md
+++ b/external/os-guides/netbsd.md
@@ -3,7 +3,7 @@ lang: en
 layout: doc
 redirect_from:
 - /doc/netbsd/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/os/netbsd.md
+redirect_to: https://forum.qubes-os.org/t/19009
 ref: 84
 title: How to create a NetBSD qube
 ---
diff --git a/external/os-guides/pentesting.md b/external/os-guides/pentesting.md
deleted file mode 100644
index 8828e5d8..00000000
--- a/external/os-guides/pentesting.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-lang: en
-layout: doc
-redirect_from:
-- /doc/pentesting/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/os/pentesting.md
-ref: 83
-title: Penetration testing
----
diff --git a/external/os-guides/pentesting/blackarch.md b/external/os-guides/pentesting/blackarch.md
index a353c37b..d23081e1 100644
--- a/external/os-guides/pentesting/blackarch.md
+++ b/external/os-guides/pentesting/blackarch.md
@@ -4,7 +4,7 @@ layout: doc
 redirect_from:
 - /doc/pentesting/blackarch/
 - /doc/blackarch/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/os/pentesting/blackarch.md
+redirect_to: https://forum.qubes-os.org/t/19010
 ref: 88
 title: How to create a BlackArch qube
 ---
diff --git a/external/os-guides/pentesting/kali.md b/external/os-guides/pentesting/kali.md
index 817b5aba..9bd1f6b4 100644
--- a/external/os-guides/pentesting/kali.md
+++ b/external/os-guides/pentesting/kali.md
@@ -4,7 +4,7 @@ layout: doc
 redirect_from:
 - /doc/pentesting/kali/
 - /doc/kali/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/os/pentesting/kali.md
+redirect_to: https://forum.qubes-os.org/t/19071
 ref: 87
 title: How to create a Kali Linux qube
 ---
diff --git a/external/os-guides/pentesting/ptf.md b/external/os-guides/pentesting/ptf.md
index 440b660b..b8639f32 100644
--- a/external/os-guides/pentesting/ptf.md
+++ b/external/os-guides/pentesting/ptf.md
@@ -4,7 +4,7 @@ layout: doc
 redirect_from:
 - /doc/pentesting/ptf/
 - /doc/ptf/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/os/pentesting/ptf.md
+redirect_to: https://forum.qubes-os.org/t/19011
 ref: 89
 title: How to create penetration testers framework (PTF) qube
 ---
diff --git a/external/os-guides/ubuntu.md b/external/os-guides/ubuntu.md
index 3a877c8f..6a98b073 100644
--- a/external/os-guides/ubuntu.md
+++ b/external/os-guides/ubuntu.md
@@ -7,7 +7,7 @@ redirect_from:
 - /en/doc/templates/ubuntu/
 - /doc/Templates/Ubuntu/
 - /wiki/Templates/Ubuntu/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/os/ubuntu.md
+redirect_to: https://qubes.3isec.org
 ref: 80
 title: Ubuntu template
 ---
diff --git a/external/privacy-guides/anonymizing-your-mac-address.md b/external/privacy-guides/anonymizing-your-mac-address.md
index b7ff2f67..99518ef1 100644
--- a/external/privacy-guides/anonymizing-your-mac-address.md
+++ b/external/privacy-guides/anonymizing-your-mac-address.md
@@ -4,7 +4,7 @@ layout: doc
 redirect_from:
 - /doc/anonymizing-your-mac-address/
 - /doc/randomizing-your-mac-address/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/privacy/anonymizing-your-mac-address.md
+redirect_to: https://forum.qubes-os.org/t/19072
 ref: 67
 title: Anonymizing your MAC address
 ---
diff --git a/external/privacy-guides/signal.md b/external/privacy-guides/signal.md
index 9999a1f1..2341d865 100644
--- a/external/privacy-guides/signal.md
+++ b/external/privacy-guides/signal.md
@@ -3,7 +3,7 @@ lang: en
 layout: doc
 redirect_from:
 - /doc/signal/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/privacy/signal.md
+redirect_to: https://forum.qubes-os.org/t/19073
 ref: 70
 title: Signal
 ---
diff --git a/external/privacy-guides/tails.md b/external/privacy-guides/tails.md
index 6de580b5..ffc55e54 100644
--- a/external/privacy-guides/tails.md
+++ b/external/privacy-guides/tails.md
@@ -4,7 +4,7 @@ layout: doc
 redirect_from:
 - /doc/tails/
 - /doc/running-tails/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/privacy/tails.md
+redirect_to: https://forum.qubes-os.org/t/19012
 ref: 71
 title: Running Tails in qubes
 ---
diff --git a/external/privacy-guides/torvm.md b/external/privacy-guides/torvm.md
index b5177ff3..8010e81d 100644
--- a/external/privacy-guides/torvm.md
+++ b/external/privacy-guides/torvm.md
@@ -8,7 +8,7 @@ redirect_from:
 - /doc/TorVM/
 - /doc/UserDoc/TorVM/
 - /wiki/UserDoc/TorVM/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/privacy/torvm.md
+redirect_to: https://forum.qubes-os.org/t/19013
 ref: 68
 title: TorVM
 ---
diff --git a/external/privacy-guides/whonix.md b/external/privacy-guides/whonix.md
index 8f8c7abb..580b2a87 100644
--- a/external/privacy-guides/whonix.md
+++ b/external/privacy-guides/whonix.md
@@ -16,7 +16,7 @@ redirect_from:
 - /doc/privacy/uninstall-whonix/
 - /doc/whonix/update/
 - /doc/privacy/updating-whonix/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/privacy/whonix.md
+redirect_to: https://forum.qubes-os.org/t/19014
 ref: 69
 title: Whonix for privacy & anonymity
 ---
diff --git a/external/security-guides/multifactor-authentication.md b/external/security-guides/multifactor-authentication.md
index 7912b8ed..4d0e8c4f 100644
--- a/external/security-guides/multifactor-authentication.md
+++ b/external/security-guides/multifactor-authentication.md
@@ -5,7 +5,7 @@ redirect_from:
 - /doc/multifactor-authentication/
 - /en/doc/multifactor-authentication/
 - /doc/Multi-factorAuthentication/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/security/multifactor-authentication.md
+redirect_to: https://forum.qubes-os.org/t/19016
 ref: 78
 title: Multifactor authentication
 ---
diff --git a/external/security-guides/security-guidelines.md b/external/security-guides/security-guidelines.md
index eb4d4542..36af472a 100644
--- a/external/security-guides/security-guidelines.md
+++ b/external/security-guides/security-guidelines.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/security-guidelines/
 - /doc/SecurityGuidelines/
 - /wiki/SecurityGuidelines/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/security/security-guidelines.md
+redirect_to: https://forum.qubes-os.org/t/19075
 ref: 79
 title: Security guidelines
 ---
diff --git a/external/security-guides/split-bitcoin.md b/external/security-guides/split-bitcoin.md
index a192a5e6..8ffc3258 100644
--- a/external/security-guides/split-bitcoin.md
+++ b/external/security-guides/split-bitcoin.md
@@ -3,7 +3,7 @@ lang: en
 layout: doc
 redirect_from:
 - /doc/split-bitcoin/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/security/split-bitcoin.md
+redirect_to: https://forum.qubes-os.org/t/19017
 ref: 77
 title: Split Bitcoin
 ---
diff --git a/external/troubleshooting/application-troubleshooting.md b/external/troubleshooting/application-troubleshooting.md
index 5c5efb04..b10ddc7f 100644
--- a/external/troubleshooting/application-troubleshooting.md
+++ b/external/troubleshooting/application-troubleshooting.md
@@ -3,7 +3,7 @@ lang: en
 layout: doc
 redirect_from:
 - /doc/application-troubleshooting/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/troubleshooting/application-troubleshooting.md
+redirect_to: https://forum.qubes-os.org/t/19019
 ref: 236
 title: Application troubleshooting
 ---
diff --git a/external/troubleshooting/intel-igfx-troubleshooting.md b/external/troubleshooting/intel-igfx-troubleshooting.md
index f616fbda..f733031b 100644
--- a/external/troubleshooting/intel-igfx-troubleshooting.md
+++ b/external/troubleshooting/intel-igfx-troubleshooting.md
@@ -3,7 +3,7 @@ lang: en
 layout: doc
 redirect_from:
 - /doc/intel-igfx-troubleshooting/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/troubleshooting/intel-igfx-troubleshooting.md
+redirect_to: https://forum.qubes-os.org/t/19081
 ref: 90
 title: Intel integrated graphics troubleshooting
 ---
diff --git a/external/troubleshooting/macbook-troubleshooting.md b/external/troubleshooting/macbook-troubleshooting.md
index 955e21ad..face9f66 100644
--- a/external/troubleshooting/macbook-troubleshooting.md
+++ b/external/troubleshooting/macbook-troubleshooting.md
@@ -1,7 +1,7 @@
 ---
 lang: en
 layout: doc
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/troubleshooting/macbook-troubleshooting.md
+redirect_to: https://forum.qubes-os.org/t/19020
 ref: 238
 title: Apple MacBook troubleshooting
 ---
diff --git a/external/troubleshooting/nvidia-troubleshooting.md b/external/troubleshooting/nvidia-troubleshooting.md
index f9d686f9..a628141b 100644
--- a/external/troubleshooting/nvidia-troubleshooting.md
+++ b/external/troubleshooting/nvidia-troubleshooting.md
@@ -4,7 +4,7 @@ layout: doc
 redirect_from:
 - /doc/NvidiaTroubleshooting/
 - /wiki/NvidiaTroubleshooting/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/troubleshooting/nvidia-troubleshooting.md
+redirect_to: https://forum.qubes-os.org/t/19021
 ref: 91
 title: Nvidia troubleshooting
 ---
diff --git a/external/troubleshooting/sony-vaio-tinkering.md b/external/troubleshooting/sony-vaio-tinkering.md
index 19fe54c4..7191850b 100644
--- a/external/troubleshooting/sony-vaio-tinkering.md
+++ b/external/troubleshooting/sony-vaio-tinkering.md
@@ -6,7 +6,7 @@ redirect_from:
 - /en/doc/sony-vaio-tinkering/
 - /doc/SonyVaioTinkering/
 - /wiki/SonyVaioTinkering/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/troubleshooting/sony-vaio-tinkering.md
+redirect_to: https://forum.qubes-os.org/t/19022
 ref: 93
 title: Sony Vaio tinkering
 ---
diff --git a/external/troubleshooting/tails-troubleshooting.md b/external/troubleshooting/tails-troubleshooting.md
index 6b815f49..1d933244 100644
--- a/external/troubleshooting/tails-troubleshooting.md
+++ b/external/troubleshooting/tails-troubleshooting.md
@@ -3,7 +3,7 @@ lang: en
 layout: doc
 redirect_from:
 - /doc/tails-troubleshooting/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/troubleshooting/tails-troubleshooting.md
+redirect_to: https://forum.qubes-os.org/t/19023
 ref: 237
 title: Tails troubleshooting
 ---
diff --git a/external/troubleshooting/thinkpad-troubleshooting.md b/external/troubleshooting/thinkpad-troubleshooting.md
index 42f25997..e0e99603 100644
--- a/external/troubleshooting/thinkpad-troubleshooting.md
+++ b/external/troubleshooting/thinkpad-troubleshooting.md
@@ -11,7 +11,7 @@ redirect_from:
 - /en/doc/lenovo450-tinkering/
 - /doc/Lenovo450Tinkering/
 - /wiki/Lenovo450Tinkering/
-redirect_to: https://github.com/Qubes-Community/Contents/blob/master/docs/troubleshooting/thinkpad-troubleshooting.md
+redirect_to: https://forum.qubes-os.org/t/19024
 ref: 95
 title: Lenovo ThinkPad troubleshooting
 ---
diff --git a/introduction/faq.md b/introduction/faq.md
index 5b334e91..2258ee1b 100644
--- a/introduction/faq.md
+++ b/introduction/faq.md
@@ -459,7 +459,7 @@ You have to restart the NetVM after the template has been shut down.
 ### Can I install Qubes OS together with other operating system (dual-boot/multi-boot)?
 
 You shouldn't do that, because it poses a security risk for your Qubes OS installation.
-But if you understand the risk and accept it, read [documentation on multibooting](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/multiboot.md).
+But if you understand the risk and accept it, read [documentation on multibooting](https://forum.qubes-os.org/t/18988).
 It begins with an explanation of the risks with such a setup.
 
 ### Which version of Qubes am I running?
@@ -806,4 +806,4 @@ If you need to support not-fully-updated systems, check for the existence of `/u
 
 Yes, Qubes natively supports automation via [Salt (SaltStack)](/doc/salt/).
 There is also the unofficial [ansible-qubes toolkit](https://github.com/Rudd-O/ansible-qubes).
-(**Warning:** Since this is an external project that has not been reviewed or endorsed by the Qubes team, [allowing it to manage dom0 may be a security risk](https://github.com/Qubes-Community/Contents/blob/master/docs/security/security-guidelines.md#dom0-precautions).)
+(**Warning:** Since this is an external project that has not been reviewed or endorsed by the Qubes team, [allowing it to manage dom0 may be a security risk](https://forum.qubes-os.org/t/19075#dom0-precautions).)
diff --git a/user/advanced-topics/standalones-and-hvms.md b/user/advanced-topics/standalones-and-hvms.md
index a911dc55..038f4f71 100644
--- a/user/advanced-topics/standalones-and-hvms.md
+++ b/user/advanced-topics/standalones-and-hvms.md
@@ -440,4 +440,4 @@ qemu-img -h | tail -n1
 Other documents related to HVMs:
 
 - [Windows VMs](https://github.com/Qubes-Community/Contents/blob/master/docs/os/windows/windows-vm.md)
-- [Linux HVM Tips](https://github.com/Qubes-Community/Contents/blob/master/docs/os/linux-hvm-tips.md)
+- [Linux HVM Tips](https://forum.qubes-os.org/t/19008)
diff --git a/user/how-to-guides/how-to-organize-your-qubes.md b/user/how-to-guides/how-to-organize-your-qubes.md
index 406d346d..e5c9891b 100644
--- a/user/how-to-guides/how-to-organize-your-qubes.md
+++ b/user/how-to-guides/how-to-organize-your-qubes.md
@@ -99,7 +99,7 @@ the other. Alice's setup looks like this:
 - **Several email qubes.** Since Alice is a command-line aficionado, she likes
   to use a terminal-based email client, so both her work and personal email
   qubes are based on a template with
-  [Mutt](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/mutt.md)
+  [Mutt](https://forum.qubes-os.org/t/18989)
   installed. The email qubes where she sends and receives PGP-signed and
   encrypted email securely accesses the private keys in her PGP backend qube
   (more on that below). To guard against malicious attachments, she configured
@@ -199,7 +199,7 @@ for work, which contains:
   communication.
 
 - **Two qubes for
-  [Signal](https://github.com/Qubes-Community/Contents/blob/master/docs/privacy/signal.md).**
+  [Signal](https://forum.qubes-os.org/t/19073).**
   Bob has two Signal app qubes (both on the same template in which the Signal
   desktop app is installed). One is linked to his own mobile number for
   communicating with co-workers and other known, trusted contacts. The other is
@@ -217,7 +217,7 @@ for work, which contains:
   the side benefit of helping to keep things organized.
 
 - **A [VPN
-  qube](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md)
+  qube](https://forum.qubes-os.org/t/19061)
   and associated qubes for accessing work resources.** The servers at work can
   only be accessed from the organization's network, so Bob has certain qubes
   that are connected to a VPN qube so that he can upload his work and access
@@ -391,7 +391,7 @@ Carol has added the following to her Qubes setup:
   physically air-gapped machine, but she's figures they all have different
   security properties. She also recently heard about using [Electrum as a
   "split" wallet in
-  Qubes](https://github.com/Qubes-Community/Contents/blob/master/docs/security/split-bitcoin.md)
+  Qubes](https://forum.qubes-os.org/t/19017)
   and is interested in exploring that further.
 
 - **Whonix qubes.** Carol read somewhere that Bitcoin nodes should be run over
diff --git a/user/how-to-guides/how-to-use-optical-discs.md b/user/how-to-guides/how-to-use-optical-discs.md
index 4d9cf4f7..4b7b536e 100644
--- a/user/how-to-guides/how-to-use-optical-discs.md
+++ b/user/how-to-guides/how-to-use-optical-discs.md
@@ -17,7 +17,7 @@ Currently, the only options for reading and recording optical discs (e.g., CDs,
  1. Use a USB optical drive.
  2. Attach a SATA optical drive to a secondary SATA controller, then assign this secondary SATA controller to a VM.
  3. Use a SATA optical drive attached to dom0.
-    (**Caution:** This option is [potentially dangerous](https://github.com/Qubes-Community/Contents/blob/master/docs/security/security-guidelines.md#dom0-precautions).)
+    (**Caution:** This option is [potentially dangerous](https://forum.qubes-os.org/t/19075#dom0-precautions).)
 
 To access an optical disc via USB follow the [typical procedure for attaching a USB device](/doc/how-to-use-usb-devices/#with-the-command-line-tool), then check with the **Qubes Devices** widget to see what device in the target qube the USB optical drive was attached to.
 Typically this would be `sr0`.
diff --git a/user/security-in-qubes/anti-evil-maid.md b/user/security-in-qubes/anti-evil-maid.md
index 19ac3193..0bcf0964 100644
--- a/user/security-in-qubes/anti-evil-maid.md
+++ b/user/security-in-qubes/anti-evil-maid.md
@@ -39,7 +39,7 @@ For more information, see the [qubes-antievilmaid](https://github.com/QubesOS/qu
 Security Considerations
 -----------------------
 
-[Qubes security guidelines](https://github.com/Qubes-Community/Contents/blob/master/docs/security/security-guidelines.md) dictate that USB devices should never be attached directly to dom0, since this can result in the entire system being compromised.
+[Qubes security guidelines](https://forum.qubes-os.org/t/19075) dictate that USB devices should never be attached directly to dom0, since this can result in the entire system being compromised.
 However, in its default configuration, installing and using AEM requires attaching a USB drive (i.e., [mass storage device](https://en.wikipedia.org/wiki/USB_mass_storage_device_class)) directly to dom0.
 (The other option is to install AEM to an internal disk.
 However, this carries significant security implications, as explained [here](https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html).) This presents us with a classic security trade-off: each Qubes user must make a choice between protecting dom0 from a potentially malicious USB drive, on the one hand, and protecting the system from Evil Maid attacks, on the other hand.
@@ -50,7 +50,7 @@ Therefore, it is up to each individual Qubes user to evaluate the relative risk
 For example, a user who frequently travels with a Qubes laptop holding sensitive data may be at a much higher risk of Evil Maid attacks than a home user with a stationary Qubes desktop.
 If the frequent traveler judges her risk of an Evil Maid attack to be higher than the risk of a malicious USB device, she might reasonably opt to install and use AEM.
 On the other hand, the home user might deem the probability of an Evil Maid attack occurring in her own home to be so low that there is a higher probability that any USB drive she purchases is already compromised, in which case she might reasonably opt never to attach any USB devices directly to dom0.
-(In either case, users can--and should--secure dom0 against further USB-related attacks through the use of a [USB VM](https://github.com/Qubes-Community/Contents/blob/master/docs/security/security-guidelines.md#creating-and-using-a-usbvm).)
+(In either case, users can--and should--secure dom0 against further USB-related attacks through the use of a [USB VM](https://forum.qubes-os.org/t/19075#creating-and-using-a-usbvm).)
 
 For more information, please see [this discussion thread](https://groups.google.com/d/msg/qubes-devel/EBc4to5IBdg/n1hfsHSfbqsJ).
 
diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index 7a5ad072..2974209b 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -88,7 +88,7 @@ The sys-firewall-2 proxy ensures that:
 
 If you adopt this model, you should be aware that all traffic will arrive at the `network service qube` appearing to originate from the IP address of `sys-firewall-2`.
 
-For the VPN service please also look at the [VPN documentation](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md).
+For the VPN service please also look at the [VPN documentation](https://forum.qubes-os.org/t/19061).
 
 Enabling networking between two qubes
 -------------------------------------
diff --git a/user/templates/minimal-templates.md b/user/templates/minimal-templates.md
index 8d63fbc4..4b5a394f 100644
--- a/user/templates/minimal-templates.md
+++ b/user/templates/minimal-templates.md
@@ -155,12 +155,12 @@ list of packages to be installed):
   `qubes-usb-proxy` to provide USB devices to other Qubes and
   `qubes-input-proxy-sender` to provide keyboard or mouse input to dom0.
 - [VPN
-  qube](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md):
+  qube](https://forum.qubes-os.org/t/19061):
   Use the `dnf search "NetworkManager VPN plugin"` command to look up the VPN
   packages you need, based on the VPN technology you'll be using, and install
   them. Some GNOME related packages may be needed as well. After creation of a
   machine based on this template, follow the [VPN
-  instructions](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md#set-up-a-proxyvm-as-a-vpn-gateway-using-networkmanager)
+  instructions](https://forum.qubes-os.org/t/19061#set-up-a-proxyvm-as-a-vpn-gateway-using-networkmanager)
   to configure it.
 - `default-mgmt-dvm`: requires `qubes-core-agent-passwordless-root` and
   `qubes-mgmt-salt-vm-connector`.
@@ -206,7 +206,7 @@ You may also wish to consider additional packages from the `qubes-core-agent`
 suite.
 
 See
-[here](https://github.com/Qubes-Community/Contents/blob/master/docs/customization/fedora-minimal-template-customization.md)
+[here](https://forum.qubes-os.org/t/18999)
 for further information on customizing `fedora-minimal`.
 
 #### Logging
@@ -254,11 +254,11 @@ list of packages to be installed):
   pair it with `qubes-core-agent-passwordless-root` or manually activate the
   user session with `loginctl activate <USER_SESSION_ID>`.)
 - [VPN
-  qube](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md):
+  qube](https://forum.qubes-os.org/t/19061):
   You may need to install network-manager VPN packages, depending on the VPN
   technology you'll be using. After creating a machine based on this template,
   follow the [VPN
-  howto](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md#set-up-a-proxyvm-as-a-vpn-gateway-using-networkmanager)
+  howto](https://forum.qubes-os.org/t/19061#set-up-a-proxyvm-as-a-vpn-gateway-using-networkmanager)
   to configure it.
 - `default-mgmt-dvm`: requires `qubes-core-agent-passwordless-root` and
   `qubes-mgmt-salt-vm-connector`.
@@ -334,11 +334,11 @@ list of packages to be installed):
   `qubes-usb-proxy` to provide USB devices to other Qubes and
   `qubes-input-proxy-sender` to provide keyboard or mouse input to dom0.
 - [VPN
-  qube](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md):
+  qube](https://forum.qubes-os.org/t/19061):
   You may need to install network-manager VPN packages, depending on the VPN
   technology you'll be using. After creating a machine based on this template,
   follow the [VPN
-  howto](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md#set-up-a-proxyvm-as-a-vpn-gateway-using-networkmanager)
+  howto](https://forum.qubes-os.org/t/19061#set-up-a-proxyvm-as-a-vpn-gateway-using-networkmanager)
   to configure it.
 - `default-mgmt-dvm`: requires `qubes-core-agent-passwordless-root` and
   `qubes-mgmt-salt-vm-connector`.
diff --git a/user/troubleshooting/installation-troubleshooting.md b/user/troubleshooting/installation-troubleshooting.md
index ddbf1a5c..ffc53e7a 100644
--- a/user/troubleshooting/installation-troubleshooting.md
+++ b/user/troubleshooting/installation-troubleshooting.md
@@ -75,11 +75,11 @@ These errors may also occur due to an incompatible Nvidia graphics card. If you
     noexitboot=1 modprobe.blacklist=nouveau rd.driver.blacklist=nouveau --- intitrd.img
     ```
 
-For more information, look at the [Nvidia Troubleshooting guide](https://github.com/Qubes-Community/Contents/blob/master/docs/troubleshooting/nvidia-troubleshooting.md#disabling-nouveau).
+For more information, look at the [Nvidia Troubleshooting guide](https://forum.qubes-os.org/t/19021#disabling-nouveau).
 
 ## Installation freezes at "Setting up Networking" 
  
-If you are facing this problem on an Apple computer, check out the [Macbook Troubleshooting guide](https://github.com/Qubes-Community/Contents/blob/master/docs/troubleshooting/macbook-troubleshooting.md).
+If you are facing this problem on an Apple computer, check out the [Macbook Troubleshooting guide](https://forum.qubes-os.org/t/19020).
 
 If you are installing Qubes 4.0 on an external storage device, you may have forgotten to disable `sys-usb` during the [initial setup](/doc/installation-guide/#initial-setup), which is generally required for that setup to work.
 
diff --git a/user/troubleshooting/pci-troubleshooting.md b/user/troubleshooting/pci-troubleshooting.md
index c1aad95b..42d30254 100644
--- a/user/troubleshooting/pci-troubleshooting.md
+++ b/user/troubleshooting/pci-troubleshooting.md
@@ -120,7 +120,7 @@ You can also configure strict reset directly from the Qubes interface by followi
 
 ## Broadcom BCM43602 Wi-Fi card causes system freeze
 
-You may face the problem where the BCM43602 Wi-Fi chip causes a system freeze whenever it is attached to a VM. To fix this problem on a Macbook, follow the steps in [Macbook Troubleshooting](https://github.com/Qubes-Community/Contents/blob/master/docs/troubleshooting/macbook-troubleshooting.md#system-freezes-after-attaching-broadcom-bcm43602-wi-fi-card).
+You may face the problem where the BCM43602 Wi-Fi chip causes a system freeze whenever it is attached to a VM. To fix this problem on a Macbook, follow the steps in [Macbook Troubleshooting](https://forum.qubes-os.org/t/19020#system-freezes-after-attaching-broadcom-bcm43602-wi-fi-card).
 
 For other non-Macbook machines, it is advisable to replace the Broadcom BCM43602 with one known to work on Qubes, such as the Atheros AR9462.
 
diff --git a/user/troubleshooting/uefi-troubleshooting.md b/user/troubleshooting/uefi-troubleshooting.md
index 0c84934a..35e33877 100644
--- a/user/troubleshooting/uefi-troubleshooting.md
+++ b/user/troubleshooting/uefi-troubleshooting.md
@@ -30,7 +30,7 @@ If you've installed successfully in legacy mode but had to change some kernel pa
 
 ## Installation freezes before displaying installer
 
-If you have an Nvidia card, see also [Nvidia Troubleshooting](https://github.com/Qubes-Community/Contents/blob/master/docs/troubleshooting/nvidia-troubleshooting.md#disabling-nouveau).
+If you have an Nvidia card, see also [Nvidia Troubleshooting](https://forum.qubes-os.org/t/19021#disabling-nouveau).
 
 ### Removing `noexitboot` and `mapbs`
 

From f6db6fc2dae3c843710ce4b465fe9de343e1c030 Mon Sep 17 00:00:00 2001
From: taradiddles <taradiddles@users.noreply.github.com>
Date: Tue, 15 Aug 2023 09:37:49 +0300
Subject: [PATCH 035/332] Fix remaining mention of qubes-community

---
 developer/general/documentation-style-guide.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/developer/general/documentation-style-guide.md b/developer/general/documentation-style-guide.md
index 4b4334e8..79146d96 100644
--- a/developer/general/documentation-style-guide.md
+++ b/developer/general/documentation-style-guide.md
@@ -262,7 +262,7 @@ Duplicating documentation is almost always a bad idea. There are many reasons fo
 
 ### Core vs. external documentation
 
-Core documentation resides in the [Qubes OS Project's official repositories](https://github.com/QubesOS/), mainly in [qubes-doc](https://github.com/QubesOS/qubes-doc). External documentation can be anywhere else (such as forums, community websites, and blogs), but there is an especially large collection in the [Qubes Forum](https://forum.qubes-os.org/docs). External documentation should not be submitted to [qubes-doc](https://github.com/QubesOS/qubes-doc). If you've written a piece of documentation that is not appropriate for [qubes-doc](https://github.com/QubesOS/qubes-doc), we encourage you to submit it to the [Qubes Forum](https://forum.qubes-os.org/docs) instead. However, *linking* to external documentation from [qubes-doc](https://github.com/QubesOS/qubes-doc) is perfectly fine. Indeed, the maintainers of the [Qubes Forum](https://forum.qubes-os.org/) should regularly submit PRs against the documentation index (see [How to edit the documentation index](/doc/how-to-edit-the-documentation/#how-to-edit-the-documentation-index)) to add and update Qubes Community links in the ["External documentation"](/doc/#external-documentation) section of the documentation table of contents.
+Core documentation resides in the [Qubes OS Project's official repositories](https://github.com/QubesOS/), mainly in [qubes-doc](https://github.com/QubesOS/qubes-doc). External documentation can be anywhere else (such as forums, community websites, and blogs), but there is an especially large collection in the [Qubes Forum](https://forum.qubes-os.org/docs). External documentation should not be submitted to [qubes-doc](https://github.com/QubesOS/qubes-doc). If you've written a piece of documentation that is not appropriate for [qubes-doc](https://github.com/QubesOS/qubes-doc), we encourage you to submit it to the [Qubes Forum](https://forum.qubes-os.org/docs) instead. However, *linking* to external documentation from [qubes-doc](https://github.com/QubesOS/qubes-doc) is perfectly fine. Indeed, the maintainers of the [Qubes Forum](https://forum.qubes-os.org/) should regularly submit PRs against the documentation index (see [How to edit the documentation index](/doc/how-to-edit-the-documentation/#how-to-edit-the-documentation-index)) to add and update Qubes Forum links in the ["External documentation"](/doc/#external-documentation) section of the documentation table of contents.
 
 The main difference between **core** (or **official**) and **external** (or **community** or **unofficial**) documentation is whether it documents software that is officially written and maintained by the Qubes OS Project. The purpose of this distinction is to keep the core docs maintainable and high-quality by limiting them to the software output by the Qubes OS Project. In other words, we take responsibility for documenting all of the software we put out into the world, but it doesn't make sense for us to take on the responsibility of documenting or maintaining documentation for anything else. For example, Qubes OS may use a popular Linux distribution for an official [TemplateVM](/doc/templates/). However, it would not make sense for a comparatively small project like ours, with modest funding and a lean workforce, to attempt to document software belonging to a large, richly-funded project with an army of paid and volunteer contributors, especially when they probably already have documentation of their own. This is particularly true when it comes to Linux in general. Although many users who are new to Qubes are also new to Linux, it makes absolutely no sense for our comparatively tiny project to try to document Linux in general when there is already a plethora of documentation out there.
 

From 98acc2c5b1bb90521c0cb073ba910c0b7036b602 Mon Sep 17 00:00:00 2001
From: Krzysztof Katowicz-Kowalewski <vnd@vndh.net>
Date: Sun, 27 Aug 2023 15:35:33 +0200
Subject: [PATCH 036/332] Update volume-backup-revert.md

fixing typo: 'minimum' to 'maximum'
---
 user/advanced-topics/volume-backup-revert.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/advanced-topics/volume-backup-revert.md b/user/advanced-topics/volume-backup-revert.md
index 50351107..3d836cc3 100644
--- a/user/advanced-topics/volume-backup-revert.md
+++ b/user/advanced-topics/volume-backup-revert.md
@@ -31,7 +31,7 @@ qvm-volume info vmname:private
 
 The output of the above command will also display the "Available revisions
 (for revert)" at the bottom. For a very large volume in a small pool,
-revisions_to_keep should probably be set to the minimum value of 1 to minimize
+revisions_to_keep should probably be set to the maximum value of 1 to minimize
 the possibility of the pool being accidentally filled up by snapshots. For a
 smaller volume for which you would like to have the future option of reverting,
 revisions_to_keep should probably be set to at least 2. To set

From 09ec28134430cccbf2124ea6032c69ae7c5a3f08 Mon Sep 17 00:00:00 2001
From: Ben Grande <ben.grande.b@gmail.com>
Date: Wed, 4 Oct 2023 21:16:40 +0000
Subject: [PATCH 037/332] Add Wi-Fi requirement to Debian minimal templates

Removed:
- qubes-core-agent-networking: already a dependency of
  qubes-core-agent-network-manager;
Added:
- wpasupplicant: required for Wi-Fi, it is recommended by
  network-manager but is not installed if not installing recommends.
  It is required on Fedora by NetworkManager-wifi and was installed by
  default on Debian Minimal before
  https://github.com/QubesOS/qubes-builder-debian/pull/74;
- gnome-keyring: already recommended on the Fedora section, saves Wi-Fi
  password;
---
 user/templates/minimal-templates.md | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/user/templates/minimal-templates.md b/user/templates/minimal-templates.md
index 8d63fbc4..c4787ef5 100644
--- a/user/templates/minimal-templates.md
+++ b/user/templates/minimal-templates.md
@@ -240,12 +240,14 @@ list of packages to be installed):
 - [FirewallVM](/doc/firewall/), such as the template for `sys-firewall`: at
   least `qubes-core-agent-networking`, and also `qubes-core-agent-dom0-updates`
   if you want to use it as the `UpdateVM` (which is normally `sys-firewall`).
-- NetVM, such as the template for `sys-net`: `qubes-core-agent-networking`
-  `qubes-core-agent-network-manager`. If your network devices need extra
-  packages for a network VM, use the `lspci` command to identify the devices,
-  then find the package that provides necessary firmware and install it. If you
-  need utilities for debugging and analyzing network connections, install the
-  following packages: `tcpdump` `telnet` `nmap` `ncat`.
+- NetVM, such as the template for `sys-net`: Ethernet requires
+  `qubes-core-agent-network-manager`, and Wi-Fi requires the previous
+  package(s) plus `wpasupplicant`, optionally `gnome-keyring` for saving the
+  Wi-Fi password. If your network devices need extra packages for a network
+  VM, use the `lspci` command to identify the devices, then find the package
+  that provides necessary firmware and install it. If you need utilities for
+  debugging and analyzing network connections, install the following packages:
+  `tcpdump` `telnet` `nmap` `ncat`.
 - [USB qube](/doc/usb-qubes/), such as the template for `sys-usb`:
   `qubes-usb-proxy` to provide USB devices to other Qubes and
   `qubes-input-proxy-sender` to provide keyboard or mouse input to dom0.

From d9560c17aae00b5712a789f0c4b127cb867aa05c Mon Sep 17 00:00:00 2001
From: Gordon Shumway <60302611+gordon-shumway-net@users.noreply.github.com>
Date: Sat, 14 Oct 2023 22:51:21 +0200
Subject: [PATCH 038/332] added ntp package hint

---
 user/templates/minimal-templates.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/templates/minimal-templates.md b/user/templates/minimal-templates.md
index 8d63fbc4..f902f8d5 100644
--- a/user/templates/minimal-templates.md
+++ b/user/templates/minimal-templates.md
@@ -241,8 +241,8 @@ list of packages to be installed):
   least `qubes-core-agent-networking`, and also `qubes-core-agent-dom0-updates`
   if you want to use it as the `UpdateVM` (which is normally `sys-firewall`).
 - NetVM, such as the template for `sys-net`: `qubes-core-agent-networking`
-  `qubes-core-agent-network-manager`. If your network devices need extra
-  packages for a network VM, use the `lspci` command to identify the devices,
+  `qubes-core-agent-network-manager` `systemd-timesyncd`(or other NTP Service).
+  If your network devices need extra packages for a network VM, use the `lspci` command to identify the devices,
   then find the package that provides necessary firmware and install it. If you
   need utilities for debugging and analyzing network connections, install the
   following packages: `tcpdump` `telnet` `nmap` `ncat`.

From 299f31f37b584c6c23a81e3fbd9a6948bd42bb08 Mon Sep 17 00:00:00 2001
From: Gordon Shumway <60302611+gordon-shumway-net@users.noreply.github.com>
Date: Sun, 15 Oct 2023 17:34:48 +0200
Subject: [PATCH 039/332] First revision of an disposable creation intro

---
 user/how-to-guides/how-to-use-disposables.md | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/user/how-to-guides/how-to-use-disposables.md b/user/how-to-guides/how-to-use-disposables.md
index 7999d8b7..2778d2ff 100644
--- a/user/how-to-guides/how-to-use-disposables.md
+++ b/user/how-to-guides/how-to-use-disposables.md
@@ -22,6 +22,22 @@ From inside an app qube, choosing the `Open in disposable` option on a file will
 
 This diagram provides a general example of how disposables can be used to safely open untrusted links and attachments in disposables. See [this article](https://blog.invisiblethings.org/2010/06/01/disposable-vms.html) for more on why one would want to use a disposable.
 
+## Named disposables and disposable templates
+
+There is a difference between [named disposables](/doc/glossary/#named-disposable) and [disposable templates](/doc/glossary/#disposable-template).
+
+In a default QubesOS Installation, you would probably use the 'whonix-ws-16-dvm' if you, as an example, want to browse the Tor network with an disposable. Every application starts a new random disposable with an ID in the name and if you close the window, it shuts down the qube. This is the feeling of an disposable template.
+
+In named disposables every application starts in the same qube, the qube itself has a fixed name and you need to manually shutdown the qube. Except from the non-persistance, they feel like usual app qubes. Named disposables are built upon disposable templates.
+
+### How to create disposable templates
+
+First you need to create an app qube. After that you need to go to the 'Qubes Settings' of the created app qube and set it as a 'Disposable template' in the 'Advanced' section and apply the change. From now on the entry in the Application menu is not named 'Qube' anymore, but splitted into 'Disposable' and 'Template (disp)'. The settings for the disposable can be changed under **'Application Menu -> Template (disp) -> Template: Qubes Settings**
+
+### How to create named disposables
+
+Named disposables can be created under **Application Menu -> Create Qubes VM**, the type needs to be 'DisposableVM'.
+
 ## Security
 
 If a [disposable template](/doc/glossary/#disposable-template) becomes compromised, then any disposable based on that disposable template could be compromised. In particular, the *default* disposable template is important because it is used by the "Open in disposable" feature. This means that it will have access to everything that you open with this feature. For this reason, it is strongly recommended that you base the default disposable template on a trusted template.

From e3e23814d0f6ef4d1832d6fe863a1fc20317509d Mon Sep 17 00:00:00 2001
From: Patrick Schleizer <adrelanos@whonix.org>
Date: Tue, 24 Oct 2023 10:25:31 -0400
Subject: [PATCH 040/332] Update managing-vm-kernels.md

---
 user/advanced-topics/managing-vm-kernels.md | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/user/advanced-topics/managing-vm-kernels.md b/user/advanced-topics/managing-vm-kernels.md
index 903151ad..5c7ba0d6 100644
--- a/user/advanced-topics/managing-vm-kernels.md
+++ b/user/advanced-topics/managing-vm-kernels.md
@@ -275,9 +275,11 @@ grub2-probe: error: cannot find a GRUB drive for /dev/mapper/dmroot. Check your
 
 Then shutdown the VM.
 
-**Note:** You may also use `PV` mode instead of `HVM` but this is not recommended for security purposes.
-If you require `PV` mode, install `grub2-xen` in dom0 and change the template's kernel to `pvgrub2`.
-Booting to a kernel inside the template is not supported under `PVH`.
+**Notes:**
+
+* You may also use `PV` mode instead of `HVM` but this is not recommended for security purposes.
+* If you require `PV` mode, install `grub2-xen-pvh` in dom0 and change the template's kernel to `pvgrub2-pvh`.
+* Booting to a kernel inside the template is not supported under `PVH`.
 
 ### Installing kernel in Debian VM
 
@@ -311,7 +313,7 @@ Go to dom0 -> Qubes VM Manger -> right click on the VM -> Qube settings -> Advan
 Depends on `Virtualization` mode setting:
 
 * `Virtualization` mode `PV`: Possible, however use of `Virtualization` mode `PV` mode is discouraged for security purposes.
-  * If you require `Virtualization` mode `PV` mode, install `grub2-xen` in dom0. This can be done by running command `sudo qubes-dom0-update grub2-xen` in dom0.
+  * If you require `Virtualization` mode `PV` mode, install `grub2-xen-pvh` in dom0. This can be done by running command `sudo qubes-dom0-update pvgrub2-pvh in dom0.
 * `Virtualization` mode `PVH`: Possible.
 * `Virtualization` mode `HVM`: Possible.
 

From b1d22b6d6bc1be93246faa19406d89d3d6a516f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sol=C3=A8ne=20Rapenne?= <solene@perso.pw>
Date: Fri, 3 Nov 2023 12:17:09 +0100
Subject: [PATCH 041/332] doc: firewall: small improvements

---
 user/security-in-qubes/firewall.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index 7a5ad072..369308f9 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -31,8 +31,8 @@ In order to edit rules for a given qube, select it in the Qube Manager and press
 
 If the qube is running, you can open Settings from the Qube Popup Menu.
 
-*R4.0 note:* ICMP and DNS are no longer accessible in the GUI, but can be changed via `qvm-firewall` described below.
-Connections to Updates Proxy are not made over a network so can not be allowed or blocked with firewall rules, but are controlled using the relevant policy file (see [R4.0 Updates proxy](/doc/software-update-vm/) for more detail).
+ICMP and DNS are not accessible in the GUI, but can be changed via `qvm-firewall` described below.
+Connections to Updates Proxy are not made over a network so can not be allowed or blocked with firewall rules, but are controlled using the relevant policy file (see [R4.x Updates proxy](/doc/software-update-vm/) for more detail).
 
 Note that if you specify a rule by DNS name it will be resolved to IP(s) *at the moment of applying the rules*, and not on the fly for each new connection.
 This means it will not work for servers using load balancing, and traffic to complex web sites which draw from many servers will be difficult to control.
@@ -50,19 +50,19 @@ Rules are implemented on the netvm.
 
 You can also manually create rules in the qube itself using standard firewalling controls.
 See [Where to put firewall rules](#where-to-put-firewall-rules).
-In complex cases, it might be appropriate to load a ruleset using `iptables-restore` called from `/rw/config/rc.local`.
+In complex cases, it might be appropriate to load a ruleset using `nft -f /path/to/ruleset` called from `/rw/config/rc.local`, the ruleset file can be populated from the current ruleset using `nft list ruleset > /path/to/ruleset`, you should add `flush ruleset` at the top of the file to remove all existing rules before loading them.
 if you do this, be aware that `rc.local` is called *after* the network is up, so local rules should not be relied upon to block leaks.
 
 Reconnecting qubes after a NetVM reboot
 -------------------------------------
 
 Normally Qubes doesn't let the user stop a NetVM if there are other qubes running which use it as their own NetVM.
-But in case the NetVM stops for whatever reason (e.g. it crashes, or the user forces its shutdown via qvm-kill via terminal in Dom0), Qubes R4.0 will often automatically repair the connection.
+But in case the NetVM stops for whatever reason (e.g. it crashes, or the user forces its shutdown via qvm-kill via terminal in Dom0), Qubes R4.x will often automatically repair the connection.
 If it does not, then there is an easy way to restore the connection to the NetVM by issuing in dom0:
 
 ` qvm-prefs <vm> netvm <netvm> `
 
-Normally qubes do not connect directly to the actual NetVM which has networking devices, but rather to the default sys-firewall first, and in most cases it would be the NetVM that will crash, e.g. in response to S3 sleep/restore or other issues with WiFi drivers.
+Normally qubes do not connect directly to the actual NetVM (sys-net by default) which has networking devices, but rather to the default sys-firewall first, and in most cases it would be the NetVM that will crash, e.g. in response to S3 sleep/restore or other issues with WiFi drivers.
 In that case it is only necessary to issue the above command once, for the sys-firewall (this assumes default VM-naming used by the default Qubes installation):
 
 ` qvm-prefs sys-firewall netvm sys-net `
@@ -242,7 +242,7 @@ When the qube `unstrusted` has started (after a first reboot), you can directly
 Port forwarding to a qube from the outside world
 ------------------------------------------------
 
-In order to allow a service present in a qube to be exposed to the outside world in the default setup (where the qube has sys-firewall as network VM, which in turn has sys-net as network VM) the following needs to be done:
+In order to allow a service present in a qube to be exposed to the outside world in the default setup (where the qube has `sys-firewall` as network VM, which in turn has `sys-net` as network VM) the following needs to be done:
 
 - In the sys-net VM:
   - Route packets from the outside world to the sys-firewall VM

From a3cefd266eacad101472155da53d4719c0d19add Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sol=C3=A8ne=20Rapenne?= <solene@perso.pw>
Date: Fri, 3 Nov 2023 12:17:28 +0100
Subject: [PATCH 042/332] doc: firewall: add tcpdump example

---
 user/security-in-qubes/firewall.md | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index 369308f9..4be3aed2 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -509,3 +509,13 @@ Firewall troubleshooting
 Firewall logs are stored in the systemd journal of the qube the firewall is running in (probably `sys-firewall`).
 You can view them by running `sudo journalctl -u qubes-firewall.service` in the relevant qube.
 Sometimes these logs can contain useful information about errors that are preventing the firewall from behaving as you would expect.
+
+An effective console utility to troubleshoot network is [tcpdump](https://www.tcpdump.org/), it can be used to display network packets entering or leaving network interfaces.
+
+For instance, if you want to check if your network interface `eth0` is receiving packets on port TCP 22 from the network 192.168.x.y, you can run this command:
+
+```
+tcpdump -i eth0 -nn dst port 22 and src net 192.168.x.y/24
+```
+
+This can be used effectively in a destination qube and its Network VM to see if forwarding / NAT rules are working.

From 5738e75e46b02b926ecc0cd340a4da6f7ee09bac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sol=C3=A8ne=20Rapenne?= <solene@perso.pw>
Date: Fri, 3 Nov 2023 12:19:03 +0100
Subject: [PATCH 043/332] doc: firewall: switch to nftables

---
 user/security-in-qubes/firewall.md | 269 ++++++++++-------------------
 1 file changed, 90 insertions(+), 179 deletions(-)

diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index 4be3aed2..f932f4ed 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -71,7 +71,7 @@ Network service qubes
 ---------------------
 
 Qubes does not support running any networking services (e.g. VPN, local DNS server, IPS, ...) directly in a qube that is used to run the Qubes firewall service (usually sys-firewall) for good reasons.
-In particular, if you want to ensure proper functioning of the Qubes firewall, you should not tinker with iptables or nftables rules in such qubes.
+In particular, if you want to ensure proper functioning of the Qubes firewall, you should not tinker with nftables rules in such qubes.
 
 Instead, you should deploy a network infrastructure such as
 
@@ -95,45 +95,43 @@ Enabling networking between two qubes
 
 Normally any networking traffic between qubes is prohibited for security reasons.
 However, in special situations, you might want to selectively allow specific qubes to establish networking connectivity between each other.
-For example, this might be useful in some development work, when you want to test networking code, or to allow file exchange between HVM domains (which do not have Qubes tools installed) via SMB/scp/NFS protocols.
+For example, this might be useful in some development work, when you want to test networking code, or to allow file exchange between HVM domains (which do not have Qubes tools installed) via SMB/SSH/NFS protocols.
 
-In order to allow networking between qubes A and B follow these steps:
+In order to allow networking from qube A (client) to qube B (server) follow these steps:
 
 - Make sure both A and B are connected to the same firewall vm (by default all VMs use the same firewall VM).
 - Note the Qubes IP addresses assigned to both qubes.
-  This can be done using the `qvm-ls -n` command, or via the Qubes Manager preferences pane for each qube.
+  This can be done using the `qvm-ls -n` command, or via the Qubes Manager using the IP column.
 - Start both qubes, and also open a terminal in the firewall VM
-- In the firewall VM's terminal enter the following iptables rule:
+- In the firewall VM's terminal enter the following nftables rule:
 
 ~~~
-sudo iptables -I FORWARD 2 -s <IP address of A> -d <IP address of B> -j ACCEPT
+sudo nft add rule ip qubes custom-forward ip saddr <IP address of A> ip daddr <IP address of B> accept
 ~~~
 
-- In qube B's terminal enter the following iptables rule:
+- In qube B's terminal enter the following nftables rule:
 
 ~~~
-sudo iptables -I INPUT -s <IP address of A> -j ACCEPT
+sudo nft add rule qubes custom-input ip saddr <IP address of A> accept
 ~~~
 
 - Now you should be able to reach B from A -- test it using e.g. ping issued from A.
   Note however, that this doesn't allow you to reach A from B -- for this you would need two more rules, with A and B swapped.
-- If everything works as expected, then you should write the above iptables rules into firewallVM's `qubes-firewall-user-script` script.
+- If everything works as expected, then you should write the above nftables rules into firewallVM's `qubes-firewall-user-script` script.
   This script is run when the netvm starts up.
   You should also write relevant rules in A and B's `rc.local` script which is run when the qube is launched.
   Here's an example how to update the script:
 
 ~~~
-[user@sys-firewall ~]$ sudo bash
-[root@sys-firewall user]# echo "iptables -I FORWARD 2 -s 10.137.2.25 -d 10.137.2.6 -j ACCEPT" >> /rw/config/qubes-firewall-user-script
-[root@sys-firewall user]# chmod +x /rw/config/qubes-firewall-user-script
+[user@sys-firewall ~]$ sudo -i
+[root@sys-firewall user]# echo "nft add rule ip qubes custom-forward ip saddr 10.137.2.25 ip daddr 10.137.2.6 accept" >> /rw/config/qubes-firewall-user-script
 ~~~
 
 - Here is an example how to update `rc.local`:
 
 ~~~
-[user@B ~]$ sudo bash
-[root@B user]# echo "iptables -I INPUT -s 10.137.2.25 -j ACCEPT" >> /rw/config/rc.local
-[root@B user]# chmod +x /rw/config/rc.local
+[user@B ~]$ sudo -i
+[root@B user]# echo "nft add rule qubes custom-input ip saddr 10.137.2.25 accept" >> /rw/config/rc.local
 ~~~
 
 Opening a single TCP port to other network-isolated qube
@@ -250,10 +248,10 @@ In order to allow a service present in a qube to be exposed to the outside world
 - In the sys-firewall VM:
   - Route packets from the sys-net VM to the VM
   - Allow packets through the sys-firewall VM firewall
-- In the qube:
+- In the qube QubeDest:
   - Allow packets through the qube firewall to reach the service
 
-As an example we can take the use case of a web server listening on port 443 that we want to expose on our physical interface eth0, but only to our local network 192.168.x.0/24.
+As an example we can take the use case of qube QubeDest running a web server listening on port 443 that we want to expose on our physical interface ens6, but only to our local network 192.168.x.y/24.
 
 > Note: To have all interfaces available and configured, make sure the 3 qubes are up and running
 
@@ -261,113 +259,85 @@ As an example we can take the use case of a web server listening on port 443 tha
 
 **1. Identify the IP addresses you will need to use for sys-net, sys-firewall and the destination qube.**
 
-You can get this information from the Settings Window for the qube, or by running this command in each qube:
-`ifconfig | grep -i cast `
+You can get this information using various methods, but only the first one can be used for `sys-net` outside world IP:
+
+- by running this command in each qube: `ip -4 -br a | grep UP`
+- using `qvm-ls -n`
+- in the Qubes Manager window using the column IP
+- from the Settings Window for the qube
+
 Note the IP addresses you will need.
 > Note: The vifx.0 interface is the one used by qubes connected to this netvm so it is _not_ an outside world interface.
 
 **2. Route packets from the outside world to the FirewallVM**
 
-For the following example, we assume that the physical interface eth0 in sys-net has the IP address 192.168.x.y and that the IP address of sys-firewall is 10.137.1.z.
+For the following example, we assume that the physical interface ens6 in sys-net is on the local network 192.168.x.y with the IP 192.168.x.n, and that the IP address of sys-firewall is 10.137.1.z.
 
-In the sys-net VM's Terminal, code a natting firewall rule to route traffic on the outside interface for the service to the sys-firewall VM
+In the sys-net VM's Terminal, the first step is to to define an ntables chain that will receive DNAT rules, we recommend to define a new chain for each destination qubes, this ease the rules management:
 
 ```
-iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.x.y -j DNAT --to-destination 10.137.1.z
+nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
 ```
 
-Code the appropriate new filtering firewall rule to allow new connections for the service
+Second step, code a natting firewall rule to route traffic on the outside interface for the service to the sys-firewall VM
 
 ```
-iptables -I FORWARD 2 -i eth0 -d 10.137.1.z -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
+nft add rule qubes custom-dnat-qubeDEST iifname == "ens6" ip saddr 192.168.x.y/24 tcp dport 443 counter dnat 10.137.1.z
 ```
 
-> If you want to expose the service on multiple interfaces, repeat the steps described in part 1 for each interface.
-> In Qubes R4, at the moment ([QubesOS/qubes-issues#3644](https://github.com/QubesOS/qubes-issues/issues/3644)), nftables is also used which imply that additional rules need to be set in a `qubes-firewall` nft table with a forward chain.
-
-`nft add rule ip qubes-firewall forward meta iifname eth0 ip daddr 10.137.1.z tcp dport 443 ct state new counter accept`
-
-Verify you are cutting through the sys-net VM firewall by looking at its counters (column 2)
+Third step, code the appropriate new filtering firewall rule to allow new connections for the service
 
 ```
-iptables -t nat -L -v -n
-iptables -L -v -n
+nft add rule qubes custom-forward iifname == "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 counter accept
 ```
 
-> Note: On Qubes R4, you can also check the nft counters
+> Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
+
+> If you want to expose the service on multiple interfaces, repeat the steps 2 and 3 described above, for each interface.
+
+Verify you are cutting through the sys-net VM firewall by looking at its counters, check for the lines in the chains `custom-forward` and `custom-dnat-qubeDEST`:
 
 ```
 nft list table ip qubes-firewall
 ```
 
-Send a test packet by trying to connect to the service from an external device
+E.g. In our example, we can see 7 packets in the forward rule, and 3 packets in the dnat rule:
 
 ```
-telnet 192.168.x.y 443
+chain custom-forward {
+  iifname "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 counter packets 7 bytes 448 accept
+}
+
+chain custom-dnat-qubeDEST {
+  type nat hook prerouting priority filter + 1; policy accept;
+  iifname "ens6" ip saddr 192.168.x.y/24 tcp dport 443 counter packets 3 bytes 192 dnat to 10.138.33.59
+}
 ```
 
-Once you have confirmed that the counters increase, store these command in `/rw/config/rc.local` so they get set on sys-net start-up
+Optional step: You can send a test packet by trying to connect to the service from an external device using the following command:
 
 ```
-sudo nano /rw/config/rc.local
+telnet 192.168.x.n 443
+```
+
+Once you have confirmed that the counters increase, store the commands used in the previous steps in `/rw/config/rc.local` so they get set on sys-net start-up
+
+```
+[user@sys-net user]$ sudo -i
+[root@sys-net user]# nano /rw/config/qubes-firewall-user-script
 ```
 
 ~~~
 #!/bin/sh
 
+# create the dnat chain for qubeDEST if it doesn't already exist
+if nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
+then
+  # create the dnat rule
+  nft add rule qubes custom-dnat-qubeDEST iifname == "ens6" saddr 192.168.x.y/24 tcp dport 443 counter dnat 10.137.1.z
 
-####################
-# My service routing
-
-# Create a new firewall natting chain for my service
-if iptables -w -t nat -N MY-HTTPS; then
-
-# Add a natting rule if it did not exist (to avoid clutter if script executed multiple times)
-  iptables -w -t nat -A MY-HTTPS -j DNAT --to-destination 10.137.1.z
-
-fi
-
-
-# If no prerouting rule exist for my service
-if ! iptables -w -t nat -n -L PREROUTING | grep --quiet MY-HTTPS; then
-
-# add a natting rule for the traffic (same reason)
-  iptables -w -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.x.y -j MY-HTTPS
-fi
-
-
-######################
-# My service filtering
-
-# Create a new firewall filtering chain for my service
-if iptables -w -N MY-HTTPS; then
-
-# Add a filtering rule if it did not exist (to avoid clutter if script executed multiple times)
-  iptables -w -A MY-HTTPS -s 192.168.x.0/24 -j ACCEPT
-
-fi
-
-# If no forward rule exist for my service
-if ! iptables -w -n -L FORWARD | grep --quiet MY-HTTPS; then
-
-# add a forward rule for the traffic (same reason)
-  iptables -w -I FORWARD 2 -d 10.137.1.z -p tcp --dport 443 -m conntrack --ctstate NEW -j MY-HTTPS
-
-fi
-~~~
-
-> Note: Again in R4 the following needs to be added:
-
-~~~
-#############
-# In Qubes R4
-
-# If not already present
-if nft -nn list table ip qubes-firewall | grep "tcp dport 443 ct state new"; then
-
-# Add a filtering rule
-  nft add rule ip qubes-firewall forward meta iifname eth0 ip daddr 10.137.1.z tcp dport 443 ct state new counter accept
-
+  # allow forwarded traffic
+  nft add rule qubes custom-forward iifname == "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 counter accept
 fi
 ~~~
 
@@ -375,133 +345,74 @@ fi
 
 For the following example, we use the fact that the physical interface of sys-firewall, facing sys-net, is eth0. Furthermore, we assume that the target VM running the web server has the IP address 10.137.0.xx and that the IP address of sys-firewall is 10.137.1.z.
 
-In the sys-firewall VM's Terminal, code a natting firewall rule to route traffic on its outside interface for the service to the qube
+In the sys-firewall VM's Terminal, add a DNAT chain to route traffic on its outside interface for the service to the qube:
 
 ```
-iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 10.137.1.z -j DNAT --to-destination 10.137.0.xx
+nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
 ```
 
-Code the appropriate new filtering firewall rule to allow new connections for the service
+Second step, code a natting firewall rule to route traffic on the outside interface for the service to the destination qube
 
 ```
-iptables -I FORWARD 2 -i eth0 -s 192.168.x.0/24 -d 10.137.0.xx -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
+nft add rule qubes custom-dnat-qubeDEST iifname == "eth0" ip saddr 192.168.x.y/24 tcp dport 443 counter dnat 10.137.0.xx
 ```
 
-> Note: If you do not wish to limit the IP addresses connecting to the service, remove the ` -s 192.168.0.1/24 `
-
-> Note: On Qubes R4
+Third step, code the appropriate new filtering firewall rule to allow new connections for the service
 
 ```
-nft add rule ip qubes-firewall forward meta iifname eth0 ip saddr 192.168.x.0/24 ip daddr 10.137.0.xx tcp dport 443 ct state new counter accept
+nft add rule qubes custom-forward iifname == "eth0" ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 counter accept
 ```
 
-Once you have confirmed that the counters increase, store these command in `/rw/config/qubes-firewall-user-script`
+> Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
+
+Once you have confirmed that the counters increase, store these commands in the script `/rw/config/qubes-firewall-user-script`
 
 ```
-sudo nano /rw/config/qubes-firewall-user-script
+[user@sys-net user]$ sudo -i
+[root@sys-net user]# nano /rw/config/qubes-firewall-user-script
 ```
 
 ~~~
 #!/bin/sh
 
+# create the dnat chain for qubeDEST if it doesn't already exist
+if nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
+then
+  # create the dnat rule
+  nft add rule qubes custom-dnat-qubeDEST iifname == "eth0" tcp dport 22 counter dnat 10.137.0.xx
 
-####################
-# My service routing
-
-# Create a new firewall natting chain for my service
-if iptables -w -t nat -N MY-HTTPS; then
-
-# Add a natting rule if it did not exist (to avoid clutter if script executed multiple times)
-  iptables -w -t nat -A MY-HTTPS -j DNAT --to-destination 10.137.0.xx
-
-fi
-
-
-# If no prerouting rule exist for my service
-if ! iptables -w -t nat -n -L PREROUTING | grep --quiet MY-HTTPS; then
-
-# add a natting rule for the traffic (same reason)
-  iptables -w -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 10.137.1.z -j MY-HTTPS
-fi
-
-
-######################
-# My service filtering
-
-# Create a new firewall filtering chain for my service
-if iptables -w -N MY-HTTPS; then
-
-# Add a filtering rule if it did not exist (to avoid clutter if script executed multiple times)
-  iptables -w -A MY-HTTPS -s 192.168.x.0/24 -j ACCEPT
-
-fi
-
-# If no forward rule exist for my service
-if ! iptables -w -n -L FORWARD | grep --quiet MY-HTTPS; then
-
-# add a forward rule for the traffic (same reason)
-  iptables -w -I FORWARD 4 -d 10.137.0.xx -p tcp --dport 443 -m conntrack --ctstate NEW -j MY-HTTPS
-
-fi
-
-################
-# In Qubes OS R4
-
-# If not already present
-if ! nft -nn list table ip qubes-firewall | grep "tcp dport 443 ct state new"; then
-
-# Add a filtering rule
-  nft add rule ip qubes-firewall forward meta iifname eth0 ip saddr 192.168.x.0/24 ip daddr 10.137.0.xx tcp dport 443 ct state new counter accept
-
+  # allow forwarded traffic
+  nft add rule qubes custom-forward iifname == "eth0" ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 22 counter accept
 fi
 ~~~
 
-Finally make this file executable (so it runs at every Firewall VM update)
-
-~~~
-sudo chmod +x /rw/config/qubes-firewall-user-script
-~~~
-
-If the service should be available to other VMs on the same system, do not forget to specify the additional rules described above.
+If the service should be available to other VMs on the same system, do not forget to specify the additional rules described earlier in this guide.
 
 **4. Allow packets into the qube to reach the service**
 
-Here no routing is required, only filtering.
-Proceed in the same way as above but store the filtering rule in the `/rw/config/rc.local` script.
+No routing is required in the destination qube, only filtering.
 For the following example, we assume that the target VM running the web server has the IP address 10.137.0.xx
 
+The according rule to allow the traffic is:
+
 ```
-sudo nano /rw/config/rc.local
+nft add rule qubes custom-input tcp dport 443 ip daddr 10.137.0.xx counter accept
 ```
 
-~~~
-######################
-# My service filtering
+To make it persistent, you need to add this command in `/rw/config/rc.local`:
 
-# Create a new firewall filtering chain for my service
-if iptables -w -N MY-HTTPS; then
+```
+[user@qubeDEST user]$ sudo -i
+[root@qubeDEST user]# echo 'nft add rule qubes custom-input tcp dport 443 ip daddr 10.137.0.xx counter accept' >> /rw/config/rc.local
+```
 
-# Add a filtering rule if it did not exist (to avoid clutter if script executed multiple times)
-  iptables -w -A MY-HTTPS -j ACCEPT
-
-fi
-
-# If no input rule exists for my service
-if ! iptables -w -n -L INPUT | grep --quiet MY-HTTPS; then
-
-# add a forward rule for the traffic (same reason)
-  iptables -w -I INPUT 5 -d 10.137.0.xx -p tcp --dport 443 -m conntrack --ctstate NEW -j MY-HTTPS
-
-fi
-~~~
-
-This time testing should allow connectivity to the service as long as the service is up :-)
+This time testing should allow connectivity to the service as long qubeDEST is running and the service is up :-)
 
 Where to put firewall rules
 ---------------------------
 
-Implicit in the above example [scripts](/doc/config-files/), but worth calling attention to: for all qubes *except* those supplying networking, iptables commands should be added to the `/rw/config/rc.local` script.
-For app qubes supplying networking (`sys-firewall` inclusive), iptables commands should be added to `/rw/config/qubes-firewall-user-script`.
+Implicit in the above example [scripts](/doc/config-files/), but worth calling attention to: for all qubes *except* those supplying networking, nftables commands should be added to the `/rw/config/rc.local` script.
+For service qubes supplying networking (`sys-firewall` and `sys-net` inclusive), nftables commands should be added to `/rw/config/qubes-firewall-user-script`.
 
 Firewall troubleshooting
 ------------------------

From d6ad647518a35228e4fb3c79b2f55e58e32c09d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sol=C3=A8ne=20Rapenne?= <solene@perso.pw>
Date: Fri, 3 Nov 2023 14:50:42 +0100
Subject: [PATCH 044/332] doc: firewall: add nftables tips

---
 user/security-in-qubes/firewall.md | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index f932f4ed..d71e662e 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -430,3 +430,24 @@ tcpdump -i eth0 -nn dst port 22 and src net 192.168.x.y/24
 ```
 
 This can be used effectively in a destination qube and its Network VM to see if forwarding / NAT rules are working.
+
+Nftables tips
+-------------
+
+A simple way to experiment changes with your ruleset can be achieved by saving the current working ruleset in two files, one for backup and the other for making changes.
+
+By adding `flush ruleset` at the top of the file, you can achieve atomic update, which mean the new ruleset would replace the current one only if it fully succeed to load.
+
+You can dump the ruleset in two files using the following command:
+
+```
+nft list ruleset | tee nft_backup | tee nft_new_ruleset
+```
+
+Then, edit `nft_new_ruleset`, add `flush ruleset` on top and make changes, load it with `nft -f nft_new_ruleset`.
+
+You can revert to the original ruleset with the following commands:
+
+```
+nft flush ruleset && nft -f nft_backup
+```
\ No newline at end of file

From caf9b9a2b41c95de6e52243786b00e32a6dbc13e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sol=C3=A8ne=20Rapenne?= <solene@perso.pw>
Date: Fri, 3 Nov 2023 14:50:49 +0100
Subject: [PATCH 045/332] doc: firewall: rewording

---
 user/security-in-qubes/firewall.md | 26 ++++++++++++++++++--------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index d71e662e..e4ab0f0d 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -266,19 +266,24 @@ You can get this information using various methods, but only the first one can b
 - in the Qubes Manager window using the column IP
 - from the Settings Window for the qube
 
-Note the IP addresses you will need.
+Note the IP addresses you will need, they will be required in the next steps.
+
 > Note: The vifx.0 interface is the one used by qubes connected to this netvm so it is _not_ an outside world interface.
 
 **2. Route packets from the outside world to the FirewallVM**
 
 For the following example, we assume that the physical interface ens6 in sys-net is on the local network 192.168.x.y with the IP 192.168.x.n, and that the IP address of sys-firewall is 10.137.1.z.
 
-In the sys-net VM's Terminal, the first step is to to define an ntables chain that will receive DNAT rules, we recommend to define a new chain for each destination qubes, this ease the rules management:
+In the sys-net VM's Terminal, the first step is to to define an ntables chain that will receive DNAT rules to relay the network traffic on a given port to the qube NetVM, we recommend to define a new chain for each destination qube to ease rules management:
 
 ```
 nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
 ```
 
+> Note: the name `custom-dnat-qubeDST` is arbitrary
+
+> Note: while we use a DNAT chain for a single qube, it's totally possible to have a single DNAT chain for multiple qubes
+
 Second step, code a natting firewall rule to route traffic on the outside interface for the service to the sys-firewall VM
 
 ```
@@ -295,13 +300,13 @@ nft add rule qubes custom-forward iifname == "ens6" ip saddr 192.168.x.y/24 ip d
 
 > If you want to expose the service on multiple interfaces, repeat the steps 2 and 3 described above, for each interface.
 
-Verify you are cutting through the sys-net VM firewall by looking at its counters, check for the lines in the chains `custom-forward` and `custom-dnat-qubeDEST`:
+Verify the rules on sys-net firewall correctly match the packets you want by looking at its counters, check for the counter lines in the chains `custom-forward` and `custom-dnat-qubeDEST`:
 
 ```
 nft list table ip qubes-firewall
 ```
 
-E.g. In our example, we can see 7 packets in the forward rule, and 3 packets in the dnat rule:
+In this example, we can see 7 packets in the forward rule, and 3 packets in the dnat rule:
 
 ```
 chain custom-forward {
@@ -314,19 +319,21 @@ chain custom-dnat-qubeDEST {
 }
 ```
 
-Optional step: You can send a test packet by trying to connect to the service from an external device using the following command:
+(Optional) You can send a test packet by trying to connect to the service from an external device using the following command:
 
 ```
 telnet 192.168.x.n 443
 ```
 
-Once you have confirmed that the counters increase, store the commands used in the previous steps in `/rw/config/rc.local` so they get set on sys-net start-up
+Once you have confirmed that the counters increase, store the commands used in the previous steps in `/rw/config/rc.local` so they get set on sys-net start-up:
 
 ```
 [user@sys-net user]$ sudo -i
 [root@sys-net user]# nano /rw/config/qubes-firewall-user-script
 ```
 
+Content of `/rw/config/qubes-firewall-user-script` in `sys-net`:
+
 ~~~
 #!/bin/sh
 
@@ -345,7 +352,7 @@ fi
 
 For the following example, we use the fact that the physical interface of sys-firewall, facing sys-net, is eth0. Furthermore, we assume that the target VM running the web server has the IP address 10.137.0.xx and that the IP address of sys-firewall is 10.137.1.z.
 
-In the sys-firewall VM's Terminal, add a DNAT chain to route traffic on its outside interface for the service to the qube:
+In the sys-firewall VM's Terminal, add a DNAT chain that will contain routing rules:
 
 ```
 nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
@@ -372,6 +379,8 @@ Once you have confirmed that the counters increase, store these commands in the
 [root@sys-net user]# nano /rw/config/qubes-firewall-user-script
 ```
 
+Content of `/rw/config/qubes-firewall-user-script` in `sys-firewall`:
+
 ~~~
 #!/bin/sh
 
@@ -391,6 +400,7 @@ If the service should be available to other VMs on the same system, do not forge
 **4. Allow packets into the qube to reach the service**
 
 No routing is required in the destination qube, only filtering.
+
 For the following example, we assume that the target VM running the web server has the IP address 10.137.0.xx
 
 The according rule to allow the traffic is:
@@ -399,7 +409,7 @@ The according rule to allow the traffic is:
 nft add rule qubes custom-input tcp dport 443 ip daddr 10.137.0.xx counter accept
 ```
 
-To make it persistent, you need to add this command in `/rw/config/rc.local`:
+To make it persistent, you need to add this command in the script `/rw/config/rc.local`:
 
 ```
 [user@qubeDEST user]$ sudo -i

From 0dbafca889e6fb03446eb44c5b025a77e2da9075 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sol=C3=A8ne=20Rapenne?= <solene@perso.pw>
Date: Fri, 3 Nov 2023 15:03:14 +0100
Subject: [PATCH 046/332] doc: firewall: example port is 443

---
 user/security-in-qubes/firewall.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index e4ab0f0d..fad87eaa 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -433,10 +433,10 @@ Sometimes these logs can contain useful information about errors that are preven
 
 An effective console utility to troubleshoot network is [tcpdump](https://www.tcpdump.org/), it can be used to display network packets entering or leaving network interfaces.
 
-For instance, if you want to check if your network interface `eth0` is receiving packets on port TCP 22 from the network 192.168.x.y, you can run this command:
+For instance, if you want to check if your network interface `eth0` is receiving packets on port TCP 443 from the network 192.168.x.y, you can run this command:
 
 ```
-tcpdump -i eth0 -nn dst port 22 and src net 192.168.x.y/24
+tcpdump -i eth0 -nn dst port 443 and src net 192.168.x.y/24
 ```
 
 This can be used effectively in a destination qube and its Network VM to see if forwarding / NAT rules are working.

From aa4442d023ca8a001fc3eb979fee38d112ea4965 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sol=C3=A8ne=20Rapenne?= <solene@perso.pw>
Date: Fri, 3 Nov 2023 15:03:25 +0100
Subject: [PATCH 047/332] doc: firewall: add conntrack support

---
 user/security-in-qubes/firewall.md | 32 +++++++++++++++---------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index fad87eaa..a58f0102 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -106,13 +106,13 @@ In order to allow networking from qube A (client) to qube B (server) follow thes
 - In the firewall VM's terminal enter the following nftables rule:
 
 ~~~
-sudo nft add rule ip qubes custom-forward ip saddr <IP address of A> ip daddr <IP address of B> accept
+sudo nft add rule ip qubes custom-forward ip saddr <IP address of A> ip daddr <IP address of B> ct state new,established,related counter accept
 ~~~
 
 - In qube B's terminal enter the following nftables rule:
 
 ~~~
-sudo nft add rule qubes custom-input ip saddr <IP address of A> accept
+sudo nft add rule qubes custom-input ip saddr <IP address of A> ct state new,established,related counter accept
 ~~~
 
 - Now you should be able to reach B from A -- test it using e.g. ping issued from A.
@@ -124,7 +124,7 @@ sudo nft add rule qubes custom-input ip saddr <IP address of A> accept
 
 ~~~
 [user@sys-firewall ~]$ sudo -i
-[root@sys-firewall user]# echo "nft add rule ip qubes custom-forward ip saddr 10.137.2.25 ip daddr 10.137.2.6 accept" >> /rw/config/qubes-firewall-user-script
+[root@sys-firewall user]# echo "nft add rule ip qubes custom-forward ip saddr 10.137.2.25 ip daddr 10.137.2.6 ct state new,established,related counter accept" >> /rw/config/qubes-firewall-user-script
 ~~~
 
 - Here is an example how to update `rc.local`:
@@ -287,13 +287,13 @@ nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority fi
 Second step, code a natting firewall rule to route traffic on the outside interface for the service to the sys-firewall VM
 
 ```
-nft add rule qubes custom-dnat-qubeDEST iifname == "ens6" ip saddr 192.168.x.y/24 tcp dport 443 counter dnat 10.137.1.z
+nft add rule qubes custom-dnat-qubeDEST iifname == "ens6" ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
 ```
 
 Third step, code the appropriate new filtering firewall rule to allow new connections for the service
 
 ```
-nft add rule qubes custom-forward iifname == "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 counter accept
+nft add rule qubes custom-forward iifname == "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
 ```
 
 > Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
@@ -310,12 +310,12 @@ In this example, we can see 7 packets in the forward rule, and 3 packets in the
 
 ```
 chain custom-forward {
-  iifname "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 counter packets 7 bytes 448 accept
+  iifname "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter packets 7 bytes 448 accept
 }
 
 chain custom-dnat-qubeDEST {
   type nat hook prerouting priority filter + 1; policy accept;
-  iifname "ens6" ip saddr 192.168.x.y/24 tcp dport 443 counter packets 3 bytes 192 dnat to 10.138.33.59
+  iifname "ens6" ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter packets 3 bytes 192 dnat to 10.138.33.59
 }
 ```
 
@@ -341,10 +341,10 @@ Content of `/rw/config/qubes-firewall-user-script` in `sys-net`:
 if nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
 then
   # create the dnat rule
-  nft add rule qubes custom-dnat-qubeDEST iifname == "ens6" saddr 192.168.x.y/24 tcp dport 443 counter dnat 10.137.1.z
+  nft add rule qubes custom-dnat-qubeDEST iifname == "ens6" saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
 
   # allow forwarded traffic
-  nft add rule qubes custom-forward iifname == "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 counter accept
+  nft add rule qubes custom-forward iifname == "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
 fi
 ~~~
 
@@ -361,13 +361,13 @@ nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority fi
 Second step, code a natting firewall rule to route traffic on the outside interface for the service to the destination qube
 
 ```
-nft add rule qubes custom-dnat-qubeDEST iifname == "eth0" ip saddr 192.168.x.y/24 tcp dport 443 counter dnat 10.137.0.xx
+nft add rule qubes custom-dnat-qubeDEST iifname == "eth0" ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.0.xx
 ```
 
 Third step, code the appropriate new filtering firewall rule to allow new connections for the service
 
 ```
-nft add rule qubes custom-forward iifname == "eth0" ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 counter accept
+nft add rule qubes custom-forward iifname == "eth0" ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
 ```
 
 > Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
@@ -388,10 +388,10 @@ Content of `/rw/config/qubes-firewall-user-script` in `sys-firewall`:
 if nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
 then
   # create the dnat rule
-  nft add rule qubes custom-dnat-qubeDEST iifname == "eth0" tcp dport 22 counter dnat 10.137.0.xx
+  nft add rule qubes custom-dnat-qubeDEST iifname == "eth0" tcp dport 443 ct state new,established,related counter dnat 10.137.0.xx
 
   # allow forwarded traffic
-  nft add rule qubes custom-forward iifname == "eth0" ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 22 counter accept
+  nft add rule qubes custom-forward iifname == "eth0" ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
 fi
 ~~~
 
@@ -406,14 +406,14 @@ For the following example, we assume that the target VM running the web server h
 The according rule to allow the traffic is:
 
 ```
-nft add rule qubes custom-input tcp dport 443 ip daddr 10.137.0.xx counter accept
+nft add rule qubes custom-input tcp dport 443 ip daddr 10.137.0.xx ct state new,established,related counter accept
 ```
 
 To make it persistent, you need to add this command in the script `/rw/config/rc.local`:
 
 ```
 [user@qubeDEST user]$ sudo -i
-[root@qubeDEST user]# echo 'nft add rule qubes custom-input tcp dport 443 ip daddr 10.137.0.xx counter accept' >> /rw/config/rc.local
+[root@qubeDEST user]# echo 'nft add rule qubes custom-input tcp dport 443 ip daddr 10.137.0.xx ct state new,established,related counter accept' >> /rw/config/rc.local
 ```
 
 This time testing should allow connectivity to the service as long qubeDEST is running and the service is up :-)
@@ -460,4 +460,4 @@ You can revert to the original ruleset with the following commands:
 
 ```
 nft flush ruleset && nft -f nft_backup
-```
\ No newline at end of file
+```

From 718a380ccfa4a513aa34b2ce48a1950832be5fd1 Mon Sep 17 00:00:00 2001
From: gordon-shumway-net
 <60302611+gordon-shumway-net@users.noreply.github.com>
Date: Sun, 5 Nov 2023 00:07:02 +0100
Subject: [PATCH 048/332] Apply suggestions from first code review
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Marta Marczykowska-Górecka <marmarta@users.noreply.github.com>
---
 user/how-to-guides/how-to-use-disposables.md | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/user/how-to-guides/how-to-use-disposables.md b/user/how-to-guides/how-to-use-disposables.md
index 2778d2ff..d13c467b 100644
--- a/user/how-to-guides/how-to-use-disposables.md
+++ b/user/how-to-guides/how-to-use-disposables.md
@@ -24,19 +24,25 @@ This diagram provides a general example of how disposables can be used to safely
 
 ## Named disposables and disposable templates
 
-There is a difference between [named disposables](/doc/glossary/#named-disposable) and [disposable templates](/doc/glossary/#disposable-template).
+There is a difference between [named disposable qubes](/doc/glossary/#named-disposable) and [disposable templates](/doc/glossary/#disposable-template).
 
-In a default QubesOS Installation, you would probably use the 'whonix-ws-16-dvm' if you, as an example, want to browse the Tor network with an disposable. Every application starts a new random disposable with an ID in the name and if you close the window, it shuts down the qube. This is the feeling of an disposable template.
+In a default QubesOS Installation, you would probably use the 'whonix-ws-16-dvm' disposable template to, for example, browse the Tor network with an disposable qube. Every time you start an application using this disposable template, a new disposable qube - named `dispX` (where X is a random number) starts. If you close the application window, the `dispX` qube shuts down and vanished from your system. That is how disposable templates are used.
 
 In named disposables every application starts in the same qube, the qube itself has a fixed name and you need to manually shutdown the qube. Except from the non-persistance, they feel like usual app qubes. Named disposables are built upon disposable templates.
 
 ### How to create disposable templates
 
-First you need to create an app qube. After that you need to go to the 'Qubes Settings' of the created app qube and set it as a 'Disposable template' in the 'Advanced' section and apply the change. From now on the entry in the Application menu is not named 'Qube' anymore, but splitted into 'Disposable' and 'Template (disp)'. The settings for the disposable can be changed under **'Application Menu -> Template (disp) -> Template: Qubes Settings**
+First, you need to create an app qube. You can run it normally, set up any necessary settings (like browser settings) you wish to be applied to every disposable qube ran from this template. Next, go to 'Qube Settings' of the app qube, set it as a _Disposable template_ in the _Advanced_ section and apply the change. 
+
+In Qubes 4.1, from now on, the entry in the Application menu is not named 'Qube' anymore, but split into 'Disposable' and 'Template (disp)'. The settings for the disposable can be changed under **'Application Menu -> Template (disp) -> Template: Qubes Settings**
+
+In Qubes 4.2, the qube will now appear in the menu as a disposable template (in the Apps section), from which you can launch new disposable qubes. To change the settings of the template itself or run programs in it, use the menu position for this qube located in the Templates section.
 
 ### How to create named disposables
 
-Named disposables can be created under **Application Menu -> Create Qubes VM**, the type needs to be 'DisposableVM'.
+In Qubes 4.1: named disposables can be created under **Application Menu -> Create Qubes VM**, set the qube type  to be _DisposableVM_.
+
+In Qubes 4.2: named disposables can be created by **Application Menu -> Settings -> Qubes Settings -> Create New Qube**. Set the qube type to _Named disposable_
 
 ## Security
 

From 86a6f12e2a882dfffbc04818458589655843514d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sol=C3=A8ne=20Rapenne?= <solene@perso.pw>
Date: Mon, 6 Nov 2023 09:04:16 +0100
Subject: [PATCH 049/332] doc: firewall: use iif instead of iifname for better
 performance

---
 user/security-in-qubes/firewall.md | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index a58f0102..b4eb1b65 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -287,13 +287,13 @@ nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority fi
 Second step, code a natting firewall rule to route traffic on the outside interface for the service to the sys-firewall VM
 
 ```
-nft add rule qubes custom-dnat-qubeDEST iifname == "ens6" ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
+nft add rule qubes custom-dnat-qubeDEST iif == "ens6" ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
 ```
 
 Third step, code the appropriate new filtering firewall rule to allow new connections for the service
 
 ```
-nft add rule qubes custom-forward iifname == "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
+nft add rule qubes custom-forward iif == "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
 ```
 
 > Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
@@ -310,12 +310,12 @@ In this example, we can see 7 packets in the forward rule, and 3 packets in the
 
 ```
 chain custom-forward {
-  iifname "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter packets 7 bytes 448 accept
+  iif "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter packets 7 bytes 448 accept
 }
 
 chain custom-dnat-qubeDEST {
   type nat hook prerouting priority filter + 1; policy accept;
-  iifname "ens6" ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter packets 3 bytes 192 dnat to 10.138.33.59
+  iif "ens6" ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter packets 3 bytes 192 dnat to 10.138.33.59
 }
 ```
 
@@ -341,10 +341,10 @@ Content of `/rw/config/qubes-firewall-user-script` in `sys-net`:
 if nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
 then
   # create the dnat rule
-  nft add rule qubes custom-dnat-qubeDEST iifname == "ens6" saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
+  nft add rule qubes custom-dnat-qubeDEST iif == "ens6" saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
 
   # allow forwarded traffic
-  nft add rule qubes custom-forward iifname == "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
+  nft add rule qubes custom-forward iif == "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
 fi
 ~~~
 
@@ -361,13 +361,13 @@ nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority fi
 Second step, code a natting firewall rule to route traffic on the outside interface for the service to the destination qube
 
 ```
-nft add rule qubes custom-dnat-qubeDEST iifname == "eth0" ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.0.xx
+nft add rule qubes custom-dnat-qubeDEST iif == "eth0" ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.0.xx
 ```
 
 Third step, code the appropriate new filtering firewall rule to allow new connections for the service
 
 ```
-nft add rule qubes custom-forward iifname == "eth0" ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
+nft add rule qubes custom-forward iif == "eth0" ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
 ```
 
 > Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
@@ -388,10 +388,10 @@ Content of `/rw/config/qubes-firewall-user-script` in `sys-firewall`:
 if nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
 then
   # create the dnat rule
-  nft add rule qubes custom-dnat-qubeDEST iifname == "eth0" tcp dport 443 ct state new,established,related counter dnat 10.137.0.xx
+  nft add rule qubes custom-dnat-qubeDEST iif == "eth0" tcp dport 443 ct state new,established,related counter dnat 10.137.0.xx
 
   # allow forwarded traffic
-  nft add rule qubes custom-forward iifname == "eth0" ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
+  nft add rule qubes custom-forward iif == "eth0" ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
 fi
 ~~~
 

From e95c51f58268e520c36152a3c037323889729291 Mon Sep 17 00:00:00 2001
From: deeplow <47065258+deeplow@users.noreply.github.com>
Date: Thu, 9 Nov 2023 03:20:40 -0500
Subject: [PATCH 050/332] Clean Install: change Qubes sources to 4.2

Tell users to upgrade the software sources. Otherwise they may miss
on critical integrations for 4.2 like VMExec (for the updater to work)
and most importantly, after 4.1 is EOL, it'll silently stop resolving
qubes package upgrades even though the template is not yet EOL.
---
 user/downloading-installing-upgrading/upgrade/4_2.md | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/user/downloading-installing-upgrading/upgrade/4_2.md b/user/downloading-installing-upgrading/upgrade/4_2.md
index 84cf80ef..74e1efa5 100644
--- a/user/downloading-installing-upgrading/upgrade/4_2.md
+++ b/user/downloading-installing-upgrading/upgrade/4_2.md
@@ -31,6 +31,16 @@ in-place:
 4. [Restore from your
    backup](/doc/how-to-back-up-restore-and-migrate/#restoring-from-a-backup) on
    your new 4.2 installation.
+5. In each old the old templates update the Qubes software sources from 4.1 to Qubes 4.2. Do this by opening a teminal in each of the imported templates and running the following commands:
+   - **Debian-based templates**:
+     ```
+     sudo sed -i 's/r4.[01]/r4.2/g' /etc/apt/sources.list.d/qubes-r4.list`
+     ```
+   - **Fedora-based templates**: 
+     ```
+     sudo sed -i 's/r4.[01]/r4.2/g' /etc/yum.repos.d/qubes-r4.repo
+     sudo sed -i 's/RPM-GPG-KEY-qubes-4\(\.1\)\{0,1\}-primary/RPM-GPG-KEY-qubes-4.2-primary/g' /etc/yum.repos.d/qubes-r4.repo
+     ```
 
 ## In-place upgrade
 

From d439baef30ee900f60434758c24dcc89132f94a1 Mon Sep 17 00:00:00 2001
From: deeplow <deeplower@protonmail.com>
Date: Thu, 9 Nov 2023 09:39:48 +0000
Subject: [PATCH 051/332] Upgrade also GPG keyring for "-unstable" repos

---
 user/downloading-installing-upgrading/upgrade/4_2.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/downloading-installing-upgrading/upgrade/4_2.md b/user/downloading-installing-upgrading/upgrade/4_2.md
index 74e1efa5..0f94671e 100644
--- a/user/downloading-installing-upgrading/upgrade/4_2.md
+++ b/user/downloading-installing-upgrading/upgrade/4_2.md
@@ -39,7 +39,7 @@ in-place:
    - **Fedora-based templates**: 
      ```
      sudo sed -i 's/r4.[01]/r4.2/g' /etc/yum.repos.d/qubes-r4.repo
-     sudo sed -i 's/RPM-GPG-KEY-qubes-4\(\.1\)\{0,1\}-primary/RPM-GPG-KEY-qubes-4.2-primary/g' /etc/yum.repos.d/qubes-r4.repo
+     sudo sed -i 's/RPM-GPG-KEY-qubes-4\(\.1\)\{0,1\}-/RPM-GPG-KEY-qubes-4.2-/g' /etc/yum.repos.d/qubes-r4.repo
      ```
 
 ## In-place upgrade

From 2b3fa9b1146765181c8722b00a6719c870a9c39e Mon Sep 17 00:00:00 2001
From: deeplow <deeplower@protonmail.com>
Date: Thu, 9 Nov 2023 10:32:31 +0000
Subject: [PATCH 052/332] Add new keyring to Debian templates

---
 user/downloading-installing-upgrading/upgrade/4_2.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/user/downloading-installing-upgrading/upgrade/4_2.md b/user/downloading-installing-upgrading/upgrade/4_2.md
index 0f94671e..a80ff90d 100644
--- a/user/downloading-installing-upgrading/upgrade/4_2.md
+++ b/user/downloading-installing-upgrading/upgrade/4_2.md
@@ -34,7 +34,8 @@ in-place:
 5. In each old the old templates update the Qubes software sources from 4.1 to Qubes 4.2. Do this by opening a teminal in each of the imported templates and running the following commands:
    - **Debian-based templates**:
      ```
-     sudo sed -i 's/r4.[01]/r4.2/g' /etc/apt/sources.list.d/qubes-r4.list`
+     sudo sed -i 's/r4.[01]/r4.2/g' /etc/apt/sources.list.d/qubes-r4.list
+     sudo sed -i 's|\[arch=amd64\]|\[arch=amd64 signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg \]|g' /etc/apt/sources.list.d/qubes-r4.list
      ```
    - **Fedora-based templates**: 
      ```

From 207b5e501958b7c121a8f02860e2f3f73134f9b4 Mon Sep 17 00:00:00 2001
From: deeplow <deeplower@protonmail.com>
Date: Thu, 9 Nov 2023 10:44:19 +0000
Subject: [PATCH 053/332] Note that upgrades repo upgrades apply only to 4.1+

At noted by Marek [1] GPG keyrings for verifying 4.1+ packages only
started being available in 4.1 templates. Telling people to fetch
the keyrings through another method would make instructions too
complicated. For this reason it seems simpler to just tell people to
use the new templates instead.

[1]: https://github.com/QubesOS/qubes-doc/pull/1345#issuecomment-1803517947
---
 .../upgrade/4_2.md                            | 21 ++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/user/downloading-installing-upgrading/upgrade/4_2.md b/user/downloading-installing-upgrading/upgrade/4_2.md
index a80ff90d..058d481b 100644
--- a/user/downloading-installing-upgrading/upgrade/4_2.md
+++ b/user/downloading-installing-upgrading/upgrade/4_2.md
@@ -31,16 +31,27 @@ in-place:
 4. [Restore from your
    backup](/doc/how-to-back-up-restore-and-migrate/#restoring-from-a-backup) on
    your new 4.2 installation.
-5. In each old the old templates update the Qubes software sources from 4.1 to Qubes 4.2. Do this by opening a teminal in each of the imported templates and running the following commands:
+5. In each old the old templates update the Qubes software sources from 4.1 to Qubes 4.2.
+   > **Note**: If the templates were first installed on a version older than
+   > Qubes 4.1, you should reinstall them. For example, your first Qubes install
+   > was 4.0 and you've been upgrading to Qubes 4.2 via clean install ever since,
+   > then this affects you and you should instead use the templates that come
+   > preinstalled in 4.2.
+
+   If the above note does not apply, you should open a teminal in each of the
+   imported templates and running the following commands:
    - **Debian-based templates**:
      ```
-     sudo sed -i 's/r4.[01]/r4.2/g' /etc/apt/sources.list.d/qubes-r4.list
+     sudo sed -i 's/r4.1/r4.2/g' /etc/apt/sources.list.d/qubes-r4.list
      sudo sed -i 's|\[arch=amd64\]|\[arch=amd64 signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg \]|g' /etc/apt/sources.list.d/qubes-r4.list
+     sudo apt update
+     sudo apt upgrade
      ```
-   - **Fedora-based templates**: 
+   - **Fedora-based templates**:
      ```
-     sudo sed -i 's/r4.[01]/r4.2/g' /etc/yum.repos.d/qubes-r4.repo
-     sudo sed -i 's/RPM-GPG-KEY-qubes-4\(\.1\)\{0,1\}-/RPM-GPG-KEY-qubes-4.2-/g' /etc/yum.repos.d/qubes-r4.repo
+     sudo sed -i 's/r4.1/r4.2/g' /etc/yum.repos.d/qubes-r4.repo
+     sudo sed -i 's/RPM-GPG-KEY-qubes-4.1-/RPM-GPG-KEY-qubes-4.2-/g' /etc/yum.repos.d/qubes-r4.repo
+     sudo dnf update
      ```
 
 ## In-place upgrade

From 6810e4b8ffa70b51acce3bd3afe9ac25f789f58e Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Thu, 16 Nov 2023 03:15:00 -0800
Subject: [PATCH 054/332] Add Star Labs StarBook to certified hardware list

---
 user/hardware/certified-hardware.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/user/hardware/certified-hardware.md b/user/hardware/certified-hardware.md
index 315de5a1..d1035497 100644
--- a/user/hardware/certified-hardware.md
+++ b/user/hardware/certified-hardware.md
@@ -61,6 +61,12 @@ The [NovaCustom NV41 Series](https://configurelaptop.eu/nv41-series/) is a 14-in
 
 The [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523) is a desktop based on the MSI PRO Z690-A DDR5 motherboard. It is certified for Qubes OS 4.X. Read our [announcement](/news/2023/09/06/nitropc-pro-qubes-certified/) for details.
 
+### Star Labs StarBook
+
+[![Photo of the Star Labs StarBook](/attachment/site/starlabs-starbook.png)](https://starlabs.systems/pages/starbook)
+
+The [Star Labs StarBook](https://starlabs.systems/pages/starbook) is a 14-inch laptop. It is certified for Qubes OS 4.X. Read our [announcement](TODO) for details.
+
 ## Become hardware certified
 
 If you are a hardware vendor, you can have your hardware certified as compatible with Qubes OS. The benefits of hardware certification include:

From 1dfdd626803e5096bca2dbd7d5311daee15b8f67 Mon Sep 17 00:00:00 2001
From: cinderflash <154299375+cinderflash@users.noreply.github.com>
Date: Tue, 19 Dec 2023 23:09:37 -0700
Subject: [PATCH 055/332] Fix all bugs link

The "Issue tracking" page links to a list of all bug reports.
The referenced label `bug` seems to be obsolete.

This patch updates the link to point to the modern `T: bug` label.
Preserves sort order descending by last update.
---
 introduction/issue-tracking.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/introduction/issue-tracking.md b/introduction/issue-tracking.md
index 6bb52803..e550ac40 100644
--- a/introduction/issue-tracking.md
+++ b/introduction/issue-tracking.md
@@ -87,7 +87,7 @@ The issue tracker has several [projects](https://github.com/QubesOS/qubes-issues
 
 ## Search tips
 
-- [Search both open and closed issues.](https://github.com/QubesOS/qubes-issues/issues?utf8=%E2%9C%93&q=is%3Aissue) For example, you may be experiencing a bug that was just fixed, in which case the report for that bug is probably closed. In this case, it would be useful to view [all bug reports, both open and closed, with the most recently updated sorted to the top](https://github.com/QubesOS/qubes-issues/issues?q=label%3Abug+sort%3Aupdated-desc).
+- [Search both open and closed issues.](https://github.com/QubesOS/qubes-issues/issues?utf8=%E2%9C%93&q=is%3Aissue) For example, you may be experiencing a bug that was just fixed, in which case the report for that bug is probably closed. In this case, it would be useful to view [all bug reports, both open and closed, with the most recently updated sorted to the top](https://github.com/QubesOS/qubes-issues/issues?q=label%3A%22T%3A+bug%22+sort%3Aupdated-desc).
 
 - [Search with labels.](https://github.com/QubesOS/qubes-issues/labels) For example, you can search issues by priority ([blocker](https://github.com/QubesOS/qubes-issues/labels/P%3A%20blocker), [critical](https://github.com/QubesOS/qubes-issues/labels/P%3A%20critical), [major](https://github.com/QubesOS/qubes-issues/labels/P%3A%20major), etc.) and by component ([core](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+label%3A%22C%3A+core%22), [manager/widget](https://github.com/QubesOS/qubes-issues/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3A%22C%3A+manager%2Fwidget%22+), [Xen](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+label%3A%22C%3A+Xen%22), etc.).
 

From 8ad2d93e23dd58338ac21128db2ec3dceb224a9f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>
Date: Sat, 11 Nov 2023 23:01:17 +0100
Subject: [PATCH 056/332] Change links to HTTPS

Change links that has HTTPS equivalent to HTTPS.
---
 _dev/conf.py                             | 2 +-
 developer/debugging/windows-debugging.md | 6 +++---
 developer/general/devel-books.md         | 4 ++--
 developer/general/gsoc.md                | 2 +-
 introduction/support.md                  | 4 ++--
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/_dev/conf.py b/_dev/conf.py
index 9f311f45..c643b145 100644
--- a/_dev/conf.py
+++ b/_dev/conf.py
@@ -186,7 +186,7 @@ htmlhelp_basename = 'QubesOSdev'
 
 # Example configuration for intersphinx: refer to the Python standard library.
 intersphinx_mapping = {
-    'python': ('http://docs.python.org/', None),
+    'python': ('https://docs.python.org/', None),
 #   'core-admin': ('https://dev.qubes-os.org/projects/core-admin/en/latest/', None),
 }
 
diff --git a/developer/debugging/windows-debugging.md b/developer/debugging/windows-debugging.md
index 852d1c67..87f22b5a 100644
--- a/developer/debugging/windows-debugging.md
+++ b/developer/debugging/windows-debugging.md
@@ -47,7 +47,7 @@ socat $tty1,raw $tty2,raw
 ...but there is a catch. Xen seems to process the traffic that goes through serial ports and changes all **0x0a** bytes into **0x0d, 0x0a** pairs (newline conversion). I didn't find a way to turn that off (setting ptys to raw mode didn't change anything) and it's not mentioned anywhere on the Internet, so maybe it's something on my system. If the above script works for you then you don't need anything more in dom0.
 
 - On the *target* system, run `bcdedit /set debug on` on the console to turn on kernel debugging. It defaults to the first serial port.
-- On the *host* system, install [WinDbg](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx) and start the kernel debug (Ctrl-K), choose **com1** as the debug port.
+- On the *host* system, install [WinDbg](https://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx) and start the kernel debug (Ctrl-K), choose **com1** as the debug port.
 - Reboot the *target* VM.
 - Run the above shell script in dom0.
 - If everything is fine you should see the proper kernel debugging output in WinDbg. However, if you see something like that:
@@ -57,7 +57,7 @@ socat $tty1,raw $tty2,raw
     Waiting to reconnect...
     Connected to Windows 7 7601 x64 target at (Wed Mar 19 20:35:43.262 2014 (UTC + 1:00)), ptr64 TRUE
     Kernel Debugger connection established.
-    Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols
+    Symbol search path is: srv*c:\symbols*https://msdl.microsoft.com/download/symbols
     Executable search path is:
     ... Retry sending the same data packet for 64 times.
     The transport connection between host kernel debugger and target Windows seems lost.
@@ -206,7 +206,7 @@ parse:
 > Waiting to reconnect...
 > Connected to Windows 7 7601 x64 target at (Wed Mar 19 20:56:31.371 2014 (UTC + 1:00)), ptr64 TRUE
 > Kernel Debugger connection established.
-> Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols
+> Symbol search path is: srv*c:\symbols*https://msdl.microsoft.com/download/symbols
 > Executable search path is:
 > Windows 7 Kernel Version 7601 MP (1 procs) Free x64
 > Built by: 7601.18247.amd64fre.win7sp1_gdr.130828-1532
diff --git a/developer/general/devel-books.md b/developer/general/devel-books.md
index d7ae9ae0..361648ba 100644
--- a/developer/general/devel-books.md
+++ b/developer/general/devel-books.md
@@ -26,6 +26,6 @@ Below is a list of various books that might be useful in learning some basics ne
   - _[Pro Git](https://git-scm.com/book/en/v2)_, by Scott Chacon and Ben Straub (complete book available free online)
 
 - Useful books about Python:
-  - _[Programming in Python 3](http://www.qtrac.eu/py3book.html)_, by Mark Summerfield
-  - _[Rapid GUI Programming with Python and Qt](http://www.qtrac.eu/pyqtbook.html)_, by Mark Summerfield
+  - _[Programming in Python 3](https://www.qtrac.eu/py3book.html)_, by Mark Summerfield
+  - _[Rapid GUI Programming with Python and Qt](https://www.qtrac.eu/pyqtbook.html)_, by Mark Summerfield
     (Although note that [Qt is being replaced by GTK](/doc/usability-ux/#gnome-kde-and-xfce) in Qubes code.)
diff --git a/developer/general/gsoc.md b/developer/general/gsoc.md
index 9e4adad3..e49d66d9 100644
--- a/developer/general/gsoc.md
+++ b/developer/general/gsoc.md
@@ -259,7 +259,7 @@ REMOVED as of January 2020: work is being done on this
 
 **Project**: Unikernel based firewallvm with Qubes firewall settings support
 
-**Brief explanation**: [blog post](http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/), [repo](https://github.com/talex5/qubes-mirage-firewall)
+**Brief explanation**: [blog post](https://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/), [repo](https://github.com/talex5/qubes-mirage-firewall)
 
 **Expected results**: A firewall implemented as a unikernel which supports all the networking-related functionality as the default sys-firewall VM, including configuration via Qubes Manager. Other duties currently assigned to sys-firewall such as the update proxy may need to be appropriately migrated first.
 
diff --git a/introduction/support.md b/introduction/support.md
index 6f495938..ef073184 100644
--- a/introduction/support.md
+++ b/introduction/support.md
@@ -176,7 +176,7 @@ information in your message. A great way to provide your hardware details is by
 [generating and submitting a Hardware Compatibility List (HCL)
 report](/doc/how-to-use-the-hcl/#generating-and-submitting-new-reports), then
 linking to it in your message. [Ask questions the smart
-way.](http://www.catb.org/esr/faqs/smart-questions.html)
+way.](https://www.catb.org/esr/faqs/smart-questions.html)
 
 ### Be patient
 
@@ -309,7 +309,7 @@ account is in no way required, expected, or encouraged. Many discussants
 [mailing lists](https://en.wikipedia.org/wiki/Electronic_mailing_list),
 interacting with them solely through plain text email with
 [MUAs](https://en.wikipedia.org/wiki/Email_client) like
-[Thunderbird](https://www.thunderbird.net/) and [Mutt](http://www.mutt.org/).
+[Thunderbird](https://www.thunderbird.net/) and [Mutt](https://www.mutt.org/).
 The Google Groups service is just free infrastructure, and we [distrust the
 infrastructure](/faq/#what-does-it-mean-to-distrust-the-infrastructure). This
 is why, for example, we encourage discussants to use [Split

From 0b342d3ed8e92c30555486d4231fe4a3fc75f94b Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Thu, 21 Dec 2023 00:48:17 +0000
Subject: [PATCH 057/332] Copy old firewall.md page to firewall_4.1.md for
 continued support 4.1

---
 user/security-in-qubes/firewall_4.1.md | 513 +++++++++++++++++++++++++
 1 file changed, 513 insertions(+)
 create mode 100644 user/security-in-qubes/firewall_4.1.md

diff --git a/user/security-in-qubes/firewall_4.1.md b/user/security-in-qubes/firewall_4.1.md
new file mode 100644
index 00000000..5c00c9f9
--- /dev/null
+++ b/user/security-in-qubes/firewall_4.1.md
@@ -0,0 +1,513 @@
+---
+lang: en
+layout: doc
+permalink: /doc/firewall_4.1/
+redirect_from:
+ref: 401
+title: Firewall 4.1
+---
+
+Introduction
+----------------------------------
+This page explains use of the firewall in Qubes 4.1, using `iptables`.  
+From Qubes 4.2, all firewall components use `nftables`. For details of that usage see [here](../firewall/)
+
+
+Understanding firewalling in Qubes
+----------------------------------
+
+Every qube in Qubes is connected to the network via a FirewallVM, which is used to enforce network-level policies.
+By default there is one default FirewallVM, but the user is free to create more, if needed.
+
+For more information, see the following:
+
+- [https://groups.google.com/group/qubes-devel/browse\_thread/thread/9e231b0e14bf9d62](https://groups.google.com/group/qubes-devel/browse_thread/thread/9e231b0e14bf9d62)
+- [https://blog.invisiblethings.org/2011/09/28/playing-with-qubes-networking-for-fun.html](https://blog.invisiblethings.org/2011/09/28/playing-with-qubes-networking-for-fun.html)
+
+How to edit rules
+-----------------
+
+In order to edit rules for a given qube, select it in the Qube Manager and press the "firewall" button.
+
+![r4.0-manager-firewall.png](/attachment/doc/r4.0-manager-firewall.png)
+
+If the qube is running, you can open Settings from the Qube Popup Menu.
+
+*R4.0 note:* ICMP and DNS are no longer accessible in the GUI, but can be changed via `qvm-firewall` described below.
+Connections to Updates Proxy are not made over a network so can not be allowed or blocked with firewall rules, but are controlled using the relevant policy file (see [R4.0 Updates proxy](/doc/software-update-vm/) for more detail).
+
+Note that if you specify a rule by DNS name it will be resolved to IP(s) *at the moment of applying the rules*, and not on the fly for each new connection.
+This means it will not work for servers using load balancing, and traffic to complex web sites which draw from many servers will be difficult to control.
+
+Instead of using the firewall GUI, you can use the `qvm-firewall` command in Dom0 to edit the firewall rules by hand.
+This gives you greater control than by using the GUI.
+
+The firewall rules for each qube are saved in an XML file in that qube's directory in dom0:
+
+```
+/var/lib/qubes/appvms/<vm-name>/firewall.xml
+```
+
+Rules are implemented on the netvm.
+
+You can also manually create rules in the qube itself using standard firewalling controls.
+See [Where to put firewall rules](#where-to-put-firewall-rules).
+In complex cases, it might be appropriate to load a ruleset using `iptables-restore` called from `/rw/config/rc.local`.
+if you do this, be aware that `rc.local` is called *after* the network is up, so local rules should not be relied upon to block leaks.
+
+Reconnecting qubes after a NetVM reboot
+-------------------------------------
+
+Normally Qubes doesn't let the user stop a NetVM if there are other qubes running which use it as their own NetVM.
+But in case the NetVM stops for whatever reason (e.g. it crashes, or the user forces its shutdown via qvm-kill via terminal in Dom0), Qubes R4.0 will often automatically repair the connection.
+If it does not, then there is an easy way to restore the connection to the NetVM by issuing in dom0:
+
+` qvm-prefs <vm> netvm <netvm> `
+
+Normally qubes do not connect directly to the actual NetVM which has networking devices, but rather to the default sys-firewall first, and in most cases it would be the NetVM that will crash, e.g. in response to S3 sleep/restore or other issues with WiFi drivers.
+In that case it is only necessary to issue the above command once, for the sys-firewall (this assumes default VM-naming used by the default Qubes installation):
+
+` qvm-prefs sys-firewall netvm sys-net `
+
+Network service qubes
+---------------------
+
+Qubes does not support running any networking services (e.g. VPN, local DNS server, IPS, ...) directly in a qube that is used to run the Qubes firewall service (usually sys-firewall) for good reasons.
+In particular, if you want to ensure proper functioning of the Qubes firewall, you should not tinker with iptables or nftables rules in such qubes.
+
+Instead, you should deploy a network infrastructure such as
+
+~~~
+sys-net <--> sys-firewall-1 <--> network service qube <--> sys-firewall-2 <--> [client qubes]
+~~~
+
+Thereby sys-firewall-1 is only needed if you have other client qubes connected there, or you want to manage the traffic of the local network service qube.
+The sys-firewall-2 proxy ensures that:
+
+1. Firewall changes done in the network service qube cannot render the Qubes firewall ineffective.
+2. Changes to the Qubes firewall by the Qubes maintainers cannot lead to unwanted information leakage in combination with user rules deployed in the network service qube.
+3. A compromise of the network service qube does not compromise the Qubes firewall.
+
+If you adopt this model, you should be aware that all traffic will arrive at the `network service qube` appearing to originate from the IP address of `sys-firewall-2`.
+
+For the VPN service please also look at the [VPN documentation](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md).
+
+Enabling networking between two qubes
+-------------------------------------
+
+Normally any networking traffic between qubes is prohibited for security reasons.
+However, in special situations, you might want to selectively allow specific qubes to establish networking connectivity between each other.
+For example, this might be useful in some development work, when you want to test networking code, or to allow file exchange between HVM domains (which do not have Qubes tools installed) via SMB/scp/NFS protocols.
+
+In order to allow networking between qubes A and B follow these steps:
+
+- Make sure both A and B are connected to the same firewall vm (by default all VMs use the same firewall VM).
+- Note the Qubes IP addresses assigned to both qubes.
+  This can be done using the `qvm-ls -n` command, or via the Qubes Manager preferences pane for each qube.
+- Start both qubes, and also open a terminal in the firewall VM
+- In the firewall VM's terminal enter the following iptables rule:
+
+~~~
+sudo iptables -I FORWARD 2 -s <IP address of A> -d <IP address of B> -j ACCEPT
+~~~
+
+- In qube B's terminal enter the following iptables rule:
+
+~~~
+sudo iptables -I INPUT -s <IP address of A> -j ACCEPT
+~~~
+
+- Now you should be able to reach B from A -- test it using e.g. ping issued from A.
+  Note however, that this doesn't allow you to reach A from B -- for this you would need two more rules, with A and B swapped.
+- If everything works as expected, then you should write the above iptables rules into firewallVM's `qubes-firewall-user-script` script.
+  This script is run when the netvm starts up.
+  You should also write relevant rules in A and B's `rc.local` script which is run when the qube is launched.
+  Here's an example how to update the script:
+
+~~~
+[user@sys-firewall ~]$ sudo bash
+[root@sys-firewall user]# echo "iptables -I FORWARD 2 -s 10.137.2.25 -d 10.137.2.6 -j ACCEPT" >> /rw/config/qubes-firewall-user-script
+[root@sys-firewall user]# chmod +x /rw/config/qubes-firewall-user-script
+~~~
+
+- Here is an example how to update `rc.local`:
+
+~~~
+[user@B ~]$ sudo bash
+[root@B user]# echo "iptables -I INPUT -s 10.137.2.25 -j ACCEPT" >> /rw/config/rc.local
+[root@B user]# chmod +x /rw/config/rc.local
+~~~
+
+Opening a single TCP port to other network-isolated qube
+--------------------------------------------------------
+
+In the case where a specific TCP port needs to be exposed from a qubes to another one, you do not need to enable networking between them but you can use the qubes RPC service `qubes.ConnectTCP`.
+
+**1. Simple port binding**
+
+Consider the following example. `mytcp-service` qube has a TCP service running on port `444` and `untrusted` qube needs to access this service.
+
+- In dom0, add the following to `/etc/qubes/policy.d/30-user-networking.policy`: (it could be `another-other-name.policy` -- just remember to keep it consistent)
+
+    ~~~
+    qubes.ConnectTCP * untrusted @default allow target=mytcp-service
+    ~~~
+
+- In untrusted, use the Qubes tool `qvm-connect-tcp`:
+
+    ~~~
+    [user@untrusted #]$ qvm-connect-tcp 444:@default:444
+    ~~~
+
+> Note: The syntax is the same as SSH tunnel handler. The first `444` correspond to the localport destination of `untrusted`, `@default` the remote machine and the second `444` to the remote machine port.
+
+The service of `mytcp-service` running on port `444` is now accessible in `untrusted` as `localhost:444`.
+
+Here `@default` is used to hide the destination qube which is specified in the Qubes RPC policy by `target=mytcp-service`. Equivalent call is to use the tool as follow:
+
+~~~
+  [user@untrusted #]$ qvm-connect-tcp ::444
+~~~
+
+which means to use default local port of `unstrusted` as the same of the remote port and unspecified destination qube is `@default` by default in `qrexec` call.
+
+**2. Binding remote port on another local port**
+
+Consider now the case where someone prefers to specify the destination qube and use another port in untrusted, for example `10044`. Instead of previous case, add
+
+~~~
+qubes.ConnectTCP * untrusted mytcp-service allow
+~~~
+
+in `/etc/qubes/policy.d/30-user-networking.policy` and in untrusted, use the tool as follow:
+
+~~~
+  [user@untrusted #]$ qvm-connect-tcp 10444:mytcp-service:444
+~~~
+
+The service of `mytcp-service` running on port `444` is now accessible in `untrusted` as `localhost:10444`.
+
+**3. Binding to different qubes using RPC policies**
+
+One can go further than the previous examples by redirecting different ports to different qubes. For example, let assume that another qube `mytcp-service-bis` with a TCP service is running on port `445`. If someone wants `untrusted` to be able to reach this service but port `445` is reserved to `mytcp-service-bis` then, in dom0, add the following to `/etc/qubes/policy.d/30-user-networking.policy`:
+
+~~~
+qubes.ConnectTCP +445 untrusted @default allow target=mytcp-service-bis
+~~~
+
+In that case, calling `qvm-connect-tcp` like previous examples, will still bind TCP port `444` of `mytcp-service` to `untrusted` but now, calling it with port `445`
+
+~~~
+  [user@untrusted #]$ qvm-connect-tcp ::445
+~~~
+
+will restrict the binding to only the corresponding TCP port of `mytcp-service-bis`.
+
+**4. Permanent port binding**
+
+For creating a permanent port bind between two qubes, `systemd` can be used. We use the case of the first example. In `/rw/config` (or any place you find suitable) of qube `untrusted`, create `my-tcp-service.socket` with content:
+
+~~~
+[Unit]
+Description=my-tcp-service
+
+[Socket]
+ListenStream=127.0.0.1:444
+Accept=true
+
+[Install]
+WantedBy=sockets.target
+~~~
+
+and `my-tcp-service@.service` with content:
+
+~~~
+[Unit]
+Description=my-tcp-service
+
+[Service]
+ExecStart=qrexec-client-vm '' qubes.ConnectTCP+444
+StandardInput=socket
+StandardOutput=inherit
+~~~
+
+In `/rw/config/rc.local`, append the lines:
+
+~~~
+cp -r /rw/config/my-tcp-service.socket /rw/config/my-tcp-service@.service /lib/systemd/system/
+systemctl daemon-reload
+systemctl start my-tcp-service.socket
+~~~
+
+When the qube `unstrusted` has started (after a first reboot), you can directly access the service of `mytcp-service` running on port `444` as `localhost:444`.
+
+Port forwarding to a qube from the outside world
+------------------------------------------------
+
+In order to allow a service present in a qube to be exposed to the outside world in the default setup (where the qube has sys-firewall as network VM, which in turn has sys-net as network VM) the following needs to be done:
+
+- In the sys-net VM:
+  - Route packets from the outside world to the sys-firewall VM
+  - Allow packets through the sys-net VM firewall
+- In the sys-firewall VM:
+  - Route packets from the sys-net VM to the VM
+  - Allow packets through the sys-firewall VM firewall
+- In the qube:
+  - Allow packets through the qube firewall to reach the service
+
+As an example we can take the use case of a web server listening on port 443 that we want to expose on our physical interface eth0, but only to our local network 192.168.x.0/24.
+
+> Note: To have all interfaces available and configured, make sure the 3 qubes are up and running
+
+> Note: [Issue #4028](https://github.com/QubesOS/qubes-issues/issues/4028) discusses adding a command to automate exposing the port.
+
+**1. Identify the IP addresses you will need to use for sys-net, sys-firewall and the destination qube.**
+
+You can get this information from the Settings Window for the qube, or by running this command in each qube:
+`ifconfig | grep -i cast `
+Note the IP addresses you will need.
+> Note: The vifx.0 interface is the one used by qubes connected to this netvm so it is _not_ an outside world interface.
+
+**2. Route packets from the outside world to the FirewallVM**
+
+For the following example, we assume that the physical interface eth0 in sys-net has the IP address 192.168.x.y and that the IP address of sys-firewall is 10.137.1.z.
+
+In the sys-net VM's Terminal, code a natting firewall rule to route traffic on the outside interface for the service to the sys-firewall VM
+
+```
+iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.x.y -j DNAT --to-destination 10.137.1.z
+```
+
+Code the appropriate new filtering firewall rule to allow new connections for the service
+
+```
+iptables -I FORWARD 2 -i eth0 -d 10.137.1.z -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
+```
+
+> If you want to expose the service on multiple interfaces, repeat the steps described in part 1 for each interface.
+> In Qubes R4, at the moment ([QubesOS/qubes-issues#3644](https://github.com/QubesOS/qubes-issues/issues/3644)), nftables is also used which imply that additional rules need to be set in a `qubes-firewall` nft table with a forward chain.
+
+`nft add rule ip qubes-firewall forward meta iifname eth0 ip daddr 10.137.1.z tcp dport 443 ct state new counter accept`
+
+Verify you are cutting through the sys-net VM firewall by looking at its counters (column 2)
+
+```
+iptables -t nat -L -v -n
+iptables -L -v -n
+```
+
+> Note: On Qubes R4, you can also check the nft counters
+
+```
+nft list table ip qubes-firewall
+```
+
+Send a test packet by trying to connect to the service from an external device
+
+```
+telnet 192.168.x.y 443
+```
+
+Once you have confirmed that the counters increase, store these command in `/rw/config/rc.local` so they get set on sys-net start-up
+
+```
+sudo nano /rw/config/rc.local
+```
+
+~~~
+#!/bin/sh
+
+
+####################
+# My service routing
+
+# Create a new firewall natting chain for my service
+if iptables -w -t nat -N MY-HTTPS; then
+
+# Add a natting rule if it did not exist (to avoid clutter if script executed multiple times)
+  iptables -w -t nat -A MY-HTTPS -j DNAT --to-destination 10.137.1.z
+
+fi
+
+
+# If no prerouting rule exist for my service
+if ! iptables -w -t nat -n -L PREROUTING | grep --quiet MY-HTTPS; then
+
+# add a natting rule for the traffic (same reason)
+  iptables -w -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.x.y -j MY-HTTPS
+fi
+
+
+######################
+# My service filtering
+
+# Create a new firewall filtering chain for my service
+if iptables -w -N MY-HTTPS; then
+
+# Add a filtering rule if it did not exist (to avoid clutter if script executed multiple times)
+  iptables -w -A MY-HTTPS -s 192.168.x.0/24 -j ACCEPT
+
+fi
+
+# If no forward rule exist for my service
+if ! iptables -w -n -L FORWARD | grep --quiet MY-HTTPS; then
+
+# add a forward rule for the traffic (same reason)
+  iptables -w -I FORWARD 2 -d 10.137.1.z -p tcp --dport 443 -m conntrack --ctstate NEW -j MY-HTTPS
+
+fi
+~~~
+
+> Note: Again in R4 the following needs to be added:
+
+~~~
+#############
+# In Qubes R4
+
+# If not already present
+if nft -nn list table ip qubes-firewall | grep "tcp dport 443 ct state new"; then
+
+# Add a filtering rule
+  nft add rule ip qubes-firewall forward meta iifname eth0 ip daddr 10.137.1.z tcp dport 443 ct state new counter accept
+
+fi
+~~~
+
+**3. Route packets from the FirewallVM to the VM**
+
+For the following example, we use the fact that the physical interface of sys-firewall, facing sys-net, is eth0. Furthermore, we assume that the target VM running the web server has the IP address 10.137.0.xx and that the IP address of sys-firewall is 10.137.1.z.
+
+In the sys-firewall VM's Terminal, code a natting firewall rule to route traffic on its outside interface for the service to the qube
+
+```
+iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 10.137.1.z -j DNAT --to-destination 10.137.0.xx
+```
+
+Code the appropriate new filtering firewall rule to allow new connections for the service
+
+```
+iptables -I FORWARD 2 -i eth0 -s 192.168.x.0/24 -d 10.137.0.xx -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
+```
+
+> Note: If you do not wish to limit the IP addresses connecting to the service, remove the ` -s 192.168.0.1/24 `
+
+> Note: On Qubes R4
+
+```
+nft add rule ip qubes-firewall forward meta iifname eth0 ip saddr 192.168.x.0/24 ip daddr 10.137.0.xx tcp dport 443 ct state new counter accept
+```
+
+Once you have confirmed that the counters increase, store these command in `/rw/config/qubes-firewall-user-script`
+
+```
+sudo nano /rw/config/qubes-firewall-user-script
+```
+
+~~~
+#!/bin/sh
+
+
+####################
+# My service routing
+
+# Create a new firewall natting chain for my service
+if iptables -w -t nat -N MY-HTTPS; then
+
+# Add a natting rule if it did not exist (to avoid clutter if script executed multiple times)
+  iptables -w -t nat -A MY-HTTPS -j DNAT --to-destination 10.137.0.xx
+
+fi
+
+
+# If no prerouting rule exist for my service
+if ! iptables -w -t nat -n -L PREROUTING | grep --quiet MY-HTTPS; then
+
+# add a natting rule for the traffic (same reason)
+  iptables -w -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 10.137.1.z -j MY-HTTPS
+fi
+
+
+######################
+# My service filtering
+
+# Create a new firewall filtering chain for my service
+if iptables -w -N MY-HTTPS; then
+
+# Add a filtering rule if it did not exist (to avoid clutter if script executed multiple times)
+  iptables -w -A MY-HTTPS -s 192.168.x.0/24 -j ACCEPT
+
+fi
+
+# If no forward rule exist for my service
+if ! iptables -w -n -L FORWARD | grep --quiet MY-HTTPS; then
+
+# add a forward rule for the traffic (same reason)
+  iptables -w -I FORWARD 4 -d 10.137.0.xx -p tcp --dport 443 -m conntrack --ctstate NEW -j MY-HTTPS
+
+fi
+
+################
+# In Qubes OS R4
+
+# If not already present
+if ! nft -nn list table ip qubes-firewall | grep "tcp dport 443 ct state new"; then
+
+# Add a filtering rule
+  nft add rule ip qubes-firewall forward meta iifname eth0 ip saddr 192.168.x.0/24 ip daddr 10.137.0.xx tcp dport 443 ct state new counter accept
+
+fi
+~~~
+
+Finally make this file executable (so it runs at every Firewall VM update)
+
+~~~
+sudo chmod +x /rw/config/qubes-firewall-user-script
+~~~
+
+If the service should be available to other VMs on the same system, do not forget to specify the additional rules described above.
+
+**4. Allow packets into the qube to reach the service**
+
+Here no routing is required, only filtering.
+Proceed in the same way as above but store the filtering rule in the `/rw/config/rc.local` script.
+For the following example, we assume that the target VM running the web server has the IP address 10.137.0.xx
+
+```
+sudo nano /rw/config/rc.local
+```
+
+~~~
+######################
+# My service filtering
+
+# Create a new firewall filtering chain for my service
+if iptables -w -N MY-HTTPS; then
+
+# Add a filtering rule if it did not exist (to avoid clutter if script executed multiple times)
+  iptables -w -A MY-HTTPS -j ACCEPT
+
+fi
+
+# If no input rule exists for my service
+if ! iptables -w -n -L INPUT | grep --quiet MY-HTTPS; then
+
+# add a forward rule for the traffic (same reason)
+  iptables -w -I INPUT 5 -d 10.137.0.xx -p tcp --dport 443 -m conntrack --ctstate NEW -j MY-HTTPS
+
+fi
+~~~
+
+This time testing should allow connectivity to the service as long as the service is up :-)
+
+Where to put firewall rules
+---------------------------
+
+Implicit in the above example [scripts](/doc/config-files/), but worth calling attention to: for all qubes *except* those supplying networking, iptables commands should be added to the `/rw/config/rc.local` script.
+For app qubes supplying networking (`sys-firewall` inclusive), iptables commands should be added to `/rw/config/qubes-firewall-user-script`.
+
+Firewall troubleshooting
+------------------------
+
+Firewall logs are stored in the systemd journal of the qube the firewall is running in (probably `sys-firewall`).
+You can view them by running `sudo journalctl -u qubes-firewall.service` in the relevant qube.
+Sometimes these logs can contain useful information about errors that are preventing the firewall from behaving as you would expect.

From a94d4f3059703a148deeee3adc8205c60e970e74 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Thu, 21 Dec 2023 01:02:35 +0000
Subject: [PATCH 058/332] Add link back from frewall page to 4.1 version

---
 user/security-in-qubes/firewall.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index 8d3efdb9..3cb7c42b 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -11,6 +11,12 @@ ref: 166
 title: Firewall
 ---
 
+Introduction
+----------------------------------
+This page explains use of the firewall in Qubes 4.2, using `nftables`.  
+In Qubes 4.1, all firewall components used `iptables`. For details of that usage see [here](../firewall_4.1/)
+
+
 Understanding firewalling in Qubes
 ----------------------------------
 

From 7c8762511ce485207c9171a5449195bd02239dde Mon Sep 17 00:00:00 2001
From: cinderflash <154299375+cinderflash@users.noreply.github.com>
Date: Wed, 20 Dec 2023 18:18:01 -0700
Subject: [PATCH 059/332] Fix reason:completed link

The "Issue tracking" page has a link to completed issues. The text
is reason:complete but the query is reason:completed.

This patch updates the text to align with the query.
---
 introduction/issue-tracking.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/introduction/issue-tracking.md b/introduction/issue-tracking.md
index e550ac40..64db9112 100644
--- a/introduction/issue-tracking.md
+++ b/introduction/issue-tracking.md
@@ -91,7 +91,7 @@ The issue tracker has several [projects](https://github.com/QubesOS/qubes-issues
 
 - [Search with labels.](https://github.com/QubesOS/qubes-issues/labels) For example, you can search issues by priority ([blocker](https://github.com/QubesOS/qubes-issues/labels/P%3A%20blocker), [critical](https://github.com/QubesOS/qubes-issues/labels/P%3A%20critical), [major](https://github.com/QubesOS/qubes-issues/labels/P%3A%20major), etc.) and by component ([core](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+label%3A%22C%3A+core%22), [manager/widget](https://github.com/QubesOS/qubes-issues/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3A%22C%3A+manager%2Fwidget%22+), [Xen](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+label%3A%22C%3A+Xen%22), etc.).
 
-- Search by closure reason: [`reason:complete`](https://github.com/QubesOS/qubes-issues/issues?q=reason%3Acompleted) and [`reason:"not planned"`](https://github.com/QubesOS/qubes-issues/issues?q=reason%3A%22not+planned%22).
+- Search by closure reason: [`reason:completed`](https://github.com/QubesOS/qubes-issues/issues?q=reason%3Acompleted) and [`reason:"not planned"`](https://github.com/QubesOS/qubes-issues/issues?q=reason%3A%22not+planned%22).
 
 - [Search by project](https://github.com/QubesOS/qubes-issues/projects).
 

From 607f66daeecc3304323225bf996186a4bc0fd5ba Mon Sep 17 00:00:00 2001
From: cinderflash <154299375+cinderflash@users.noreply.github.com>
Date: Thu, 21 Dec 2023 17:17:46 -0700
Subject: [PATCH 060/332] Remove extraneous word

---
 introduction/issue-tracking.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/introduction/issue-tracking.md b/introduction/issue-tracking.md
index 64db9112..f711dd9d 100644
--- a/introduction/issue-tracking.md
+++ b/introduction/issue-tracking.md
@@ -188,7 +188,7 @@ We close issues at step 3. Then, as updates are released, the issue automaticall
 
 Therefore, if you see that an issue is closed, but the fix is not yet available to you, be aware that it may be at an intermediate stage of this process between issue closure and the update being available in whichever repos you have enabled in whichever version of Qubes you're using.
 
-In order to assist with this, we have a label called [backport pending](https://github.com/QubesOS/qubes-issues/labels/backport%20pending), which means, "The fix has been released for the testing release but is pending backport to the stable release." Our infrastructure will attempt to apply this label automatically, when appropriate, but it is not perfect, and the developers may be need to adjust it manually.
+In order to assist with this, we have a label called [backport pending](https://github.com/QubesOS/qubes-issues/labels/backport%20pending), which means, "The fix has been released for the testing release but is pending backport to the stable release." Our infrastructure will attempt to apply this label automatically, when appropriate, but it is not perfect, and the developers may need to adjust it manually.
 
 ### Understanding open and closed issues
 

From ee3479c1699202da20d913c651f352da29702c61 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Thu, 21 Dec 2023 19:47:26 -0800
Subject: [PATCH 061/332] Remove announcement links

These announcements contain outdated information, and they mostly just
duplicate information that is already on each vendor's website. By
removing these links, we refrain from directing users to read
out-of-date information when they can instead get the latest information
from each vendor. Moreover, we don't have to worry about our duplicate
information becoming desynchronized from each vendor, which would create
confusion for users.
---
 user/hardware/certified-hardware.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/user/hardware/certified-hardware.md b/user/hardware/certified-hardware.md
index d06be86e..1338c9fb 100644
--- a/user/hardware/certified-hardware.md
+++ b/user/hardware/certified-hardware.md
@@ -29,37 +29,37 @@ The current Qubes-certified models are listed below in chronological order of ce
 
 [![Photo of the Insurgo PrivacyBeast X230](/attachment/site/insurgo-privacybeast-x230.png)](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/)
 
-The [Insurgo PrivacyBeast X230](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/) is a laptop based on the ThinkPad X230. It is certified for Qubes OS 4.X. Read our [announcement](/news/2019/07/18/insurgo-privacybeast-qubes-certification/) for details.
+The [Insurgo PrivacyBeast X230](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/) is a laptop based on the ThinkPad X230. It is certified for Qubes OS 4.X.
 
 ### NitroPad X230
 
 [![Photo of the NitroPad X230](/attachment/site/nitropad-x230.jpg)](https://shop.nitrokey.com/shop/product/nitropad-x230-67)
 
-The [NitroPad X230](https://shop.nitrokey.com/shop/product/nitropad-x230-67) is a laptop based on the ThinkPad X230. It is certified for Qubes OS 4.X. Read our [announcement](/news/2020/03/04/nitropad-x230-qubes-certification/) for details.
+The [NitroPad X230](https://shop.nitrokey.com/shop/product/nitropad-x230-67) is a laptop based on the ThinkPad X230. It is certified for Qubes OS 4.X.
 
 ### NitroPad T430
 
 [![Photo of the NitroPad T430](/attachment/site/nitropad-t430.jpg)](https://shop.nitrokey.com/shop/product/nitropad-t430-119)
 
-The [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119) is a laptop based on the ThinkPad T430. It is certified for Qubes OS 4.X. Read our [announcement](/news/2021/06/01/nitropad-t430-qubes-certification/) for details.
+The [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119) is a laptop based on the ThinkPad T430. It is certified for Qubes OS 4.X.
 
 ### Dasharo FidelisGuard Z690
 
 [![Photo of the Dasharo FidelisGuard Z690](/attachment/site/dasharo-fidelisguard-z690.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
 
-The [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is a desktop based on the MSI PRO Z690-A DDR4 motherboard. It is certified for Qubes OS 4.X. Read our [announcement](/news/2023/03/15/dasharo-fidelisguard-z690-first-qubes-certified-desktop/) for details.
+The [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is a desktop based on the MSI PRO Z690-A DDR4 motherboard. It is certified for Qubes OS 4.X.
 
 ### NovaCustom NV41 Series
 
 [![Photo of the NovaCustom NV41 Series](/attachment/site/novacustom-nv41-series.png)](https://novacustom.com/product/nv41-series/)
 
-The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is a 14-inch custom laptop. It is certified for Qubes OS 4.X. Read our [announcement](/news/2023/05/03/novacustom-nv41-series-qubes-certified/) for details.
+The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is a 14-inch custom laptop. It is certified for Qubes OS 4.X.
 
 ### NitroPC Pro
 
 [![Photo of the NitroPC Pro](/attachment/posts/nitropc-pro.jpg)](https://shop.nitrokey.com/shop/product/nitropc-pro-523)
 
-The [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523) is a desktop based on the MSI PRO Z690-A DDR5 motherboard. It is certified for Qubes OS 4.X. Read our [announcement](/news/2023/09/06/nitropc-pro-qubes-certified/) for details.
+The [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523) is a desktop based on the MSI PRO Z690-A DDR5 motherboard. It is certified for Qubes OS 4.X.
 
 ## Become hardware certified
 

From babb1b00f11236eb13033fe56d00470dd0d90734 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Fri, 22 Dec 2023 14:18:37 -0800
Subject: [PATCH 062/332] Remove Whonix from table

Whonix 16 will reach EOL before Qubes 4.1 reaches EOL, at which point
the table will be inaccurate. Since the Whonix support cycle does not
match the Qubes support cycle, and since whonix templates are not
official templates, it is better to remove from them from the table and
direct users to the Whonix website for official information about
support status.
---
 .../supported-releases.md                                 | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/user/downloading-installing-upgrading/supported-releases.md b/user/downloading-installing-upgrading/supported-releases.md
index 3d7d1b7d..8d6d567b 100644
--- a/user/downloading-installing-upgrading/supported-releases.md
+++ b/user/downloading-installing-upgrading/supported-releases.md
@@ -91,10 +91,10 @@ upstream release on the upstream distribution's website (see [Fedora
 EOL](https://fedoraproject.org/wiki/End_of_life) and [Debian
 Releases](https://wiki.debian.org/DebianReleases)).
 
-| Qubes OS    | Fedora | Debian | Whonix |
-| ----------- | ------ | ------ | ------ |
-| Release 4.1 | 38     | 11, 12 | 16     |
-| Release 4.2 | 38     | 12     | 17     |
+| Qubes OS    | Fedora | Debian |
+| ----------- | ------ | ------ |
+| Release 4.1 | 38     | 11, 12 |
+| Release 4.2 | 38     | 12     |
 
 ### Note on Debian support
 

From e1987db9a40055e8a1f52cf1fc2f88408dba1450 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Fri, 22 Dec 2023 14:31:43 -0800
Subject: [PATCH 063/332] Unwrap text

---
 .../supported-releases.md                     | 60 +++----------------
 1 file changed, 8 insertions(+), 52 deletions(-)

diff --git a/user/downloading-installing-upgrading/supported-releases.md b/user/downloading-installing-upgrading/supported-releases.md
index 8d6d567b..65565e1a 100644
--- a/user/downloading-installing-upgrading/supported-releases.md
+++ b/user/downloading-installing-upgrading/supported-releases.md
@@ -8,16 +8,11 @@ ref: 154
 title: Supported releases
 ---
 
-This page details the level and period of support for releases of operating
-systems in the Qubes ecosystem.
+This page details the level and period of support for releases of operating systems in the Qubes ecosystem.
 
 ## Qubes OS
 
-Qubes OS releases are supported for **six months** after each subsequent major
-or minor release (see [Version Scheme](/doc/version-scheme/)). The current
-release and past major releases are always available on the
-[Downloads](/downloads/) page, while all ISOs, including past minor releases,
-are available from our [download mirrors](/downloads/#mirrors).
+Qubes OS releases are supported for **six months** after each subsequent major or minor release (see [Version Scheme](/doc/version-scheme/)). The current release and past major releases are always available on the [Downloads](/downloads/) page, while all ISOs, including past minor releases, are available from our [download mirrors](/downloads/#mirrors).
 
 | Qubes OS    | Start Date | End Date   | Status         |
 | ----------- | ---------- | ---------- | -------------- |
@@ -33,13 +28,7 @@ are available from our [download mirrors](/downloads/#mirrors).
 
 ### Note on patch releases
 
-Please note that patch releases, such as 3.2.1 and 4.0.1, do not designate
-separate, new major or minor releases of Qubes OS. Rather, they designate their
-respective major or minor releases, such as 3.2 and 4.0, inclusive of all
-package updates up to a certain point. For example, installing Release 4.0 and
-fully updating it results in the same system as installing Release 4.0.1.
-Therefore, patch releases are not displayed as separate rows on any of the
-tables on this page.
+Please note that patch releases, such as 3.2.1 and 4.0.1, do not designate separate, new major or minor releases of Qubes OS. Rather, they designate their respective major or minor releases, such as 3.2 and 4.0, inclusive of all package updates up to a certain point. For example, installing Release 4.0 and fully updating it results in the same system as installing Release 4.0.1. Therefore, patch releases are not displayed as separate rows on any of the tables on this page.
 
 ## Dom0
 
@@ -58,38 +47,13 @@ The table below shows the OS used for dom0 in each Qubes OS release.
 
 ### Note on dom0 and EOL
 
-Dom0 is isolated from domUs. DomUs can access only a few interfaces, such as
-Xen, device backends (in the dom0 kernel and in other VMs, such as the NetVM),
-and Qubes tools (gui-daemon, qrexec-daemon, etc.). These components are
-[security-critical](/doc/security-critical-code/), and we provide updates for
-all of them (when necessary), regardless of the support status of the base
-distribution. For this reason, we consider it safe to continue using a given
-base distribution in dom0 even after it has reached end-of-life (EOL).
+Dom0 is isolated from domUs. DomUs can access only a few interfaces, such as Xen, device backends (in the dom0 kernel and in other VMs, such as the NetVM), and Qubes tools (gui-daemon, qrexec-daemon, etc.). These components are [security-critical](/doc/security-critical-code/), and we provide updates for all of them (when necessary), regardless of the support status of the base distribution. For this reason, we consider it safe to continue using a given base distribution in dom0 even after it has reached end-of-life (EOL).
 
 ## Templates
 
-The following table shows select [template](/doc/templates/) releases that are
-currently supported. Currently, only [Fedora](/doc/templates/fedora/) and
-[Debian](/doc/templates/debian/) templates are officially supported by the
-Qubes OS Project. [Whonix](https://www.whonix.org/wiki/Qubes) templates are
-supported by our partner, the [Whonix Project](https://www.whonix.org/). Qubes
-support for each template ends when that upstream release reaches end-of-life
-(EOL), even if that release is included in the table below. Please see below for
-distribution-specific notes.
+The following table shows select [template](/doc/templates/) releases that are currently supported. Currently, only [Fedora](/doc/templates/fedora/) and [Debian](/doc/templates/debian/) templates are officially supported by the Qubes OS Project. [Whonix](https://www.whonix.org/wiki/Qubes) templates are supported by our partner, the [Whonix Project](https://www.whonix.org/). Qubes support for each template ends when that upstream release reaches end-of-life (EOL), even if that release is included in the table below. Please see below for distribution-specific notes.
 
-It is the responsibility of each distribution to clearly notify its users in
-advance of its own EOL dates, and it is users' responsibility to heed these
-notices by upgrading to supported releases. As a courtesy to Qubes users, we
-attempt to pass along any upstream EOL notices we receive for
-officially-supported templates, but our ability to do this reliably is
-dependent on the upstream distribution's practices. If a distribution provides
-a mailing list similar to [qubes-announce](/support/#qubes-announce), which
-allows us to receive only very important, infrequent messages, including EOL
-announcements, we are much more likely to be able to pass along EOL notices to
-Qubes users reliably. Qubes users can always check the EOL status of an
-upstream release on the upstream distribution's website (see [Fedora
-EOL](https://fedoraproject.org/wiki/End_of_life) and [Debian
-Releases](https://wiki.debian.org/DebianReleases)).
+It is the responsibility of each distribution to clearly notify its users in advance of its own EOL dates, and it is users' responsibility to heed these notices by upgrading to supported releases. As a courtesy to Qubes users, we attempt to pass along any upstream EOL notices we receive for officially-supported templates, but our ability to do this reliably is dependent on the upstream distribution's practices. If a distribution provides a mailing list similar to [qubes-announce](/support/#qubes-announce), which allows us to receive only very important, infrequent messages, including EOL announcements, we are much more likely to be able to pass along EOL notices to Qubes users reliably. Qubes users can always check the EOL status of an upstream release on the upstream distribution's website (see [Fedora EOL](https://fedoraproject.org/wiki/End_of_life) and [Debian Releases](https://wiki.debian.org/DebianReleases)).
 
 | Qubes OS    | Fedora | Debian |
 | ----------- | ------ | ------ |
@@ -98,16 +62,8 @@ Releases](https://wiki.debian.org/DebianReleases)).
 
 ### Note on Debian support
 
-Debian releases have two EOL dates: regular and [long-term support
-(LTS)](https://wiki.debian.org/LTS). See [Debian Production
-Releases](https://wiki.debian.org/DebianReleases#Production_Releases) for a
-chart that illustrates this. Qubes support ends at the *regular* EOL date,
-*not* the LTS EOL date, unless a specific exception has been made.
+Debian releases have two EOL dates: regular and [long-term support (LTS)](https://wiki.debian.org/LTS). See [Debian Production Releases](https://wiki.debian.org/DebianReleases#Production_Releases) for a chart that illustrates this. Qubes support ends at the *regular* EOL date, *not* the LTS EOL date, unless a specific exception has been made.
 
 ### Note on Whonix support
 
-[Whonix](https://www.whonix.org/wiki/Qubes) templates are supported by our
-partner, the [Whonix Project](https://www.whonix.org/). The Whonix Project has
-set its own support policy for Whonix templates in Qubes. Please see the
-[Qubes-Whonix version support policy](https://www.whonix.org/wiki/About#Qubes_Hosts)
-for details.
+[Whonix](https://www.whonix.org/wiki/Qubes) templates are supported by our partner, the [Whonix Project](https://www.whonix.org/). The Whonix Project has set its own support policy for Whonix templates in Qubes. Please see the [Qubes-Whonix version support policy](https://www.whonix.org/wiki/About#Qubes_Hosts) for details.

From 7c7c0382d66f2a0cbfce6a44c3f04b8184b2a2cf Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Fri, 22 Dec 2023 14:33:33 -0800
Subject: [PATCH 064/332] Add minor clarification

---
 user/downloading-installing-upgrading/supported-releases.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/downloading-installing-upgrading/supported-releases.md b/user/downloading-installing-upgrading/supported-releases.md
index 65565e1a..18416a26 100644
--- a/user/downloading-installing-upgrading/supported-releases.md
+++ b/user/downloading-installing-upgrading/supported-releases.md
@@ -51,7 +51,7 @@ Dom0 is isolated from domUs. DomUs can access only a few interfaces, such as Xen
 
 ## Templates
 
-The following table shows select [template](/doc/templates/) releases that are currently supported. Currently, only [Fedora](/doc/templates/fedora/) and [Debian](/doc/templates/debian/) templates are officially supported by the Qubes OS Project. [Whonix](https://www.whonix.org/wiki/Qubes) templates are supported by our partner, the [Whonix Project](https://www.whonix.org/). Qubes support for each template ends when that upstream release reaches end-of-life (EOL), even if that release is included in the table below. Please see below for distribution-specific notes.
+The following table shows select [template](/doc/templates/) (and [standalone](/doc/standalones-and-hvms/)) releases that are currently supported. Currently, only [Fedora](/doc/templates/fedora/) and [Debian](/doc/templates/debian/) templates are officially supported by the Qubes OS Project. [Whonix](https://www.whonix.org/wiki/Qubes) templates are supported by our partner, the [Whonix Project](https://www.whonix.org/). Qubes support for each template ends when that upstream release reaches end-of-life (EOL), even if that release is included in the table below. Please see below for distribution-specific notes.
 
 It is the responsibility of each distribution to clearly notify its users in advance of its own EOL dates, and it is users' responsibility to heed these notices by upgrading to supported releases. As a courtesy to Qubes users, we attempt to pass along any upstream EOL notices we receive for officially-supported templates, but our ability to do this reliably is dependent on the upstream distribution's practices. If a distribution provides a mailing list similar to [qubes-announce](/support/#qubes-announce), which allows us to receive only very important, infrequent messages, including EOL announcements, we are much more likely to be able to pass along EOL notices to Qubes users reliably. Qubes users can always check the EOL status of an upstream release on the upstream distribution's website (see [Fedora EOL](https://fedoraproject.org/wiki/End_of_life) and [Debian Releases](https://wiki.debian.org/DebianReleases)).
 

From c25b832d597bf9da21a62e93bb12ea9b4f0399a8 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Fri, 22 Dec 2023 14:36:13 -0800
Subject: [PATCH 065/332] Make wording more accurate

---
 user/downloading-installing-upgrading/supported-releases.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/downloading-installing-upgrading/supported-releases.md b/user/downloading-installing-upgrading/supported-releases.md
index 18416a26..977806e0 100644
--- a/user/downloading-installing-upgrading/supported-releases.md
+++ b/user/downloading-installing-upgrading/supported-releases.md
@@ -53,7 +53,7 @@ Dom0 is isolated from domUs. DomUs can access only a few interfaces, such as Xen
 
 The following table shows select [template](/doc/templates/) (and [standalone](/doc/standalones-and-hvms/)) releases that are currently supported. Currently, only [Fedora](/doc/templates/fedora/) and [Debian](/doc/templates/debian/) templates are officially supported by the Qubes OS Project. [Whonix](https://www.whonix.org/wiki/Qubes) templates are supported by our partner, the [Whonix Project](https://www.whonix.org/). Qubes support for each template ends when that upstream release reaches end-of-life (EOL), even if that release is included in the table below. Please see below for distribution-specific notes.
 
-It is the responsibility of each distribution to clearly notify its users in advance of its own EOL dates, and it is users' responsibility to heed these notices by upgrading to supported releases. As a courtesy to Qubes users, we attempt to pass along any upstream EOL notices we receive for officially-supported templates, but our ability to do this reliably is dependent on the upstream distribution's practices. If a distribution provides a mailing list similar to [qubes-announce](/support/#qubes-announce), which allows us to receive only very important, infrequent messages, including EOL announcements, we are much more likely to be able to pass along EOL notices to Qubes users reliably. Qubes users can always check the EOL status of an upstream release on the upstream distribution's website (see [Fedora EOL](https://fedoraproject.org/wiki/End_of_life) and [Debian Releases](https://wiki.debian.org/DebianReleases)).
+It is the responsibility of each distribution to clearly notify its users in advance of its own EOL dates, and it is users' responsibility to heed these notices by upgrading to supported releases. As a courtesy to Qubes users, we attempt to pass along upstream EOL notices we receive for select distributions, but our ability to do this reliably is dependent on the upstream distribution's practices. For example, if a distribution provides a mailing list similar to [qubes-announce](/support/#qubes-announce), which allows us to receive only very important, infrequent messages, including EOL announcements, we are much more likely to be able to pass along EOL notices to Qubes users reliably. Qubes users can always check the EOL status of an upstream release on the upstream distribution's website (see [Fedora EOL](https://fedoraproject.org/wiki/End_of_life) and [Debian Releases](https://wiki.debian.org/DebianReleases)).
 
 | Qubes OS    | Fedora | Debian |
 | ----------- | ------ | ------ |

From c43c67e10a9bb211451d403a67360db3346e4f61 Mon Sep 17 00:00:00 2001
From: cinderflash <154299375+cinderflash@users.noreply.github.com>
Date: Fri, 22 Dec 2023 19:53:53 -0700
Subject: [PATCH 066/332] Pluralize word

---
 introduction/issue-tracking.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/introduction/issue-tracking.md b/introduction/issue-tracking.md
index f711dd9d..1085625b 100644
--- a/introduction/issue-tracking.md
+++ b/introduction/issue-tracking.md
@@ -105,7 +105,7 @@ This guideline is important for keeping issues focused on *actionable informatio
 
 ### Do not submit questions
 
-[qubes-issues](https://github.com/QubesOS/qubes-issues/issues) is not the place to ask questions. This includes, but is not limited to, troubleshooting questions and questions about how to do things with Qubes. Instead, see [Help, Support, Mailing Lists, and Forum](/support/) for appropriate place to ask questions. By contrast, [qubes-issues](https://github.com/QubesOS/qubes-issues/issues) is meant for tracking more general bugs, enhancements, and tasks that affect a broad range of Qubes users.
+[qubes-issues](https://github.com/QubesOS/qubes-issues/issues) is not the place to ask questions. This includes, but is not limited to, troubleshooting questions and questions about how to do things with Qubes. Instead, see [Help, Support, Mailing Lists, and Forum](/support/) for appropriate places to ask questions. By contrast, [qubes-issues](https://github.com/QubesOS/qubes-issues/issues) is meant for tracking more general bugs, enhancements, and tasks that affect a broad range of Qubes users.
 
 ### Use the issue template
 

From 3dd6a34f2a08eff745e9a3eb80f1c9b8ccc2719d Mon Sep 17 00:00:00 2001
From: cinderflash <154299375+cinderflash@users.noreply.github.com>
Date: Sat, 23 Dec 2023 22:11:42 -0700
Subject: [PATCH 067/332] Add missing word

---
 introduction/support.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/introduction/support.md b/introduction/support.md
index ef073184..9d8b7512 100644
--- a/introduction/support.md
+++ b/introduction/support.md
@@ -39,7 +39,7 @@ No worries! Here's how we recommend proceeding:
 3. Try [searching the issue tracker](/doc/issue-tracking/#search-tips). There
    may already be an open **or closed** issue about your problem. The issue
    tracker is constantly being updated with known bugs and may contain
-   workarounds for problems you're experiencing. If there any pinned issues at
+   workarounds for problems you're experiencing. If there are any pinned issues at
    the top, make sure to check them first!
 
 4. Try [searching the Qubes Forum](https://forum.qubes-os.org/). There may

From 444b04ddfb4747f2cb8a0e458979bba3b1be9ef9 Mon Sep 17 00:00:00 2001
From: cinderflash <154299375+cinderflash@users.noreply.github.com>
Date: Sun, 24 Dec 2023 16:21:45 -0700
Subject: [PATCH 068/332] Remove duplicate word

---
 introduction/support.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/introduction/support.md b/introduction/support.md
index 9d8b7512..03b51e46 100644
--- a/introduction/support.md
+++ b/introduction/support.md
@@ -226,7 +226,7 @@ The moderation team aims to enforce our [Code of Conduct](/code-of-conduct/).
 Beyond this, users should not expect any specific action from the moderation
 team. Specifically, users should not request that posts or messages be deleted
 or edited by a moderator. Users are reminded that, in most venues, anything
-posted will be sent out as an email to other others, and these emails cannot be
+posted will be sent out as an email to others, and these emails cannot be
 deleted from others' inboxes.
 
 ### Specific mailing list rules and notes

From 9f1a698032c39067ec671f37eee2f6e6914c05a3 Mon Sep 17 00:00:00 2001
From: EntomoSci <70287304+EntomoSci@users.noreply.github.com>
Date: Tue, 2 Jan 2024 20:41:57 -0300
Subject: [PATCH 069/332] Update standalones-and-hvms.md

Add cmd option to command alternative of standalone creation to reflect better the "alternative" part of the GUI version given its option msg "Standalone qube copied from a template".
---
 user/advanced-topics/standalones-and-hvms.md | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/user/advanced-topics/standalones-and-hvms.md b/user/advanced-topics/standalones-and-hvms.md
index 038f4f71..e1b0e7a3 100644
--- a/user/advanced-topics/standalones-and-hvms.md
+++ b/user/advanced-topics/standalones-and-hvms.md
@@ -59,11 +59,13 @@ your own OS)."
 Alternatively, from the dom0 command line:
 
 ```
-qvm-create --class StandaloneVM --label <YOUR_COLOR> --property virt_mode=hvm <NEW_STANDALONE_NAME>
+qvm-create --class StandaloneVM --label <YOUR_COLOR> --property virt_mode=hvm --template <TEMPLATE_QUBE_NAME> <NEW_STANDALONE_NAME>
 ```
 
-(Note: Technically, `virt_mode=hvm` is not necessary for every standalone.
-However, it makes sense if you want to use a kernel from within the qube.)
+Notes:
+- Technically, `virt_mode=hvm` is not necessary for every standalone.
+However, it makes sense if you want to use a kernel from within the qube.
+- If you want to make available the software installed in a template qube in your standalone, pass its name to `--template` option.
 
 ## Updating standalones
 

From 108fb1e106a65e0d5c0a7f13913be8fd288a62d0 Mon Sep 17 00:00:00 2001
From: chomiczosc <155738605+chomiczosc@users.noreply.github.com>
Date: Fri, 5 Jan 2024 15:26:36 +0100
Subject: [PATCH 070/332] Update getting-started.md

- simplifying "Getting started section" to make it more comprehensible
- updating the section to match Qubes 4.2
---
 introduction/getting-started.md | 135 +++++++++++++++-----------------
 1 file changed, 64 insertions(+), 71 deletions(-)

diff --git a/introduction/getting-started.md b/introduction/getting-started.md
index 1ac922d5..92409e27 100644
--- a/introduction/getting-started.md
+++ b/introduction/getting-started.md
@@ -18,14 +18,13 @@ Dive right in to [organizing your qubes](/doc/how-to-organize-your-qubes/).)
 
 ## The Basics
 
-Qubes OS is an operating system built out of securely-isolated compartments
-called [qubes](/doc/glossary/#qube). For example, you might have a work qube, a
-personal qube, a banking qube, a web browsing qube, and so on. You can have as
-many qubes as you want! Most of the time, you'll be using an [app
-qube](/doc/glossary/#app-qube), which is a qube intended for running software
+Qubes OS is an operating system built out of securely-isolated compartments, or [qubes](/doc/glossary/#qube). 
+You can have a work qube, a personal qube, a banking qube, a web browsing qube, a standalone Windows qube and so on. 
+You can have as many qubes as you want! Most of the time, you'll be using an [app
+qube](/doc/glossary/#app-qube), a qube for running software
 programs like web browsers, email clients, and word processors. Each app qube
 is based on another type of qube called a [template](/doc/glossary/#template).
-More than one qube can be based on the same template. Importantly, a qube
+The same template can be a base for various cubes. Importantly, a qube
 cannot modify its template in any way. This means that, if a qube is ever
 compromised, its template and any other qubes based on that template will
 remain safe. This is what makes Qubes OS so secure. Even if an attack is
@@ -35,9 +34,8 @@ Suppose you want to use your favorite web browser in several different qubes.
 You'd install the web browser in a template, then every qube based on that
 template would be able to run the web browser software (while still being
 forbidden from modifying the template and any other qubes). This way, you only
-have to install the web browser a single time, and updating the template serves
-to update all the qubes based on it. This elegant design saves time and space
-while enhancing security.
+have to install the web browser a single time, and updating the template updates all the qubes based on it. 
+This elegant design saves time and space while enhancing security.
 
 There are also some "helper" qubes in your system. Each qube that connects to
 the Internet does so through a network-providing [service
@@ -54,27 +52,24 @@ corresponding version number. There are many ready-to-use
 many as you like.
 
 Last but not least, there's a very special [admin
-qube](/doc/glossary/#admin-qube) which, as the name suggests, is used to
-administer your entire system. There's only one admin qube, and it's called
-[dom0](/doc/glossary/#dom0). You can think of it as the master qube, holding
-ultimate power over everything that happens in Qubes OS. Dom0 is more trusted
-than any other qube. If dom0 were ever compromised, it would be "game over."
-The entire system would effectively be compromised. That's why everything in
-Qubes OS is specifically designed to protect dom0 and ensure that doesn't
+qube](/doc/glossary/#admin-qube) used to administer your entire system. 
+There's only one admin qube, and it's called [dom0](/doc/glossary/#dom0). 
+You can think of it as the master qube, holding ultimate power over everything that happens in Qubes OS. 
+Dom0 is the most trusted one of all qubes. If dom0 were ever to be compromised, it would be "game over"- an effective compromise of the entire system.
+That's why everything in Qubes OS is specifically designed to protect dom0 and ensure that doesn't
 happen. Due to its overarching importance, dom0 has no network connectivity and
 is used only for running the [desktop
 environment](https://en.wikipedia.org/wiki/Desktop_environment) and [window
 manager](https://en.wikipedia.org/wiki/Window_manager). Dom0 should never be
 used for anything else. In particular, you should never run user applications
-in dom0. (That's what your app qubes are for!)
+in dom0. (That's what your app qubes are for!) In short, do not interact directly with dom0 in any way, shape or form.
 
 ### Color & Security
 
 You'll choose a **color** for each of your qubes out of a predefined set of
-colors. Each window on your desktop will have its frame colored according to
-the color of that qube. These colored frames help you keep track of which qube
-each window belongs to and how trustworthy it is. This is especially helpful
-when you have the same app running in multiple qubes at the same time. For
+colors. The color of the frame of each window on your desktop will correspond to the color of that cube. 
+These colored frames help you keep track of which qube you're currently using and how trustworthy it is. This is especially helpful
+when you have the same program running in multiple qubes at the same time. For
 example, if you're logged in to your bank account in one qube while doing some
 random web surfing in a different qube, you wouldn't want to accidentally enter
 your banking password in the latter! The colored frames help to avoid such
@@ -83,16 +78,16 @@ mistakes.
 [![snapshot_40.png](/attachment/doc/r4.0-snapshot_40.png)](/attachment/doc/r4.0-snapshot_40.png)
 
 Most Qubes users associate red with what's untrusted and dangerous (like a red
-light: stop! danger!), green with what's safe and trusted, and yellow and
-orange with things in the middle. This color scheme also extends to include
-blue and black, which are usually interpreted as indicating progressively more
-trusted domains than green, with black being ultimately trusted. Color and
-associated meanings are ultimately up to you, however. The system itself does
-not treat the colors differently. If you create two identical qubes --- black
+stop light signalling danger), green with what's safe and trusted, and yellow and
+orange with things in-between. This color scheme also includes
+blue and black, commonly interpreted as indicating progressively more
+trusted domains than green, with black being ultimately trusted. However, color and
+associated meanings are entirely up to you. The system itself does
+not treat the colors differently - they're all equally safe on their own. If you create two identical qubes --- black
 and red, say --- they'll be the same until you start using them differently.
-Feel free to use the colors in whatever way is most useful to you. For example,
+Feel free to use the colors in the way that best meets your needs. For example,
 you might decide to use three or four qubes for work activities and give them
-all the same color --- or all different colors. It's entirely up to you.
+all the same color --- or all different colors depending on the nature of the task they are used for.
 
 ### User Interface
 
@@ -104,27 +99,24 @@ the window managers [i3](/doc/i3/) and [AwesomeWM](/doc/awesomewm/).
 
 [![r4.0-taskbar.png](/attachment/doc/r4.0-taskbar.png)](/attachment/doc/r4.0-taskbar.png)
 
-The bar at the top of your screen in Qubes 4.0 includes the following XFCE
+The bar at the top of your screen in Qubes 4.2 includes the following XFCE
 component areas:
 
-- The **Tray**, where many functional widgets live.
+- The **App Menu**, where you go to open an application within a qube, to open
+  a dom0 terminal, to access administrative UI tools such as the Qube Manager,
+  or to access settings panels for your desktop environment.
+- The **Task Bar** where buttons for open and hidden windows live.
 - **Spaces**, an interface for [virtual
   desktops](https://en.wikipedia.org/wiki/Virtual_desktop). Virtual desktops do
   not have any inherent security isolation properties, but some users find them
   useful for organizing things.
-- The **Task Bar** where buttons for open and hidden windows live.
-- The **App Menu**, where you go to open an application within a qube, to open
-  a dom0 terminal, to access administrative UI tools such as the Qube Manager,
-  or to access settings panels for your desktop environment.
-
-To learn more about how to customize your desktop environment, we recommend you
-spend some time going through [XFCE's documentation](https://docs.xfce.org/).
+- The **Tray**, where many functional widgets live.
 
 There are several tray widgets that are unique to Qubes OS:
 
 - The **Whonix SDWDate** allows you to control the Tor connection in your
   [`sys-whonix`](https://www.whonix.org/wiki/Qubes) qube.
-- The **Qubes Clipboard** lets you easily copy text from dom0.
+- The **Qubes Clipboard** lets you easily [copy text](https://wwwpreview.qubes-os.org/doc/how-to-copy-and-paste-text/) between various qubes and from dom0.
 - The **Qubes Devices** widget allows you to attach and detach devices --- such
   as USB drives and cameras --- to qubes. 
 - The **Qubes Disk Space** widget shows you how much storage you're using.
@@ -136,50 +128,57 @@ There are several tray widgets that are unique to Qubes OS:
 
 [![r4.1-widgets.png](/attachment/doc/r4.1-widgets.png)](/attachment/doc/r4.1-widgets.png)
 
+To learn more about how to customize your desktop environment, we recommend you
+go through [XFCE's documentation](https://docs.xfce.org/).
+
 #### Qube Manager
 
-To see all of your qubes at the same time, you can use the **Qube Manager** (go
-to the App Menu → Qubes Tools → Qube Manager), which displays the states of
-all the qubes in your system, even the ones that aren't running.
+To see all of your qubes at the same time, you can use the **Qube Manager**. 
+It displays the states of all the qubes in your system, even the ones that aren’t running.
+
+To access Qube Manager go to:
+Qubes Icon (App Menu) → Settings Icon → Qubes Tools → **Qube Manager**
 
 [![r4.0-qubes-manager.png](/attachment/doc/r4.0-qubes-manager.png)](/attachment/doc/r4.0-qubes-manager.png)
 
 #### Command-line interface
 
-All aspects of Qubes OS can be controlled using command-line tools. Opening a
-terminal emulator in dom0 can be done in several ways:
+All aspects of Qubes OS can be controlled using command-line tools such as the terminal emulator. 
+The default terminal emulator in Qubes is Xfce Terminal. 
+Opening a terminal emulator in dom0 can be done in several ways:
 
-- Go to the App Menu and select **Terminal Emulator** at the top.
+- Go to the App Menu, click on the Settings icon, choose Other from the drop-down menu, and select **Xfce Terminal Emulator** at the bottom.
 - Press `Alt`+`F3` and search for `xfce terminal`.
 - Right-click on the desktop and select **Open Terminal Here**.
 
-Terminal emulators can also be run in other qubes as normal programs. Various
-command-line tools are described as part of this guide, and the whole reference
-can be found [here](/doc/tools/).
+Various command-line tools are described as part of this guide, and the whole reference can be found [here](/doc/tools/).
+Terminal emulators can also be run in other qubes as normal programs. 
 
 ## First boot
 
 When you install Qubes OS, a number of qubes are pre-configured for you:
 
-- **Templates:** `fedora-XX` (`XX` being the version number)
+- **App qubes** such as `work`, `personal`, `untrusted`, and `vault` are your "starter pack" qubes to compartmentalize tasks
+  and types of data to suit most basic needs. (There is nothing special about these pre-configured qubes - they are identical in nature to more specific ones you might wish to create later.)
+- **Templates:** `fedora-XX`, `debian-XX` (`XX` being the version number)
+- **Service qubes:** `sys-usb`, `sys-net`, `sys-firewall`, and `sys-whonix`)
 - **Admin qube:** `dom0`
-- **Service qubes:** `sys-usb`, `sys-net`, `sys-firewall`, and `sys-whonix`
-- **App qubes** configured to prioritize security by compartmentalizing tasks
-  and types of data: `work`, `personal`, `untrusted`, and `vault`. (There is
-  nothing special about these qubes. If you were to create a black qube and
-  name it `vault`, it would be the same as the pre-configured `vault` qube.
-  They're just suggestions to get you started. )
 
-A variety of open-source applications such as file managers, command-line
-terminals, printer managers, text editors, and "applets" used to configure
-different things like audio or parts of the user interface are also installed
-by default—most within the templates. Most are bundled with each template.
+Other software installed in Qubes OS by default includes open-source applications such as file managers, 
+command-line terminals, printer managers, text editors, and applets for configuring audio and user interface settings.
+Most of these applications are incorporated within each template.
 
 ### Adding, removing, and listing qubes
 
-You can easily create a new qube with the **Create Qubes VM** option in the App
-Menu. If you need to add or remove qubes, simply use the Qube Manager's **Add**
-and **Remove** buttons. You can also add, remove, and list qubes from the
+To create a new qube or remove one, use **Create Qubes VM** option in the App Menu.
+
+Creating a New Qube:
+Qubes Icon → Settings → Qubes Tools → Qube Manager → Create Qubes VM → **New Qube**
+
+Removing a qube:
+To remove a qube, use the **Delete qube button** as the final step instead.
+
+You can also add, remove, and list qubes from the
 command line using the following tools:
 
 - `qvm-create`
@@ -188,14 +187,8 @@ command line using the following tools:
 
 ### How many qubes do I need?
 
-That's a great question, but there's no one-size-fits-all answer. It depends on
-the structure of your digital life, and this is at least a little different for
-everyone. If you plan on using your system for work, then it also depends on
-what kind of job you do.
-
-It's a good idea to start out with the qubes created automatically by the
-installer: `work`, `personal`, `untrusted`, and `vault`. If and when you start
-to feel that some activity just doesn't fit into any of your existing qubes, or
+It's a good idea to start out with the pre-installed app qubes: `work`, `personal`, `untrusted`, and `vault`. 
+If you start to feel that some activity just doesn't fit into any of your existing qubes, or
 you want to partition some part of your life, you can easily create a new qube
 for it. You'll also be able to easily [copy any
 files](/doc/how-to-copy-and-move-files) you need to the newly-created qube.
@@ -252,5 +245,5 @@ GitHub](https://github.com/QubesOS).
 
 ## Documentation
 
-Peruse our extensive library of [documentation](/doc/) for users and developers
+Browse our extensive library of [documentation](/doc/) for users and developers
 of Qubes OS. You can even [help us improve it](/doc/how-to-edit-the-documentation/)!

From 4a9ab9fac587590027d8330dcc25e6a825d93182 Mon Sep 17 00:00:00 2001
From: chomiczosc <155738605+chomiczosc@users.noreply.github.com>
Date: Fri, 5 Jan 2024 15:45:08 +0100
Subject: [PATCH 071/332] Update getting-started.md

Fixes from review
---
 introduction/getting-started.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/introduction/getting-started.md b/introduction/getting-started.md
index 92409e27..4a02083c 100644
--- a/introduction/getting-started.md
+++ b/introduction/getting-started.md
@@ -24,7 +24,7 @@ You can have as many qubes as you want! Most of the time, you'll be using an [ap
 qube](/doc/glossary/#app-qube), a qube for running software
 programs like web browsers, email clients, and word processors. Each app qube
 is based on another type of qube called a [template](/doc/glossary/#template).
-The same template can be a base for various cubes. Importantly, a qube
+The same template can be a base for various qubes. Importantly, a qube
 cannot modify its template in any way. This means that, if a qube is ever
 compromised, its template and any other qubes based on that template will
 remain safe. This is what makes Qubes OS so secure. Even if an attack is
@@ -62,7 +62,7 @@ is used only for running the [desktop
 environment](https://en.wikipedia.org/wiki/Desktop_environment) and [window
 manager](https://en.wikipedia.org/wiki/Window_manager). Dom0 should never be
 used for anything else. In particular, you should never run user applications
-in dom0. (That's what your app qubes are for!) In short, do not interact directly with dom0 in any way, shape or form.
+in dom0. (That's what your app qubes are for!) In short, be very careful when interacting with dom0.
 
 ### Color & Security
 

From 4971daeec4ffd017c9d2525d7335641aa19859c5 Mon Sep 17 00:00:00 2001
From: Pierre Alain <65669679+palainp@users.noreply.github.com>
Date: Fri, 5 Jan 2024 18:36:42 +0100
Subject: [PATCH 072/332] Update managing-vm-kernels.md

The presence of initramfs is checked with Qubes 4.2 in the current head of qubes-core-admin (https://github.com/QubesOS/qubes-core-admin/blob/49c9fc95a26fbc866efe731b94cef543de67cb07/qubes/storage/kernels.py#L140).
---
 user/advanced-topics/managing-vm-kernels.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/advanced-topics/managing-vm-kernels.md b/user/advanced-topics/managing-vm-kernels.md
index 903151ad..fd073123 100644
--- a/user/advanced-topics/managing-vm-kernels.md
+++ b/user/advanced-topics/managing-vm-kernels.md
@@ -224,7 +224,7 @@ Kernel for a VM is stored in `/var/lib/qubes/vm-kernels/KERNEL_VERSION` director
 * `modules.img` - ext4 filesystem image containing Linux kernel modules (to be mounted at `/lib/modules`); additionally it should contain a copy of `vmlinuz` and `initramfs` in its root directory (for loading by qemu inside stubdomain)
 * `default-kernelopts-common.txt` - default kernel options, in addition to those specified with `kernelopts` qube property (can be disabled with `no-default-kernelopts` feature)
 
-All the files besides `vmlinuz` are optional in Qubes R4.1 or newer. In Qubes R4.0, `vmlinuz` and `initramfs` are both required to be present.
+All the files besides `vmlinuz` and `initramfs` are optional in Qubes R4.0 or newer.
 
 ## Using kernel installed in the VM
 

From 206f7f20865ede1af6ae80495831128bcee6d04d Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Fri, 5 Jan 2024 19:58:32 -0800
Subject: [PATCH 073/332] Further clarify spaces in fingerprint

https://forum.qubes-os.org/t/23503
---
 project-security/verifying-signatures.md | 29 +++++++++++++++---------
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/project-security/verifying-signatures.md b/project-security/verifying-signatures.md
index 5be0d0b3..5a474674 100644
--- a/project-security/verifying-signatures.md
+++ b/project-security/verifying-signatures.md
@@ -190,8 +190,9 @@ you see here may not be genuine. That's why we strongly suggest obtaining the
 fingerprint from *multiple independent sources in several different ways*, then
 comparing the strings of letters and numbers to make sure they match.
 
-When it comes to PGP fingerprints, spaces and capitalization don't matter. In
-other words, all of these fingerprints are considered the same:
+For the purpose of convincing yourself that you know the authentic QMSK
+fingerprint, spaces and capitalization don't matter. In other words, all of
+these fingerprints are considered the same:
 
 ```
 427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494
@@ -201,12 +202,16 @@ other words, all of these fingerprints are considered the same:
 ```
 
 Instead, what matters is that *all* the characters are present in *exactly* the
-same order. If even one character is different, the fingerprints do not match.
-Even if two fingerprints have all the same characters, if any of those
-characters are in a different order, sequence, or position, then the
-fingerprints do not match.
+same order. If even one character is different, the fingerprints should not be
+considered the same. Even if two fingerprints have all the same characters, if
+any of those characters are in a different order, sequence, or position, then
+the fingerprints should not be considered the same.
 
-You may also sometimes see the entire fingerprint prefixed with `0x`, as in:
+However, for the purpose of *searching for*, *looking up*, or *entering* keys,
+spaces and capitalization can matter, depending on the software or tool you're
+using. You may need to try different variations (e.g., with and without
+spaces). You may also sometimes see (or need to enter) the entire fingerprint
+prefixed with `0x`, as in:
 
 ```
 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494
@@ -214,10 +219,12 @@ You may also sometimes see the entire fingerprint prefixed with `0x`, as in:
 ```
 
 The `0x` prefix is sometimes used to indicate that the string following it is a
-hexadecimal value, and some PGP-related tools may require this prefix. For the
-purpose of comparing fingerprints as described here, you may safely ignore the
-`0x` prefix, as it is not part of the fingerprint. As long as the 40-character
-string after the `0x` matches exactly, the fingerprint is the same.
+hexadecimal value, and some PGP-related tools may require this prefix. Again,
+for the purpose of convincing yourself that you know the authentic QMSK
+fingerprint, you may safely ignore the `0x` prefix, as it is not part of the
+fingerprint. As long as the 40-character string after the `0x` matches exactly,
+the fingerprint is considered the same. The `0x` prefix only matters if the
+software or tool you're using cares about it.
 
 The general idea of "comparing fingerprints" is to go out into the world
 (whether digitally, physically, or both) and find other 40-character strings

From ee570dee48952fd17483cf681157ffe8676ccb31 Mon Sep 17 00:00:00 2001
From: cinderflash <154299375+cinderflash@users.noreply.github.com>
Date: Mon, 8 Jan 2024 22:59:01 -0700
Subject: [PATCH 074/332] Pluralize word

---
 introduction/support.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/introduction/support.md b/introduction/support.md
index 03b51e46..4fc0185e 100644
--- a/introduction/support.md
+++ b/introduction/support.md
@@ -403,7 +403,7 @@ interface](https://groups.google.com/group/qubes-devel).
 This list is for non-technical discussion and coordination around the Qubes OS
 project.
 
-Examples of topics or question suitable for this list include:
+Examples of topics or questions suitable for this list include:
 
 * Participation (talks, workshops, etc.) at upcoming events
 * Project funding applications and strategies
@@ -430,7 +430,7 @@ interface](https://groups.google.com/group/qubes-project).
 This list is for discussion around the localization and translation of Qubes
 OS, its documentation, and the website.
 
-Examples of topics or question suitable for this list include:
+Examples of topics or questions suitable for this list include:
 
 * Questions about or issues with [Transifex](https://www.transifex.com/), the
   translation platform we use

From 7a2f875a330ab69f47756080c94e859a8e586907 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Wed, 10 Jan 2024 03:56:19 -0800
Subject: [PATCH 075/332] Remove outdated sentence

---
 user/hardware/certified-hardware.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/hardware/certified-hardware.md b/user/hardware/certified-hardware.md
index 942bbe37..42afb236 100644
--- a/user/hardware/certified-hardware.md
+++ b/user/hardware/certified-hardware.md
@@ -65,7 +65,7 @@ The [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523) is a d
 
 [![Photo of the Star Labs StarBook](/attachment/site/starlabs-starbook.png)](https://starlabs.systems/pages/starbook)
 
-The [Star Labs StarBook](https://starlabs.systems/pages/starbook) is a 14-inch laptop. It is certified for Qubes OS 4.X. Read our [announcement](TODO) for details.
+The [Star Labs StarBook](https://starlabs.systems/pages/starbook) is a 14-inch laptop. It is certified for Qubes OS 4.X.
 
 ## Become hardware certified
 

From b7a000ad061c082cd47cc0be3b65247fc2f6daba Mon Sep 17 00:00:00 2001
From: Rune Philosof <57357936+runephilosof-abtion@users.noreply.github.com>
Date: Mon, 22 Jan 2024 07:54:23 +0100
Subject: [PATCH 076/332] fedora-upgrade.md: Update template-name

The qubes-updater has started using the qvm-features template-name to check whether the template is supported.
So the template name needs to be updated.
https://github.com/QubesOS/qubes-desktop-linux-manager/blob/main/qui/utils.py#L83-L95

Partly fixes: https://github.com/QubesOS/qubes-issues/issues/8725
Still missing the other in-place template upgrade instructions.
---
 user/templates/fedora/fedora-upgrade.md | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/user/templates/fedora/fedora-upgrade.md b/user/templates/fedora/fedora-upgrade.md
index 2529e1de..2d5dad90 100644
--- a/user/templates/fedora/fedora-upgrade.md
+++ b/user/templates/fedora/fedora-upgrade.md
@@ -51,6 +51,7 @@ If you wish to install a new, unmodified Fedora template instead of upgrading a
 [user@dom0 ~]$ qvm-shutdown fedora-<new>
 [user@dom0 ~]$ sudo losetup -d $dev
 [user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
+[user@dom0 ~]$ qvm-features fedora-<new> template-name fedora-<new>
 ```
 
 **Recommended:** [Switch everything that was set to the old template to the new template.](/doc/templates/#switching)
@@ -159,15 +160,21 @@ The same general procedure may be used to upgrade any template based on the stan
     [user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
     ```
 
-8. (Recommended) [Switch everything that was set to the old template to the new template.](/doc/templates/#switching)
+8. Set the template-name, which is used by the Qubes updater.
 
-9. (Optional) Make the new template the global default.
+    ```
+    [user@dom0 ~]$ qvm-features fedora-<new> template-name fedora-<new>
+    ```
+
+9. (Recommended) [Switch everything that was set to the old template to the new template.](/doc/templates/#switching)
+
+10. (Optional) Make the new template the global default.
 
     ```
     [user@dom0 ~]$ qubes-prefs --set default_template fedora-<new>
     ```
 
-10. (Optional) [Uninstall the old template.](/doc/templates/#uninstalling)
+11. (Optional) [Uninstall the old template.](/doc/templates/#uninstalling)
     Make sure that the template you're uninstalling is the old one, not the new one!
 
 ## Summary instructions for Fedora Minimal templates
@@ -180,6 +187,7 @@ The same general procedure may be used to upgrade any template based on the stan
 [root@fedora-<new>-minimal ~]# dnf clean all
 [user@fedora-<new>-minimal ~]# dnf --releasever=<new> --best --allowerasing distro-sync
 [user@fedora-<new>-minimal ~]# fstrim -v /
+[user@dom0 ~]$ qvm-features fedora-<new>-minimal template-name fedora-<new>
 ```
 
 (Shut down template by any normal means.)

From 164bc8289cdff01588d6ff21159f0a6740b7f07a Mon Sep 17 00:00:00 2001
From: deeplow <deeplower@protonmail.com>
Date: Fri, 2 Feb 2024 10:38:29 +0000
Subject: [PATCH 077/332] Generalize YubiKey guide by adding TOTP MFA

Not every user will have a hardware token. This adds instructions
for setting up multi-factor with TOTP. This was inspired / based on
work by @kennethrrosen [1].

Everything about the YubiKey guide is kept but moved to a lower
heading level to acommodate for the two MFA options: YubiKey or TOTP.

[1]: https://forum.qubes-os.org/t/otp-for-xscreensaver-guide/23988
---
 .../security-in-qubes/{yubi-key.md => mfa.md} | 130 +++++++++++++++---
 1 file changed, 112 insertions(+), 18 deletions(-)
 rename user/security-in-qubes/{yubi-key.md => mfa.md} (60%)

diff --git a/user/security-in-qubes/yubi-key.md b/user/security-in-qubes/mfa.md
similarity index 60%
rename from user/security-in-qubes/yubi-key.md
rename to user/security-in-qubes/mfa.md
index a4cdfc68..b1f6938f 100644
--- a/user/security-in-qubes/yubi-key.md
+++ b/user/security-in-qubes/mfa.md
@@ -1,32 +1,126 @@
 ---
 lang: en
 layout: doc
-permalink: /doc/yubikey/
+permalink: /doc/mfa/
 redirect_from:
 - /doc/yubi-key/
 - /en/doc/yubi-key/
 - /doc/YubiKey/
+- /doc/yubikey/
 ref: 169
-title: YubiKey
+title: Multi-factor Login
 ---
 
+
+## Multi-factor authentication within in particular qubes
+
+Most use cases for the hardware tokens can be achieved exactly as described by the
+manufacturer or other instructions found online. One usually just needs to
+attach the token (e.g. YubiKey) to the corresponding app qube to get the same
+result (see the documentation on how to use [USB devices](/doc/how-to-use-usb-devices/)
+in Qubes OS accordingly). The recommended way for using CTAP in Qubes is described
+[here](https://www.qubes-os.org/doc/ctap-proxy/).
+
+## Multi-factor login for Qubes OS
+
+By default Qubes has two protection mechanisms against attackers. The first is full disk encryption and the second the user login screen / lockscreen. This article section concerns only adding multi-factor authentication to the second one.
+
+### Time-based One-time Password (TOTP)
+
+As the name implies, this generates authentication code that is time-dependent. You can save the TOTP secret in a mobile app like [FreeOTP](https://en.wikipedia.org/wiki/FreeOTP)
+and then use it as an additional factor to login to your Qubes system.
+
+> **Warning**: remember to keep backup access codes.
+
+1. Download `google-authenticator` in dom0:
+
+    ```
+    sudo qubes-dom0-update google-authenticator
+    ```
+
+2. Run google authenticator:
+
+    ```
+    google-authenticator
+    ```
+
+3. Walk through the setup instructions 2 which will also generate your QR code for your auth app of choice:
+
+   ```
+   Do you want me to update your “/home/user/.google_authenticator” file (y/n) y
+
+   Do you want to disallow multiple uses of the same authentication token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n)
+
+   By default, tokens are good for 30 seconds, and to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. If you experience problems with poor time synchronization, you can increase the window from its default size of 1:30min to about 4min. Do you want to do so (y/n)
+
+   If the computer that you are logging into isn’t hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s. Do you want to enable rate-limiting (y/n)
+   ```
+
+> **Warning**: in the next session if incorrectly performed, there is the risk of locking yourself out. Before procedding ensure that you have an up-to-date backup.
+>
+> For advanced users, to make sure you can quickly recover, you can also open another loging session in a tty. To do this, you do <kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>F2</kbd> and login normally. Should anything go wrong, as long as you don't shut the computer down, you can still access this tty by entering the same key combination and reverting the changes. After you've opened this "backup" login, you can get to your graphical desktop with <kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>F1</kbd>.
+
+Now we are going to add the authenticator as a login requirement:
+
+1. `sudo authselect create-profile mfa --base-on sssd`
+
+2. Edit the custom system authentication template with `sudo nanois encouraged /etc/authselect/custom/mfa/system-auth`.
+
+   Add the following line right after `auth required pam_faildelay.so delay=2000000`:
+
+   ```
+   auth required pam_google_authenticator.so
+   ```
+
+   After the change, the top of the file should look like this:
+
+   ```
+   {imply "with-smartcard" if "with-smartcard-required"}
+   auth required pam_env.so
+   auth required pam_faildelay.so delay=2000000
+   auth required pam_google_authenticator.so
+   ```
+
+3. Lastly, activate this authentication method with:
+
+   ```
+   sudo authselect select custom/mfa
+   ```
+
+Now you can test by locking the screen with <kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>l</kbd>. If it was successful and you are pleased with the results, restart your computer.
+
+**Note**: When logging in. the first thing you put is the TOTP secret and then the password. This is true in the screen locker and as well as the session manager (the login window that shows right after you put the disk encryption passphrase).
+
+After this is done, its recommended to do a backup. This is because as long as you incude dom0 in the backup, your authentication code will be backed up as well.
+
+#### Troubleshooting
+
+The following assumes you haven't restarted your computer since setting up TOTP secret.
+
+1. Switch to TTY2 with <kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>F2</kbd>.
+2. Revert to the original policy with:
+   ```
+   sudo authselect select sssd
+   ```
+3. Switch back to the graphical desktop with <kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>F1</kbd>. You should be able to login normally (without multi-factor authentication).
+4. Change the mfa custom policy and apply it again.
+
+#### Lost TOTP / authentication device?
+
+In case you've lost your TOTP authentication device, you have two options.
+
+The first option is backup codes. When generating the TOTP secret you must have saved some recovery codes. Those can be used in place of the TOTP code, but they're discarded after use. So make sure you redo the multi-factor authentications intructions.
+
+The second option is recovery from a backup. It will work as long as you included dom0 in said backup. After restoring the dom0 backup, open a terminal in dom0 and the file should be located in `/home/<USER>/home-restore-<DATE>/dom0-home/<USER>/.google_authenticator`.
+
+### Login with a YubiKey
+
 "The YubiKey is a hardware authentication device manufactured by Yubico to
 protect access to computers, networks, and online services that supports
 one-time passwords (OTP), public-key cryptography, and authentication, and the
 Universal 2nd Factor (U2F) and FIDO2 protocols[1] developed by the FIDO
 Alliance." ([Wikipedia](https://en.wikipedia.org/wiki/YubiKey))
 
-## General usage in Qubes OS
-
-Most use cases for the YubiKey can be achieved exactly as described by the
-manufacturer or other instructions found online. One usually just needs to
-attach the YubiKey to the corresponding app qube to get the same result (see the
-documentation on how to use [USB devices](/doc/how-to-use-usb-devices/) in Qubes
-OS accordingly). The recommended way for using CTAP in Qubes is described
-[here](https://www.qubes-os.org/doc/ctap-proxy/).
-
-## Multi-factor login for Qubes OS
-
 You can use a YubiKey to enhance the user authentication in Qubes. The following
 instructions explain how to setup the YubiKey as an *additional* way to login.
 
@@ -45,7 +139,7 @@ during setup and b) you do not need to fear [shoulder
 surfing](https://en.wikipedia.org/wiki/Shoulder_surfing_(computer_security)) so
 much (i.e. by not using your standard login password in public).
 
-### Setup login with YubiKey
+#### Setup login with YubiKey
 
 To use the YubiKey for multi-factor authentication you need to
 
@@ -90,7 +184,7 @@ All these requirements are described below, step by step.
 YubiKey](https://www.qubes-os.org/doc/how-to-use-usb-devices/) to this app qube
 though) or directly on the sys-usb vm.
 
-   You need to (temporarily) install the package "yubikey-personalization-gui" and 
+   You need to (temporarily) install the package "yubikey-personalization-gui" and
    run it by typing `yubikey-personalization-gui` in the command line.
 
    - In the program go to `Challenge-Response`,
@@ -154,7 +248,7 @@ these files, otherwise it will most likely not work.
 7. Adjust the USB VM name in case you are using something other than the default
    `sys-usb` by editing `/etc/qubes/yk-keys/yk-vm` in dom0.
 
-### Usage
+#### Usage
 
 When you want to authenticate
 
@@ -169,7 +263,7 @@ When everything is ok, your screen will be unlocked.
 In any case you can still use your normal login password, but do it in a secure
 location where no one can snoop your password.
 
-### Optional: Enforce YubiKey Login
+#### Optional: Enforce YubiKey Login
 
 Edit `/etc/pam.d/yubikey` (or appropriate file if you are using other screen locker program) and remove `default=ignore` so the line looks like this.
 
@@ -177,7 +271,7 @@ Edit `/etc/pam.d/yubikey` (or appropriate file if you are using other screen loc
 auth [success=done] pam_exec.so expose_authtok quiet /usr/bin/yk-auth
 ```
 
-### Optional: Locking the screen when YubiKey is removed
+#### Optional: Locking the screen when YubiKey is removed
 
 Look into it
 You can setup your system to automatically lock the screen when you unplug your YubiKey.

From 8d0e6ed68c32f33cf878f126fc29aa9db5baf831 Mon Sep 17 00:00:00 2001
From: ABIbreak <158116564+ABIbreak@users.noreply.github.com>
Date: Sat, 3 Feb 2024 23:11:15 -0500
Subject: [PATCH 078/332] Remove mentions of wireless-tools

Fedora removed the package back in 2021 (see https://fedoraproject.org/wiki/Changes/RemoveWirelessExtensions), and a query on pkgs.org reports that CentOS does not have any packages by that name
---
 user/templates/minimal-templates.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/templates/minimal-templates.md b/user/templates/minimal-templates.md
index 6fd7aa9f..2da511ff 100644
--- a/user/templates/minimal-templates.md
+++ b/user/templates/minimal-templates.md
@@ -144,7 +144,7 @@ list of packages to be installed):
   (which is normally `sys-firewall`).
 - NetVM, such as the template for `sys-net`: `qubes-core-agent-networking`
   `qubes-core-agent-network-manager` `NetworkManager-wifi`
-  `network-manager-applet` `wireless-tools` `notification-daemon`
+  `network-manager-applet` `notification-daemon`
   `gnome-keyring` `polkit` `@hardware-support`. If your network devices need
   extra packages for the template to work as a network VM, use the `lspci`
   command to identify the devices, then run `dnf search firmware` (replace
@@ -324,7 +324,7 @@ list of packages to be installed):
   if you want to use it as the `UpdateVM` (which is normally `sys-firewall`).
 - NetVM, such as the template for `sys-net`: `qubes-core-agent-networking`
   `qubes-core-agent-network-manager` `NetworkManager-wifi`
-  `network-manager-applet` `wireless-tools` `notification-daemon`
+  `network-manager-applet` `notification-daemon`
   `gnome-keyring`. If your network devices need extra packages for a network
   VM, use the `lspci` command to identify the devices, then find the package
   that provides necessary firnware and install it. If you need utilities for

From 3ada8f6f0c41beda65357897059e6e48e1c02ec5 Mon Sep 17 00:00:00 2001
From: Sylwester Arabas <slayoo@staszic.waw.pl>
Date: Wed, 7 Feb 2024 00:42:28 +0100
Subject: [PATCH 079/332] fix hex digit number in the key upload instruction

---
 developer/code/code-signing.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/developer/code/code-signing.md b/developer/code/code-signing.md
index d22c3cf8..b92b258a 100644
--- a/developer/code/code-signing.md
+++ b/developer/code/code-signing.md
@@ -65,7 +65,7 @@ Currently, [these](https://github.com/marmarek/signature-checker/blob/master/che
 
 In the example below, we will use `keyserver.ubuntu.com`.
 
-Replace 6E2F4E7AF50A5827 with your key ID, which is the last 8 hex digits of the long number in the second line of the output above:
+Replace 6E2F4E7AF50A5827 with your key ID, which is the last 16 hex digits of the long number in the second line of the output above:
 ```
 pub   rsa3072 2021-12-30 [SC] [expires: 2023-12-30]
       87975838063F97A968D503266E2F4E7AF50A5827

From 60969a1610f6152075c8ab5efadf6c9a3417a67f Mon Sep 17 00:00:00 2001
From: Sylwester Arabas <slayoo@staszic.waw.pl>
Date: Wed, 7 Feb 2024 00:46:11 +0100
Subject: [PATCH 080/332] remove repeated code (shell session) snippet

---
 developer/code/code-signing.md | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/developer/code/code-signing.md b/developer/code/code-signing.md
index d22c3cf8..b14da08f 100644
--- a/developer/code/code-signing.md
+++ b/developer/code/code-signing.md
@@ -76,11 +76,6 @@ $ gpg --send-keys --keyserver hkps://keyserver.ubuntu.com 6E2F4E7AF50A5827
 gpg: sending key 6E2F4E7AF50A5827 to hkps://keyserver.ubuntu.com
 ```
 
-```
-$ gpg --send-keys --keyserver hkps://keyserver.ubuntu.com 6E2F4E7AF50A5827
-gpg: sending key 6E2F4E7AF50A5827 to hkps://keyserver.ubuntu.com
-```
-
 ## Using PGP with Git
 
 If you're submitting a patch via GitHub (or a similar Git server), please sign

From 5e2c457b9bfc32aebb0c7f41b676ebc13b7b49a9 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Tue, 13 Feb 2024 03:59:36 -0800
Subject: [PATCH 081/332] Add Fedora 39 to supported templates

QubesOS/qubes-issues#8499
---
 user/downloading-installing-upgrading/supported-releases.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/downloading-installing-upgrading/supported-releases.md b/user/downloading-installing-upgrading/supported-releases.md
index 977806e0..5bbcf993 100644
--- a/user/downloading-installing-upgrading/supported-releases.md
+++ b/user/downloading-installing-upgrading/supported-releases.md
@@ -57,8 +57,8 @@ It is the responsibility of each distribution to clearly notify its users in adv
 
 | Qubes OS    | Fedora | Debian |
 | ----------- | ------ | ------ |
-| Release 4.1 | 38     | 11, 12 |
-| Release 4.2 | 38     | 12     |
+| Release 4.1 | 38, 39 | 11, 12 |
+| Release 4.2 | 38, 39 | 12     |
 
 ### Note on Debian support
 

From 7eaacf0b21d259eadeb06f643ce27faf6103b4a7 Mon Sep 17 00:00:00 2001
From: deeplow <deeplower@protonmail.com>
Date: Sat, 17 Feb 2024 14:36:07 +0000
Subject: [PATCH 082/332] FIXUP: use instead qubes-dist-upgrade tool

---
 .../upgrade/4_2.md                            | 41 +++++++------------
 1 file changed, 15 insertions(+), 26 deletions(-)

diff --git a/user/downloading-installing-upgrading/upgrade/4_2.md b/user/downloading-installing-upgrading/upgrade/4_2.md
index 058d481b..ba088be1 100644
--- a/user/downloading-installing-upgrading/upgrade/4_2.md
+++ b/user/downloading-installing-upgrading/upgrade/4_2.md
@@ -22,37 +22,26 @@ data.
 If you would prefer to perform a clean installation rather than upgrading
 in-place:
 
-1. Create a
+1. (optional) Run the updater to ensure all of your templates are in their latest version.
+2. Install the `qubes-dist-upgrade` tool. This is the inplace upgrade tool, which is not what we're doing. However it will needed in order to prepare the templates for the 4.2 version. You install it with the following command in the dom0 terminal:
+
+       sudo qubes-dom0-update -y qubes-dist-upgrade
+
+3. Change your templates to use the 4.2 repositories instead of the 4.1 ones. You do this with the following command in the dom0 terminal:
+
+       qubes-dist-upgrade --template-standalone-upgrade
+
+    **Note**: This step is critical to ensure the templates will receive updates once Qubes 4.1 reaches end-of-life (EOL) and was missing in previous clean installation instructions.
+
+4. Create a
    [backup](/doc/how-to-back-up-restore-and-migrate/#creating-a-backup) of your
    current installation.
-2. [Download](/downloads/) the latest 4.2 release.
-3. Follow the [installation guide](/doc/installation-guide/) to install Qubes
+5. [Download](/downloads/) the latest 4.2 release.
+6. Follow the [installation guide](/doc/installation-guide/) to install Qubes
    4.1.
-4. [Restore from your
+7. [Restore from your
    backup](/doc/how-to-back-up-restore-and-migrate/#restoring-from-a-backup) on
    your new 4.2 installation.
-5. In each old the old templates update the Qubes software sources from 4.1 to Qubes 4.2.
-   > **Note**: If the templates were first installed on a version older than
-   > Qubes 4.1, you should reinstall them. For example, your first Qubes install
-   > was 4.0 and you've been upgrading to Qubes 4.2 via clean install ever since,
-   > then this affects you and you should instead use the templates that come
-   > preinstalled in 4.2.
-
-   If the above note does not apply, you should open a teminal in each of the
-   imported templates and running the following commands:
-   - **Debian-based templates**:
-     ```
-     sudo sed -i 's/r4.1/r4.2/g' /etc/apt/sources.list.d/qubes-r4.list
-     sudo sed -i 's|\[arch=amd64\]|\[arch=amd64 signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg \]|g' /etc/apt/sources.list.d/qubes-r4.list
-     sudo apt update
-     sudo apt upgrade
-     ```
-   - **Fedora-based templates**:
-     ```
-     sudo sed -i 's/r4.1/r4.2/g' /etc/yum.repos.d/qubes-r4.repo
-     sudo sed -i 's/RPM-GPG-KEY-qubes-4.1-/RPM-GPG-KEY-qubes-4.2-/g' /etc/yum.repos.d/qubes-r4.repo
-     sudo dnf update
-     ```
 
 ## In-place upgrade
 

From 1d540888fe1e84d1deef10e413545f3ec9a5fb60 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Sat, 17 Feb 2024 09:38:23 -0800
Subject: [PATCH 083/332] Add template upgrade problem to list of known issues

References QubesOS/qubes-doc#1345 and QubesOS/qubes-issues#8701
---
 developer/releases/4_2/release-notes.md | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/developer/releases/4_2/release-notes.md b/developer/releases/4_2/release-notes.md
index 7b4dbc58..649f5571 100644
--- a/developer/releases/4_2/release-notes.md
+++ b/developer/releases/4_2/release-notes.md
@@ -42,9 +42,13 @@ The new Qubes OS Policy Editor tool:
 
 ## Known issues
 
-- DomU firewalls have completely switched to nftables. Users should add their custom rules to the `custom-input` and `custom-forward` chains. ([#5031](https://github.com/QubesOS/qubes-issues/issues/5031), [#6062](https://github.com/QubesOS/qubes-issues/issues/6062))
+- DomU firewalls have completely switched to nftables. Users should add their custom rules to the `custom-input` and `custom-forward` chains. (For more information, see issues [#5031](https://github.com/QubesOS/qubes-issues/issues/5031) and [#6062](https://github.com/QubesOS/qubes-issues/issues/6062).)
 
-For a full list of open bug reports affecting 4.2, please see [here](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+label%3Aaffects-4.2+label%3A%22T%3A+bug%22+is%3Aopen). We strongly recommend [updating Qubes OS](/doc/how-to-update/) immediately after installation in order to apply any and all available bug fixes.
+- Templates continue to target their original Qubes OS release repos even after both the templates and Qubes OS itself have been upgraded to newer releases. If you are using fresh templates, this does not affect you. However, if you are migrating existing templates from a pre-4.2.0 installation, then please see [qubes-doc PR #1345](https://github.com/QubesOS/qubes-doc/pull/1345) and issue [#8701](https://github.com/QubesOS/qubes-issues/issues/8701).
+
+Also see the [full list of open bug reports affecting Qubes 4.2](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+label%3Aaffects-4.2+label%3A%22T%3A+bug%22+is%3Aopen).
+
+We strongly recommend [updating Qubes OS](/doc/how-to-update/) immediately after installation in order to apply all available bug fixes.
 
 ## Download
 

From df40f5eacfa93820e4050274672707d30f6eabc6 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sun, 18 Feb 2024 00:42:52 +0000
Subject: [PATCH 084/332] Add note on policies to glossary

---
 user/reference/glossary.md | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/user/reference/glossary.md b/user/reference/glossary.md
index 3e2c010d..98649dd4 100644
--- a/user/reference/glossary.md
+++ b/user/reference/glossary.md
@@ -128,10 +128,22 @@ example, it is common for the net qube of an [app qube](#app-qube) to be the
 [service qube](#service-qube) `sys-firewall`, which in turn uses `sys-net` as
 its net qube. 
 
+* If a qube does not have a net qube (i.e., its `netvm` is set to `None`), then
+  that qube is offline. It is disconnected from all networking.
+
 * The name `netvm` derives from "Networking Virtual Machine." Before Qubes 4.0,
   there was a type of [service qube](#service-qube) called a "NetVM." The name
   of the `netvm` property is a holdover from that era.
 
+## policies
+
+In Qubes OS, "policies" govern interactions between qubes, powered by [Qubes' qrexec system](https://www.qubes-os.org/doc/qrexec/).
+A single policy is a rule applied to a qube or set of qubes, that governs how and when information or assets may be shared with other qubes.  
+An example is the rules governing how files can be copied between qubes.  
+Policy rules are grouped together in files under `/etc/qubes/policy.d`  
+Policies are an important part of what makes Qubes OS special.
+
+
 ## qube
 
 A secure compartment in Qubes OS. Currently, qubes are implemented as Xen
@@ -145,8 +157,7 @@ still be called "qubes."
 
 * Note that starting a sentence with the plural of "qube" (i.e., "Qubes...")
   can be ambiguous, since it may not be clear whether the referent is a
-  plurality of qubes or [Qubes OS](#qubes-os). You may wish to rephrase
-  sentences in order to avoid this ambiguity.
+  plurality of qubes or [Qubes OS](#qubes-os).
 
 * Example usage: "In Qubes OS, you do your banking in your 'banking' qube and
   your web surfing in your 'untrusted' qube. That way, if your 'untrusted' qube
@@ -210,5 +221,5 @@ See [Templates](/doc/templates/).
 
 ## VM
 
-An abbreviation for "virtual machine." A software implementation of a machine
-(for example, a computer) that executes programs like a physical machine.
+An abbreviation for "virtual machine." A software implementation of a computer
+that provides the functionality of a physical machine.

From 75102ad8ad13115ab4b30edaebf1b372f150dd18 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Sun, 18 Feb 2024 13:56:07 -0800
Subject: [PATCH 085/332] Update description of known template upgrade issue

For more information, see:
- https://github.com/QubesOSqubes-doc/commit/1d540888fe1e84d1deef10e413545f3ec9a5fb60#r138763242
- https://github.com/QubesOS/qubes-issues/issues/8701
- https://github.com/QubesOS/qubes-doc/pull/1345
---
 developer/releases/4_2/release-notes.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/developer/releases/4_2/release-notes.md b/developer/releases/4_2/release-notes.md
index 649f5571..109becca 100644
--- a/developer/releases/4_2/release-notes.md
+++ b/developer/releases/4_2/release-notes.md
@@ -44,7 +44,7 @@ The new Qubes OS Policy Editor tool:
 
 - DomU firewalls have completely switched to nftables. Users should add their custom rules to the `custom-input` and `custom-forward` chains. (For more information, see issues [#5031](https://github.com/QubesOS/qubes-issues/issues/5031) and [#6062](https://github.com/QubesOS/qubes-issues/issues/6062).)
 
-- Templates continue to target their original Qubes OS release repos even after both the templates and Qubes OS itself have been upgraded to newer releases. If you are using fresh templates, this does not affect you. However, if you are migrating existing templates from a pre-4.2.0 installation, then please see [qubes-doc PR #1345](https://github.com/QubesOS/qubes-doc/pull/1345) and issue [#8701](https://github.com/QubesOS/qubes-issues/issues/8701).
+- Templates restored in 4.2 from a pre-4.2 backup continue to target their original Qubes OS release repos. If you are using fresh templates on a clean 4.2 installation, or if you performed an [in-place upgrade from 4.1 to 4.2](/doc/upgrade/4.2/#in-place-upgrade), then this does not affect you. (For more information, see issue [#8701](https://github.com/QubesOS/qubes-issues/issues/8701).)
 
 Also see the [full list of open bug reports affecting Qubes 4.2](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+label%3Aaffects-4.2+label%3A%22T%3A+bug%22+is%3Aopen).
 

From 0d34d104d90a33eb986d7c05b49d42e0087354c1 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sun, 18 Feb 2024 23:45:47 +0000
Subject: [PATCH 086/332] Move specifics of passwordless root implementation to
 developer docs. Closes PR #1296

---
 developer/system/vm-sudo.md | 50 +++++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 developer/system/vm-sudo.md

diff --git a/developer/system/vm-sudo.md b/developer/system/vm-sudo.md
new file mode 100644
index 00000000..2ed578d0
--- /dev/null
+++ b/developer/system/vm-sudo.md
@@ -0,0 +1,50 @@
+---
+lang: en
+layout: doc
+permalink: /doc/vm-sudo-implementation/
+redirect_from:
+- /en/doc/vm-sudo-implementation/
+- /doc/VMSudo-implementation/
+ref: 341
+title: Passwordless root access in qubes
+---
+
+The rationale behind passwordless root in qubes is set out [here](/doc/vm-sudo).  Implementation is by the qubes-core-agent-passwordless-root package.
+
+This page sets out the configuration changes made, with (not necessary complete) list of mechanisms depending on each of them:
+
+1. sudo (`/etc/sudoers.d/qubes`):
+
+    ```
+    Defaults !requiretty
+    %qubes ALL=(ALL) ROLE=unconfined_r TYPE=unconfined_t NOPASSWD: ALL
+
+    (...)
+    ```
+
+    - Easy user -> root access (main option for the user).
+    - `qvm-usb` (not really working, as of R2).
+
+2. PolicyKit (`/etc/polkit-1/rules.d/00-qubes-allow-all.rules`):
+
+    ```
+    //allow any action, detailed reasoning in sudoers.d/qubes
+    polkit.addRule(function(action,subject) { if (subject.isInGroup("qubes")) return polkit.Result.YES; });
+
+    ```
+
+    PAM (`/etc/pam.d/su.qubes` or `/usr/share/pam-configs/su.qubes`)
+    ```
+    auth    	sufficient	pam_succeed_if.so use_uid user ingroup qubes
+    ```
+
+    - NetworkManager configuration from normal user (`nm-applet`).
+    - Updates installation (`gpk-update-viewer`).
+    - User can use pkexec just like sudo Note: above is needed mostly because Qubes user GUI session isn't treated by PolicyKit/logind as "local" session because of the way in which X server and session is started.
+      Perhaps we will address this issue in the future, but this is really low priority.
+      Patches welcomed anyway.
+
+3. Empty root password:
+    - Used for access to 'root' account from text console (`qvm-console-dispvm`) - the only way to access the VM when GUI isn't working.
+    - Can be used for easy 'su -' from user to root.
+

From fdcb21e1786a8e89b31568ad4eec60bcf844b1e0 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Mon, 19 Feb 2024 00:32:00 +0000
Subject: [PATCH 087/332] Update page on passwordless root. Confirm that
 Joanna's statement continues to reflect the views of the developers. Provide
 details on replacing passwordless root. Implementation details are moved to
 developer docs.

---
 user/security-in-qubes/vm-sudo.md | 56 ++++++++-----------------------
 1 file changed, 14 insertions(+), 42 deletions(-)

diff --git a/user/security-in-qubes/vm-sudo.md b/user/security-in-qubes/vm-sudo.md
index 7141102d..08606534 100644
--- a/user/security-in-qubes/vm-sudo.md
+++ b/user/security-in-qubes/vm-sudo.md
@@ -10,7 +10,7 @@ ref: 165
 title: Passwordless root access in qubes
 ---
 
-Background (`/etc/sudoers.d/qubes` in VM):
+The background to passswordless root access is summarised in this statement, that used to be found at `/etc/sudoers.d/qubes` in each qube:
 
 ```
 user ALL=(ALL) NOPASSWD: ALL
@@ -59,59 +59,31 @@ user ALL=(ALL) NOPASSWD: ALL
 #
 # joanna.
 ```
+The core of this statement continues to reflect the views of the Qubes developers.
 
-Below is a complete list of configuration made according to the above statement, with (not necessary complete) list of mechanisms depending on each of them:
+Passwordless root is provided by the `qubes-core-agent-passwordless-root package`.  
+Details of the implementation are [here](/doc/vm-sudo-implementation)
 
-1. sudo (`/etc/sudoers.d/qubes`):
+[Minimal templates](/doc/templates/minimal/), which are intended for use by advanced users, do not have this package installed by default.
 
-    ```
-    user ALL=(ALL) NOPASSWD: ALL
-    (...)
-    ```
+Replacing passwordless root access
+----------------------------------
 
-    - Easy user -> root access (main option for the user).
-    - `qvm-usb` (not really working, as of R2).
+Some users may wish to modify their system by enabling user/root isolation in qubes.  
+We do not support this in any packages, but users are free to remove the qubes-core-agent-passwordless-root package if they wish, using standard packaging tools.
 
-2. PolicyKit (`/etc/polkit-1/rules.d/00-qubes-allow-all.rules`):
-
-    ```
-    //allow any action, detailed reasoning in sudoers.d/qubes
-    polkit.addRule(function(action,subject) { return polkit.Result.YES; });
-    ```
-
-    and `/etc/polkit-1/localauthority/50-local.d/qubes-allow-all.pkla`:
-
-    ```
-    [Qubes allow all]
-    Identity=*
-    Action=*
-    ResultAny=yes
-    ResultInactive=yes
-    ResultActive=yes
-    ```
-
-    - NetworkManager configuration from normal user (`nm-applet`).
-    - Updates installation (`gpk-update-viewer`).
-    - User can use pkexec just like sudo Note: above is needed mostly because Qubes user GUI session isn't treated by PolicyKit/logind as "local" session because of the way in which X server and session is started.
-      Perhaps we will address this issue in the future, but this is really low priority.
-      Patches welcomed anyway.
-
-3. Empty root password:
-    - Used for access to 'root' account from text console (`qvm-console-dispvm`) - the only way to access the VM when GUI isn't working.
-    - Can be used for easy 'su -' from user to root.
+Root access can then be gained from dom0 by (e.g) `qvm-run -u root QUBE qubes-run-terminal`, or `qvm-console-dispvm QUBE`.
 
 Replacing passwordless root access with Dom0 user prompt
 --------------------------------------------------------
 
-While the Qubes developers support the statement above, some Qubes users may wish to enable user/root isolation in VMs anyway.
-We do not support this in any of our packages, but of course nothing is preventing a user from modifying his or her own system.
-A list of steps to do so is provided in the [Qubes community guide, Replacing passwordless root with a dom0 prompt
-](https://forum.qubes-os.org/t/replacing-passwordless-root-with-a-dom0-prompt/19074) **without any guarantee of safety, accuracy, or completeness.
+An alternative approach is to enable user/root isolation by using a dom0 generated prompt.  
+A list of steps to do so is provided in the [Qubes community guide, Replacing passwordless root with a dom0 prompt](https://forum.qubes-os.org/t/replacing-passwordless-root-with-a-dom0-prompt/19074) **without any guarantee of safety, accuracy, or completeness.
 Proceed at your own risk.
 Do not rely on this for extra security.**
 
 Dom0 passwordless root access
 -----------------------------
 
-There is also passwordless user->root access in dom0.
-As stated in the comment in sudo configuration there (which is different from the one in individual qubes), there is really no point in user/root isolation, because all the user data (and VM management interface) is already accessible from dom0 user level, so there is nothing more to get from dom0 root account.
+There is also passwordless user->root access in dom0.  
+As stated in the comment in `/etc/sudoers.d/qubes` there is really no point in user/root isolation in dom0, because all user data (and the whole Qubes management interface) is already accessible to the user, so there is nothing more to be gained from the dom0 root account.

From 565d801d24dff91e6eab5a2c2197dded689d5993 Mon Sep 17 00:00:00 2001
From: Patrick Schleizer <adrelanos@whonix.org>
Date: Mon, 19 Feb 2024 05:56:40 -0500
Subject: [PATCH 088/332] minor vm-sudo.md formatting improvements

---
 user/security-in-qubes/vm-sudo.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/security-in-qubes/vm-sudo.md b/user/security-in-qubes/vm-sudo.md
index 08606534..b2bba946 100644
--- a/user/security-in-qubes/vm-sudo.md
+++ b/user/security-in-qubes/vm-sudo.md
@@ -61,8 +61,8 @@ user ALL=(ALL) NOPASSWD: ALL
 ```
 The core of this statement continues to reflect the views of the Qubes developers.
 
-Passwordless root is provided by the `qubes-core-agent-passwordless-root package`.  
-Details of the implementation are [here](/doc/vm-sudo-implementation)
+Passwordless root is provided by the `qubes-core-agent-passwordless-root` package.
+Details of the implementation are [here](/doc/vm-sudo-implementation).
 
 [Minimal templates](/doc/templates/minimal/), which are intended for use by advanced users, do not have this package installed by default.
 

From a2c7ae70bb7322463ebadc01e19a97c01bbdf58b Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Wed, 21 Feb 2024 14:03:24 +0000
Subject: [PATCH 089/332] Reinstate new line in vm-sudo.md

---
 user/security-in-qubes/vm-sudo.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/security-in-qubes/vm-sudo.md b/user/security-in-qubes/vm-sudo.md
index b2bba946..3001c367 100644
--- a/user/security-in-qubes/vm-sudo.md
+++ b/user/security-in-qubes/vm-sudo.md
@@ -61,7 +61,7 @@ user ALL=(ALL) NOPASSWD: ALL
 ```
 The core of this statement continues to reflect the views of the Qubes developers.
 
-Passwordless root is provided by the `qubes-core-agent-passwordless-root` package.
+Passwordless root is provided by the `qubes-core-agent-passwordless-root` package.  
 Details of the implementation are [here](/doc/vm-sudo-implementation).
 
 [Minimal templates](/doc/templates/minimal/), which are intended for use by advanced users, do not have this package installed by default.

From da276b305da33c275f54eea9b52c608a68bc2f78 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Mon, 26 Feb 2024 15:33:24 -0800
Subject: [PATCH 090/332] Sort Qubes-certified computers in reverse
 chronological order

---
 user/hardware/certified-hardware.md | 62 ++++++++++++++---------------
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/user/hardware/certified-hardware.md b/user/hardware/certified-hardware.md
index 42afb236..9be78b53 100644
--- a/user/hardware/certified-hardware.md
+++ b/user/hardware/certified-hardware.md
@@ -23,37 +23,13 @@ You may also be interested in the [community-recommended hardware](https://forum
 
 Qubes-certified computers are certified for a [major release](/doc/version-scheme/) and regularly tested by the Qubes developers to ensure compatibility with all of Qubes' features within that major release. The developers test all new updates within that major release to ensure that no regressions are introduced.
 
-The current Qubes-certified models are listed below in chronological order of certification.
+The current Qubes-certified models are listed below in reverse chronological order of certification.
 
-### Insurgo PrivacyBeast X230
+### Star Labs StarBook
 
-[![Photo of the Insurgo PrivacyBeast X230](/attachment/site/insurgo-privacybeast-x230.png)](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/)
+[![Photo of the Star Labs StarBook](/attachment/site/starlabs-starbook.png)](https://starlabs.systems/pages/starbook)
 
-The [Insurgo PrivacyBeast X230](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/) is a laptop based on the ThinkPad X230. It is certified for Qubes OS 4.X.
-
-### NitroPad X230
-
-[![Photo of the NitroPad X230](/attachment/site/nitropad-x230.jpg)](https://shop.nitrokey.com/shop/product/nitropad-x230-67)
-
-The [NitroPad X230](https://shop.nitrokey.com/shop/product/nitropad-x230-67) is a laptop based on the ThinkPad X230. It is certified for Qubes OS 4.X.
-
-### NitroPad T430
-
-[![Photo of the NitroPad T430](/attachment/site/nitropad-t430.jpg)](https://shop.nitrokey.com/shop/product/nitropad-t430-119)
-
-The [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119) is a laptop based on the ThinkPad T430. It is certified for Qubes OS 4.X.
-
-### Dasharo FidelisGuard Z690
-
-[![Photo of the Dasharo FidelisGuard Z690](/attachment/site/dasharo-fidelisguard-z690.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
-
-The [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is a desktop based on the MSI PRO Z690-A DDR4 motherboard. It is certified for Qubes OS 4.X.
-
-### NovaCustom NV41 Series
-
-[![Photo of the NovaCustom NV41 Series](/attachment/site/novacustom-nv41-series.png)](https://novacustom.com/product/nv41-series/)
-
-The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is a 14-inch custom laptop. It is certified for Qubes OS 4.X.
+The [Star Labs StarBook](https://starlabs.systems/pages/starbook) is a 14-inch laptop. It is certified for Qubes OS 4.X.
 
 ### NitroPC Pro
 
@@ -61,11 +37,35 @@ The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is a 1
 
 The [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523) is a desktop based on the MSI PRO Z690-A DDR5 motherboard. It is certified for Qubes OS 4.X.
 
-### Star Labs StarBook
+### NovaCustom NV41 Series
 
-[![Photo of the Star Labs StarBook](/attachment/site/starlabs-starbook.png)](https://starlabs.systems/pages/starbook)
+[![Photo of the NovaCustom NV41 Series](/attachment/site/novacustom-nv41-series.png)](https://novacustom.com/product/nv41-series/)
 
-The [Star Labs StarBook](https://starlabs.systems/pages/starbook) is a 14-inch laptop. It is certified for Qubes OS 4.X.
+The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is a 14-inch custom laptop. It is certified for Qubes OS 4.X.
+
+### Dasharo FidelisGuard Z690
+
+[![Photo of the Dasharo FidelisGuard Z690](/attachment/site/dasharo-fidelisguard-z690.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
+
+The [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is a desktop based on the MSI PRO Z690-A DDR4 motherboard. It is certified for Qubes OS 4.X.
+
+### NitroPad T430
+
+[![Photo of the NitroPad T430](/attachment/site/nitropad-t430.jpg)](https://shop.nitrokey.com/shop/product/nitropad-t430-119)
+
+The [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119) is a laptop based on the ThinkPad T430. It is certified for Qubes OS 4.X.
+
+### NitroPad X230
+
+[![Photo of the NitroPad X230](/attachment/site/nitropad-x230.jpg)](https://shop.nitrokey.com/shop/product/nitropad-x230-67)
+
+The [NitroPad X230](https://shop.nitrokey.com/shop/product/nitropad-x230-67) is a laptop based on the ThinkPad X230. It is certified for Qubes OS 4.X.
+
+### Insurgo PrivacyBeast X230
+
+[![Photo of the Insurgo PrivacyBeast X230](/attachment/site/insurgo-privacybeast-x230.png)](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/)
+
+The [Insurgo PrivacyBeast X230](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/) is a laptop based on the ThinkPad X230. It is certified for Qubes OS 4.X.
 
 ## Become hardware certified
 

From 0c60408a5534b4a633e4cc08b0988c35c52f5519 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Mon, 26 Feb 2024 15:37:33 -0800
Subject: [PATCH 091/332] Drop ".X" in release numbers

---
 user/hardware/certified-hardware.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/user/hardware/certified-hardware.md b/user/hardware/certified-hardware.md
index 9be78b53..d6096c18 100644
--- a/user/hardware/certified-hardware.md
+++ b/user/hardware/certified-hardware.md
@@ -29,43 +29,43 @@ The current Qubes-certified models are listed below in reverse chronological ord
 
 [![Photo of the Star Labs StarBook](/attachment/site/starlabs-starbook.png)](https://starlabs.systems/pages/starbook)
 
-The [Star Labs StarBook](https://starlabs.systems/pages/starbook) is a 14-inch laptop. It is certified for Qubes OS 4.X.
+The [Star Labs StarBook](https://starlabs.systems/pages/starbook) is a 14-inch laptop. It is certified for Qubes OS 4.
 
 ### NitroPC Pro
 
 [![Photo of the NitroPC Pro](/attachment/posts/nitropc-pro.jpg)](https://shop.nitrokey.com/shop/product/nitropc-pro-523)
 
-The [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523) is a desktop based on the MSI PRO Z690-A DDR5 motherboard. It is certified for Qubes OS 4.X.
+The [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523) is a desktop based on the MSI PRO Z690-A DDR5 motherboard. It is certified for Qubes OS 4.
 
 ### NovaCustom NV41 Series
 
 [![Photo of the NovaCustom NV41 Series](/attachment/site/novacustom-nv41-series.png)](https://novacustom.com/product/nv41-series/)
 
-The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is a 14-inch custom laptop. It is certified for Qubes OS 4.X.
+The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is a 14-inch custom laptop. It is certified for Qubes OS 4.
 
 ### Dasharo FidelisGuard Z690
 
 [![Photo of the Dasharo FidelisGuard Z690](/attachment/site/dasharo-fidelisguard-z690.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
 
-The [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is a desktop based on the MSI PRO Z690-A DDR4 motherboard. It is certified for Qubes OS 4.X.
+The [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is a desktop based on the MSI PRO Z690-A DDR4 motherboard. It is certified for Qubes OS 4.
 
 ### NitroPad T430
 
 [![Photo of the NitroPad T430](/attachment/site/nitropad-t430.jpg)](https://shop.nitrokey.com/shop/product/nitropad-t430-119)
 
-The [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119) is a laptop based on the ThinkPad T430. It is certified for Qubes OS 4.X.
+The [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119) is a laptop based on the ThinkPad T430. It is certified for Qubes OS 4.
 
 ### NitroPad X230
 
 [![Photo of the NitroPad X230](/attachment/site/nitropad-x230.jpg)](https://shop.nitrokey.com/shop/product/nitropad-x230-67)
 
-The [NitroPad X230](https://shop.nitrokey.com/shop/product/nitropad-x230-67) is a laptop based on the ThinkPad X230. It is certified for Qubes OS 4.X.
+The [NitroPad X230](https://shop.nitrokey.com/shop/product/nitropad-x230-67) is a laptop based on the ThinkPad X230. It is certified for Qubes OS 4.
 
 ### Insurgo PrivacyBeast X230
 
 [![Photo of the Insurgo PrivacyBeast X230](/attachment/site/insurgo-privacybeast-x230.png)](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/)
 
-The [Insurgo PrivacyBeast X230](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/) is a laptop based on the ThinkPad X230. It is certified for Qubes OS 4.X.
+The [Insurgo PrivacyBeast X230](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/) is a laptop based on the ThinkPad X230. It is certified for Qubes OS 4.
 
 ## Become hardware certified
 

From 8c3db1074ebe671c47b094f702e2d7953d529abd Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Wed, 28 Feb 2024 11:32:37 -0800
Subject: [PATCH 092/332] Add NitroPC Pro 2 to list of Qubes-certified
 computers

See QubesOS/qubes-posts#128
---
 user/hardware/certified-hardware.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/user/hardware/certified-hardware.md b/user/hardware/certified-hardware.md
index d6096c18..dbe50dd3 100644
--- a/user/hardware/certified-hardware.md
+++ b/user/hardware/certified-hardware.md
@@ -25,6 +25,12 @@ Qubes-certified computers are certified for a [major release](/doc/version-schem
 
 The current Qubes-certified models are listed below in reverse chronological order of certification.
 
+### NitroPC Pro 2
+
+[![Photo of the NitroPC Pro 2](/attachment/posts/nitropc-pro.jpg)](https://shop.nitrokey.com/shop/nitropc-pro-2-523)
+
+The [NitroPC Pro 2](https://shop.nitrokey.com/shop/nitropc-pro-2-523) is a desktop based on the MSI PRO Z790-P DDR5 motherboard. It is certified for Qubes OS 4.
+
 ### Star Labs StarBook
 
 [![Photo of the Star Labs StarBook](/attachment/site/starlabs-starbook.png)](https://starlabs.systems/pages/starbook)

From 896aaf5681c69a9bb3c80e867dd2a6319f699cae Mon Sep 17 00:00:00 2001
From: ooops <kennethrrosen@proton.me>
Date: Sat, 2 Mar 2024 02:11:33 +0100
Subject: [PATCH 093/332] Edit for grammar and clarity qrexec.md

---
 developer/services/qrexec.md | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/developer/services/qrexec.md b/developer/services/qrexec.md
index dc8039da..fbdc7327 100644
--- a/developer/services/qrexec.md
+++ b/developer/services/qrexec.md
@@ -22,14 +22,14 @@ However, the OS needs a mechanism to allow the administrative domain (dom0) to f
 For instance, when a user selects an application from the KDE menu, it should start in the selected VM.
 Also, it is often useful to be able to pass stdin/stdout/stderr from an application running in a VM to dom0 (and the other way around).
 (For example, so that a VM can notify dom0 that there are updates available for it).
-By default, Qubes allows VMs initiate such communications in specific circumstances.
-The qrexec framework generalizes this process by providing a remote procedure call (RPC) protocol for the Qubes architecture.
+By default, Qubes allows VMs to initiate such communications in specific circumstances.
+The qrexec framework generalizes this process by providing a remote procedure call (RPC) for the Qubes architecture.
 It allows users and developers to use and design secure inter-VM tools.
 
 ## Qrexec basics: architecture and examples
 
 Qrexec is built on top of *vchan*, a Xen library providing data links between VMs.
-During domain startup , a process named `qrexec-daemon` is started in dom0, and a process named `qrexec-agent` is started in the VM.
+During domain startup, a process named `qrexec-daemon` is started in dom0, and a process named `qrexec-agent` is started in the VM.
 They are connected over a **vchan** channel.
 `qrexec-daemon` listens for connections from a dom0 utility named `qrexec-client`.
 Let's say we want to start a process (call it `VMprocess`) in a VM (`someVM`).
@@ -47,18 +47,18 @@ For example, the following command creates an empty file called `hello-world.txt
 $ qrexec-client -e -d someVM user:'touch hello-world.txt'
 ```
 
-The string before the colon specifies what user to run the command as.
-The `-e` flag tells `qrexec-client` to exit immediately after sending the execution request and receiving a status code from `qrexec-agent` (whether the process creation succeeded).
+The string before the colon specifies which user will run the command.
+The `-e` flag tells `qrexec-client` to exit immediately after sending the execution request and receiving a status code from `qrexec-agent` (if the process creation succeeded).
 With this option, no further data is passed between the domains.
-By contrast, the following command demonstrates an open channel between dom0 and someVM (in this case, a remote shell):
+The following command demonstrates an open channel between dom0 and someVM (in this case, a remote shell):
 
 ```
 $ qrexec-client -d someVM user:bash
 ```
 
 The `qvm-run` command is heavily based on `qrexec-client`.
-It also takes care of additional activities, e.g. starting the domain if it is not up yet and starting the GUI daemon.
-Thus, it is usually more convenient to use `qvm-run`.
+It also handles additional activities, e.g. starting the domain if the domain is not up yet and starting the GUI daemon.
+It is usually more convenient to use `qvm-run`.
 
 There can be an almost arbitrary number of `qrexec-client` processes for a given domain.
 The limiting factor is the number of available vchan channels, which depends on the underlying hypervisor, as well the domain's OS.
@@ -70,17 +70,17 @@ For more details on the qrexec framework and protocol, see "[Qubes RPC internals
 Some common tasks (like copying files between VMs) have an RPC-like structure: a process in one VM (say, the file sender) needs to invoke and send/receive data to some process in other VM (say, the file receiver).
 The Qubes RPC framework was created to securely facilitate a range of such actions.
 
-Obviously, inter-VM communication must be tightly controlled to prevent one VM from taking control of another, possibly more privileged, VM.
-Therefore the design decision was made to pass all control communication via dom0, that can enforce proper authorization.
-Then, it is natural to reuse the already-existing qrexec framework.
+Inter-VM communication must be tightly controlled to prevent one VM from taking control of another, possibly more privileged, VM.
+The design decision was made to pass all control communication via dom0 which can enforce proper authorization.
+It is therefore natural to reuse the already-existing qrexec framework.
 
-Also, note that bare qrexec provides `VM <-> dom0` connectivity, but the command execution is always initiated by dom0.
-There are cases when VM needs to invoke and send data to a command in dom0 (e.g. to pass information on newly installed `.desktop` files).
-Thus, the framework allows dom0 to be the RPC target as well.
+Note that bare qrexec provides `VM <-> dom0` connectivity, but the command execution is always initiated by dom0.
+There are cases when a VM needs to invoke and send data to a command in dom0 (e.g. to pass information on newly installed `.desktop` files).
+This framework allows dom0 to be the RPC target as well.
 
 Thanks to the framework, RPC programs are very simple -- both RPC client and server just use their stdin/stdout to pass data.
-The framework does all the inner work to connect these processes to each other via `qrexec-daemon` and `qrexec-agent`.
-Additionally, disposable VMs are tightly integrated -- RPC to a DisposableVM is identical to RPC to a normal domain, all one needs is to pass `@dispvm` as the remote domain name.
+The framework does all the inner work to connect the processes to eachother via `qrexec-daemon` and `qrexec-agent`.
+Disposable VMs are tightly integrated -- RPC to a DisposableVM is identical to RPC to an AppVM or StandaloneVM: all one needs is to pass `@dispvm` as the remote domain name.
 
 ## Qubes RPC administration
 

From e3dd9bc6a5c03e4efa19114179a4060560085636 Mon Sep 17 00:00:00 2001
From: Christian Foerster <christian.foerster@mailfence.com>
Date: Sat, 2 Mar 2024 22:58:43 +0100
Subject: [PATCH 094/332] include NitroKey 3, MFA PR header

---
 .../security-in-qubes/{yubi-key.md => mfa.md} | 161 ++++++++++++------
 1 file changed, 108 insertions(+), 53 deletions(-)
 rename user/security-in-qubes/{yubi-key.md => mfa.md} (51%)

diff --git a/user/security-in-qubes/yubi-key.md b/user/security-in-qubes/mfa.md
similarity index 51%
rename from user/security-in-qubes/yubi-key.md
rename to user/security-in-qubes/mfa.md
index a4cdfc68..2a8a73a2 100644
--- a/user/security-in-qubes/yubi-key.md
+++ b/user/security-in-qubes/mfa.md
@@ -1,66 +1,75 @@
 ---
 lang: en
 layout: doc
-permalink: /doc/yubikey/
+permalink: /doc/mfa/
 redirect_from:
 - /doc/yubi-key/
 - /en/doc/yubi-key/
 - /doc/YubiKey/
+- /doc/yubikey/
 ref: 169
-title: YubiKey
+title: Multi-factor Login
 ---
 
-"The YubiKey is a hardware authentication device manufactured by Yubico to
-protect access to computers, networks, and online services that supports
-one-time passwords (OTP), public-key cryptography, and authentication, and the
-Universal 2nd Factor (U2F) and FIDO2 protocols[1] developed by the FIDO
-Alliance." ([Wikipedia](https://en.wikipedia.org/wiki/YubiKey))
 
-## General usage in Qubes OS
+## Multi-factor authentication within particular qubes
 
-Most use cases for the YubiKey can be achieved exactly as described by the
+Most use cases for the hardware tokens can be achieved exactly as described by the
 manufacturer or other instructions found online. One usually just needs to
-attach the YubiKey to the corresponding app qube to get the same result (see the
-documentation on how to use [USB devices](/doc/how-to-use-usb-devices/) in Qubes
-OS accordingly). The recommended way for using CTAP in Qubes is described
+attach the token (e.g. YubiKey) to the corresponding app qube to get the same
+result (see the documentation on how to use [USB devices](/doc/how-to-use-usb-devices/)
+in Qubes OS accordingly). The recommended way for using CTAP in Qubes is described
 [here](https://www.qubes-os.org/doc/ctap-proxy/).
 
 ## Multi-factor login for Qubes OS
 
-You can use a YubiKey to enhance the user authentication in Qubes. The following
-instructions explain how to setup the YubiKey as an *additional* way to login.
+By default Qubes has two protection mechanisms against attackers. 
+The first is full disk encryption and the second the user login screen / lockscreen. 
+This article section concerns only adding multi-factor authentication to the second one.
+
+### Login with a YubiKey / NitroKey3
+
+The YubiKey / NitroKey3 is a hardware authentication device manufactured by Yubico / NitroKey
+to protect access to computers, networks, and online services that supports
+one-time passwords (OTP), public-key cryptography, and authentication, and the
+Universal 2nd Factor (U2F) and FIDO2 protocols[1] developed by the FIDO Alliance.
+
+You can use a YubiKey / NitroKey3 to enhance the user authentication in Qubes. The following
+instructions explain how to setup the YubiKey / NitroKey3 as an *additional* way to login.
 
 After setting it up, you can login by providing both - a password typed in via
-keyboard *and* the YubiKey plugged in. Someone eavesdropping your login attempt
+keyboard *and* the YubiKey / NitroKey3 plugged in. Someone eavesdropping your login attempt
 would not be able to login by only observing and remembering your password.
-Stealing your YubiKey would not suffice to login either. Only if an attacker has
-both, the password and the Yubikey, it would be possible to login (it is thus
-called [Multi-factor
-authentication](https://en.wikipedia.org/wiki/Multi-factor_authentication)).
+Stealing your YubiKey / NitroKey3 would not suffice to login either. Only if an attacker has
+both, the password and the Yubikey / NitroKey3, it would be possible to login (it is thus
+called [Multi-factor authentication](https://en.wikipedia.org/wiki/Multi-factor_authentication)).
 
 The following instructions keep your current login password untouched and
 recommends to define a new, additional password that is used in combination with
-the YubiKey only. This ensures that you a) do not accidentally lock yourself out
+the YubiKey / NitroKey3 only. This ensures that you a) do not accidentally lock yourself out
 during setup and b) you do not need to fear [shoulder
 surfing](https://en.wikipedia.org/wiki/Shoulder_surfing_(computer_security)) so
 much (i.e. by not using your standard login password in public).
 
-### Setup login with YubiKey
+#### Setup login with YubiKey / NitroKey3
 
-To use the YubiKey for multi-factor authentication you need to
+To use the YubiKey / NitroKey3 for multi-factor authentication you need to
 
-* install software for the YubiKey,
+* install software for the YubiKey / NitroKey3,
 * configure the YubiKey for the
   [Challenge-Response](https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication)
-mode,
-* store the password for YubiKey Login and the Challenge-Response secret in
+mode or the NitroKey3 for [HOTP](https://en.wikipedia.org/wiki/HMAC-based_one-time_password) mode,
+* store the password for YubiKey / NitroKey3 Login and the Challenge-Response / HOTP secret in
   dom0,
-* enable YubiKey authentication for every service you want to use it for.
+* enable YubiKey / NitroKey3 authentication for every service you want to use it for.
 
-All these requirements are described below, step by step.
+All these requirements are described below, step by step, for the YubiKey and NitroKey3.
+Note that setting up both a YubiKey and a NitroKey3 is not supported.
 
-1. Install YubiKey software in the template on which your USB VM is based.
-   Without this software the challenge-response mechanism is not working.
+1. Install YubiKey / NitroKey3 software in the template on which your USB VM is based.
+   Without this software the challenge-response / HOTP mechanism won't work.
+
+   **YubiKey**
 
    For Fedora.
 
@@ -73,24 +82,44 @@ All these requirements are described below, step by step.
     ```
     sudo apt-get install yubikey-personalization
     ```
+   
+   **NitroKey3**
+
+   Follow the installation instructions on the official [NitroKey 
+website](https://docs.nitrokey.com/software/nitropy/all-platforms/installation).
+   
+   **WARNING**: *as of February 2024 the official instructions involve using pipx to
+            install the pynitrokey package and its dependencies without any GPG
+            verification! This is not a recommended practice, but will soon be
+            fixed by NitroKey when they start providing release artifacts with
+            detached signatures on [their GitHub](https://github.com/Nitrokey/pynitrokey/releases).
+            Proper packaging and distribution for Debian and perhaps Fedora is
+            also planned for the mid-long term.*
+            **Installing packages using pip or pipx is not recommended!**
+   
+   **both**
 
    Shut down your template. Then, either reboot your USB VM (so changes inside
    the template take effect in your USB app qube) or install the packages inside
    your USB VM as well if you would like to avoid rebooting it.
 
 2. Install [qubes-app-yubikey](https://github.com/QubesOS/qubes-app-yubikey) in
-   dom0. This provides the program to authenticate with password and YubiKey.
+   dom0. This provides the program to authenticate with password and YubiKey / NitroKey3.
 
     ```
     sudo qubes-dom0-update qubes-yubikey-dom0
     ```
 
-3. Configure your YubiKey for challenge-response `HMAC-SHA1` mode. This can be
+3. Configure your YubiKey / NitroKey3:
+   
+   **YubiKey**
+   
+   Configure your YubiKey for challenge-response `HMAC-SHA1` mode. This can be
    done on any qube, e.g. a disposable (you need to [attach the
 YubiKey](https://www.qubes-os.org/doc/how-to-use-usb-devices/) to this app qube
 though) or directly on the sys-usb vm.
 
-   You need to (temporarily) install the package "yubikey-personalization-gui" and 
+   You need to (temporarily) install the package "yubikey-personalization-gui" and
    run it by typing `yubikey-personalization-gui` in the command line.
 
    - In the program go to `Challenge-Response`,
@@ -102,24 +131,51 @@ though) or directly on the sys-usb vm.
      to the vm,
    - press `Write Configuration` once you are ready.
 
-   We will refer the `Secret Key (20 bytes hex)` as `AESKEY`.
+   **NitroKey3**
+
+   Set up a new NK3 Secrets App HOTP secret by attaching the NitroKey to your
+   USB qube and running the following commands in it:
+   ```
+   AESKEY=$(echo -n "your-20-digit-secret" | base32)
+   nitropy nk3 secrets register --kind hotp --hash sha256 --digits-str 8 --counter-start 1 --touch-button loginxs $AESKEY
+   ```
+   Note that the 20 digit sequence can contain any printable ASCII character,
+   e.g. letters, numbers, punctuation marks. The actual `Secret Key (base 32)`
+   is the base32 encoded form of that sequence.
+
+   **both**
+
+   We will call the `Secret Key (20 bytes hex)` (YubiKey) or `Secret Key (base 32)` `AESKEY`.
 
    - It is recommended to keep a backup of your `AESKEY` in an offline VM used as a vault.
    - Consider keeping a backup of your `AESKEY` on paper and storing it in a safe place.
-   - If you have multiple YubiKeys for backup purposes (in case a yubikey gets
+   - If you have multiple YubiKeys for backup purposes (in case one gets
      lost, stolen or breaks) you can write the same settings into other
-YubiKeys. You can choose "Program multiple YubiKeys" in the program, make sure
-to select `Same secret for all keys` in this case.
+YubiKeys. For YubiKeys you can choose "Program multiple YubiKeys" in the program;
+ make sure to select `Same secret for all keys` in this case. For NitroKeys you can set up
+the secret for multiple of them, but you must always use the same NitroKey, because the
+HOTP counter will be incremented in dom0 as well as the used NitroKey whenever you make use
+of this method. If you want to switch to a different NitroKey later, delete the file
+`/etc/qubes/yk-keys/nk-hotp-counter` in dom0 first to make it work with a fresh NitroKey 3.
 
-4. Paste your `AESKEY` into `/etc/qubes/yk-keys/yk-secret-key.hex` in dom0.
+4. **YubiKey**
+
+   Paste your `AESKEY` into `/etc/qubes/yk-keys/yk-secret-key.hex` in dom0.
+   Note that if you had previously used a NitroKey3 with this package, you *must* delete
+   the file `/etc/qubes/yk-keys/nk-hotp-secret` or its content!
+
+   **NitroKey3**
+
+   Create the file `/etc/qubes/yk-keys/nk-hotp-secret` in dom0 and paste your `AESKEY` 
+   (in base 32 format) into it.
 
 5. As mentioned before, you need to define a new password that is only used in
-   combination with the YubiKey. You can write this password in plain text into
-`/etc/qubes/yk-keys/yk-login-pass` in dom0. This is considered safe as dom0 is
+   combination with the YubiKey / NitroKey3. You can write this password in plain text into
+`/etc/qubes/yk-keys/login-pass` in dom0. This is considered safe as dom0 is
 ultimately trusted anyway.
 
     However, if you prefer you can paste a hashed password instead into
-`/etc/qubes/yk-keys/yk-login-pass-hashed.hex` in dom0.
+`/etc/qubes/yk-keys/login-pass-hashed.hex` in dom0.
 
     You can calculate your hashed password using the following two commands.
     First run the following command to store your password in a temporary variable `password`.
@@ -141,9 +197,9 @@ ultimately trusted anyway.
     auth include yubikey
     ```
 
-    to the corresponding service file in `/etc/pam.d/` in dom0. This means, if
-you want to enable the login via YubiKey for xscreensaver (the default screen
-lock program), you add the line at the beginning of `/etc/pam.d/xscreensaver`.
+    (same for YubiKey and NitroKey3) to the corresponding service file in `/etc/pam.d/` in dom0.
+This means, if you want to enable the login via YubiKey / NitroKey3 for xscreensaver 
+(the default screen lock program), you add the line at the beginning of `/etc/pam.d/xscreensaver`.
 If you want to use the login for a tty shell, add it to `/etc/pam.d/login`. Add
 it to `/etc/pam.d/lightdm` if you want to enable the login for the default
 display manager and so on.
@@ -152,24 +208,24 @@ display manager and so on.
 these files, otherwise it will most likely not work.
 
 7. Adjust the USB VM name in case you are using something other than the default
-   `sys-usb` by editing `/etc/qubes/yk-keys/yk-vm` in dom0.
+   `sys-usb` by editing `/etc/qubes/yk-keys/vm` in dom0.
 
-### Usage
+#### Usage
 
 When you want to authenticate
 
-1. plug your YubiKey into an USB slot,
-2. enter the password associated with the YubiKey,
+1. plug your YubiKey / NitroKey3 into an USB slot,
+2. enter the password associated with the YubiKey / NitroKey3,
 3. press Enter and
-4. press the button of the YubiKey, if you configured the confirmation (it will
-   blink).
+4. press the button of the YubiKey / NitroKey3, if you configured the confirmation
+ (it will light up or blink).
 
 When everything is ok, your screen will be unlocked.
 
 In any case you can still use your normal login password, but do it in a secure
 location where no one can snoop your password.
 
-### Optional: Enforce YubiKey Login
+#### Optional: Enforce YubiKey / NitroKey3 Login
 
 Edit `/etc/pam.d/yubikey` (or appropriate file if you are using other screen locker program) and remove `default=ignore` so the line looks like this.
 
@@ -177,10 +233,9 @@ Edit `/etc/pam.d/yubikey` (or appropriate file if you are using other screen loc
 auth [success=done] pam_exec.so expose_authtok quiet /usr/bin/yk-auth
 ```
 
-### Optional: Locking the screen when YubiKey is removed
+#### Optional: Locking the screen when YubiKey / NitroKey3 is removed
 
-Look into it
-You can setup your system to automatically lock the screen when you unplug your YubiKey.
+You can setup your system to automatically lock the screen when you unplug your YubiKey / NitroKey3.
 This will require creating a simple qrexec service which will expose the ability to lock the screen to your USB VM, and then adding a udev hook to actually call that service.
 
 In dom0:

From 1890f09056477a37fd7f6daffb69b1b5add46eb7 Mon Sep 17 00:00:00 2001
From: deeplow <deeplower@protonmail.com>
Date: Sun, 3 Mar 2024 10:19:40 +0000
Subject: [PATCH 095/332] Mention existence of Qubes Builder V2

Qubes Builder V1 is still supported at least until Qubes 4.1
reaches EOL. However the docs don't mention at all the existance of
version 2 of the builder. The ideal solution would be to
document builder v2, while that doesn't happen, at least having a
warning is better than nothing.
---
 developer/building/qubes-builder-details.md | 8 ++++++++
 developer/building/qubes-builder.md         | 7 +++++++
 developer/building/qubes-iso-building.md    | 7 +++++++
 3 files changed, 22 insertions(+)

diff --git a/developer/building/qubes-builder-details.md b/developer/building/qubes-builder-details.md
index f3582284..4e01c689 100644
--- a/developer/building/qubes-builder-details.md
+++ b/developer/building/qubes-builder-details.md
@@ -10,6 +10,14 @@ ref: 65
 title: Qubes builder details
 ---
 
+
+<div class="alert alert-warning" role="alert">
+  <i class="fa fa-exclamation-circle"></i>
+  <b>Note:</b> This information concern the older Qubes builder (v1). It supports
+  only building Qubes 4.1 or earlier. For building Qubes R4.2 or later and related
+  components, please see instead [qubes-builderv2](https://github.com/QubesOS/qubes-builderv2/).
+</div>
+
 Components Makefile.builder file
 --------------------------------
 
diff --git a/developer/building/qubes-builder.md b/developer/building/qubes-builder.md
index 035a36d3..ca04f084 100644
--- a/developer/building/qubes-builder.md
+++ b/developer/building/qubes-builder.md
@@ -10,6 +10,13 @@ ref: 64
 title: Qubes builder
 ---
 
+<div class="alert alert-warning" role="alert">
+  <i class="fa fa-exclamation-circle"></i>
+  <b>Note:</b> These instructions concern the older Qubes builder (v1). It supports
+  only building Qubes 4.1 or earlier. For building Qubes R4.2 or later and related
+  components, please see instead [qubes-builderv2](https://github.com/QubesOS/qubes-builderv2/).
+</div>
+
 **Note: See [ISO building instructions](/doc/qubes-iso-building/) for a streamlined overview on how to use the build system.**
 
 
diff --git a/developer/building/qubes-iso-building.md b/developer/building/qubes-iso-building.md
index fe9fb452..987a5d54 100644
--- a/developer/building/qubes-iso-building.md
+++ b/developer/building/qubes-iso-building.md
@@ -12,6 +12,13 @@ ref: 63
 title: Qubes ISO building
 ---
 
+<div class="alert alert-warning" role="alert">
+  <i class="fa fa-exclamation-circle"></i>
+  <b>Note:</b> These instructions concern the older Qubes builder (v1). It supports
+  only building Qubes 4.1 or earlier. For building Qubes R4.2 or later and related
+  components, please see instead [qubes-builderv2](https://github.com/QubesOS/qubes-builderv2/).
+</div>
+
 Build Environment
 -----------------
 

From c4d2e2f5869007c8b4080494707e2c315eede654 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Wed, 6 Mar 2024 18:43:46 -0800
Subject: [PATCH 096/332] Add section on meta-issues

---
 introduction/issue-tracking.md | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/introduction/issue-tracking.md b/introduction/issue-tracking.md
index 1085625b..200dbc74 100644
--- a/introduction/issue-tracking.md
+++ b/introduction/issue-tracking.md
@@ -83,7 +83,25 @@ A label of the form `affects-<RELEASE_NUMBER>` indicates that an issue affects t
 
 ### Projects
 
-The issue tracker has several [projects](https://github.com/QubesOS/qubes-issues/projects). A project is a way to create a group of multiple related issues. This is the preferred method of grouping issues, whereas trying to use normal issues as "meta-issues" or "epics" is discouraged.
+According to GitHub, a [project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects) is "an adaptable spreadsheet, task-board, and road map that integrates with your issues and pull requests on GitHub to help you plan and track your work effectively." The issue tracker has several [projects](https://github.com/QubesOS/qubes-issues/projects). 
+
+### Meta-issues
+
+A meta-issue is an issue that serves to collect and organize a group of other issues. We use meta-issues when we need a way to track work on specific features. We cannot use [projects](#projects) for this, because we already use a project for tracking the work of the Qubes team as a whole, and projects cannot contain milestones or other projects.
+
+Meta-issues must abide by the following rules:
+
+- Only members of the core team may create meta-issues (or convert existing issues into meta-issues).
+
+  Rationale: The purpose of meta-issues is to track the development of certain features that fit into the overall goals of the Qubes OS Project, which requires making informed project-management decisions with the approval of the project lead.
+
+- Meta-issues must be [locked](https://docs.github.com/en/communities/moderating-comments-and-conversations/locking-conversations).
+
+  Rationale: One of the historical problems we've experienced with meta-issues (and one of the reasons they were discouraged for a long time) is that each meta-issue tends to turn into a discussion thread that becomes hopelessly long to the point where the person who is supposed to work on it has no idea what is supposed to be done or where to start, and it eventually just gets closed. Locking is intended to prevent that from happening again.
+
+- Meta-issues must have informative descriptions, not just lists of issues. In particular, each meta-issue should explain its goal, what is in scope, and what the relevant categories and priorities are.
+
+- Meta-issues must have clear, concrete, and actionable criteria for when they will be closed. Meta-issues should never be "open-ended" or expected to stay open indefinitely. If this ever becomes unclear, the meta-issue should be closed until it becomes clear.
 
 ## Search tips
 

From 875fc70ebf5a95fb5b1270066be710ea15856ff8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rafa=C5=82=20Wojdy=C5=82a?= <omeg@invisiblethingslab.com>
Date: Sun, 10 Mar 2024 19:38:22 +0100
Subject: [PATCH 097/332] Update windows debugging instructions
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Rafał Wojdyła <omeg@invisiblethingslab.com>
---
 developer/debugging/windows-debugging.md | 291 +++++------------------
 1 file changed, 59 insertions(+), 232 deletions(-)

diff --git a/developer/debugging/windows-debugging.md b/developer/debugging/windows-debugging.md
index 87f22b5a..aec81298 100644
--- a/developer/debugging/windows-debugging.md
+++ b/developer/debugging/windows-debugging.md
@@ -10,253 +10,80 @@ ref: 50
 title: Windows debugging
 ---
 
-Debugging Windows code can be tricky in a virtualized environment. The guide below assumes Xen hypervisor and Windows 7 VMs.
+Debugging Windows code can be tricky in a virtualized environment. The guide below assumes Qubes 4.1 and Windows 7 or later VMs.
 
 User-mode debugging is usually straightforward if it can be done on one machine. Just duplicate your normal debugging environment in the VM.
 
-Things get complicated if you need to perform kernel debugging or troubleshoot problems that only manifest on system boot, user logoff or similar. For that you need two Windows VMs: the *host* and the *target*. The *host* will contain [WinDbg](https://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx) installation, your source code and private symbols. The *target* will run the code being debugged. Both will be linked by virtual serial ports.
+Things get complicated if you need to perform kernel debugging or troubleshoot problems that only manifest on system boot, user logoff or similar. For that you need two Windows VMs: the *host* and the *target*. The *host* will contain the debugger, your source code and private symbols. The *target* will run the code being debugged. We will use kernel debugging over network which is supported from Windows 7 onwards. The main caveat is that Windows kernel supports only specific network adapters for this, and the default one in Qubes won't work.
 
-- First, you need to prepare separate copies of both *target* and *host* VM configuration files with some changes. Copy the files from **/var/lib/qubes/appvms/vmname/vmname.conf** to some convenient location, let's call them **host.conf** and **target.conf**.
-- In both copied files add the following line at the end: `serial = 'pty'`. This will make Xen connect VM's serial ports to dom0's ptys.
-- From now on you need to start both VMs like this: `qvm-start --custom-config=/your/edited/host.conf host`
-- To connect both VM serial ports together you will either need [socat](http://www.dest-unreach.org/socat/) or a custom utility described later.
-- To determine which dom0 pty corresponds to VM's serial port you need to read xenstore, example script below:
+## Important note
 
-```bash
-#!/bin/sh
+- Do not install Xen network PV drivers in the target VM. Network kernel debugging needs a specific type of NIC or it won't work, the network PV drivers interfere with that.
 
-id1=$(xl domid "$1-dm")
-tty1=$(xenstore-read /local/domain/${id1}/device/console/3/tty)
-echo $tty1
-```
+- If you have kernel debugging active when the Xen PV drivers are being installed, make sure to disable it before rebooting (`bcdedit /set debug off`). You can re-enable debugging after the reboot. The OS won't boot otherwise. I'm not sure what's the exact cause. I know that busparams for the debugging NIC change when PV drivers are installed (see later), but even changing that accordingly in the debug settings doesn't help -- so it's best to disable debug for this one reboot.
 
-Pass it a running VM name and it will output the corresponding pty name.
+## Modifying the NIC of the target VM
 
-- To connect both ptys you can use [socat](http://www.dest-unreach.org/socat/) like that:
+You will need to create a custom libvirt config for the target VM. See [the documentation](https://dev.qubes-os.org/projects/core-admin/en/latest/libvirt.html) for overview of how libvirt templates work in Qubes. The following assumes the target VM is named `target-vm`.
 
-```bash
-#!/bin/sh
+- Edit `/usr/share/qubes/templates/libvirt/xen.xml` to prepare our custom config to override just the NIC part of the global template:
+  - add `{{ '{% block network %}' }}` before `{{ '{% if vm.netvm %}' }}`
+  - add `{{ '{% endblock %}' }}` after the matching `{{ '{% endif %}' }}`
+- Copy `/usr/share/qubes/templates/libvirt/devices/net.xml` to `/etc/qubes/templates/libvirt/xen/by-name/target-vm.xml`.
+- Add `<model type='e1000'/>` to the `<interface>` section.
+- Enclose everything within `{{ '{% block network %}' }}` + `{{ '{% endblock %}' }}`.
+- Add `{{ "{% extends 'libvirt/xen.xml' %}" }}` at the start.
+- The final `target-vm.xml` should look something like this:
 
-id1=$(xl domid "$1-dm")
-id2=$(xl domid "$2-dm")
-tty1=$(xenstore-read /local/domain/${id1}/device/console/3/tty)
-tty2=$(xenstore-read /local/domain/${id2}/device/console/3/tty)
-socat $tty1,raw $tty2,raw
-```
+~~~
+{% raw %}
+{% extends 'libvirt/xen.xml' %}
+{% block network %}
+   <interface type='ethernet'>
+      <mac address="{{ vm.mac }}" />
+      <ip address="{{ vm.ip }}" />
+      <backenddomain name="{{ vm.netvm.name }}" />
+      <script path='vif-route-qubes' />
+      <model type='e1000' />
+   </interface>
+{% endblock %}
+{% endraw %}
+~~~
 
-...but there is a catch. Xen seems to process the traffic that goes through serial ports and changes all **0x0a** bytes into **0x0d, 0x0a** pairs (newline conversion). I didn't find a way to turn that off (setting ptys to raw mode didn't change anything) and it's not mentioned anywhere on the Internet, so maybe it's something on my system. If the above script works for you then you don't need anything more in dom0.
+- Start `target-vm` and verify in the device manager that a "Intel PRO/1000 MT" adapter is present.
 
-- On the *target* system, run `bcdedit /set debug on` on the console to turn on kernel debugging. It defaults to the first serial port.
-- On the *host* system, install [WinDbg](https://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx) and start the kernel debug (Ctrl-K), choose **com1** as the debug port.
-- Reboot the *target* VM.
-- Run the above shell script in dom0.
-- If everything is fine you should see the proper kernel debugging output in WinDbg. However, if you see something like that:
+## Host and target preparation
+
+- On `host-vm` you will need WinDbg, which is a part of the [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/).
+- Copy the `Debuggers` directory from Windows SDK to `target-vm`.
+- In both `host-vm` and `target-vm` switch the windows network to private (it tends to be public by default).
+- Either turn off the windows firewall or enable all ICMP-in rules in both VMs.
+- In `firewall-vm` edit `/rw/config/qubes-firewall-user-script` to connect both Windows VMs, add:
+  - `iptables -I FORWARD 2 -s <target-vm-ip> -d <host-vm-ip> -j ACCEPT`
+  - `iptables -I FORWARD 2 -s <host-vm-ip> -d <target-vm-ip> -j ACCEPT`
+  - run `/rw/config/qubes-firewall-user-script` so the changes take effect immediately
+- Make sure both VMs can ping each other.
+- In `target-vm`:
+  - start elevated `cmd` session
+  - `cd sdk\Debuggers\x64`
+  - `kdnet` should show that the NIC is supported, note the busparams:
+
+    ~~~
+    Network debugging is supported on the following NICs:
+    busparams=0.6.0, Intel(R) PRO/1000 MT Network Connection, KDNET is running on this NIC.
+    ~~~
+
+  - `bcdedit /debug on`
+  - `bcdedit /dbgsettings net hostip:<host-vm-ip> port:50000 key:1.1.1.1` (you can customize the key)
+  - `bcdedit /set "{dbgsettings}" busparams x.y.z` (use the busparams `kdnet` has shown earlier)
+- In `host-vm` start WinDbg: `windbg -k net:port=50000,key=1.1.1.1`. It will listen for target's connection.
+- Reboot `target-vm`, debugging should start:
 
     ~~~
-    Opened \\.\com1
     Waiting to reconnect...
-    Connected to Windows 7 7601 x64 target at (Wed Mar 19 20:35:43.262 2014 (UTC + 1:00)), ptr64 TRUE
-    Kernel Debugger connection established.
-    Symbol search path is: srv*c:\symbols*https://msdl.microsoft.com/download/symbols
-    Executable search path is:
-    ... Retry sending the same data packet for 64 times.
-    The transport connection between host kernel debugger and target Windows seems lost.
-    please try resync with target, recycle the host debugger, or reboot the target Windows.
-    Unable to read KTHREAD address fffff8000281ccc0
-    **************************************************************************
-    Unable to read debugger data block header
-    **************************************************************************
-    Unable to read KTHREAD address fffff8000281ccc0
-    Unable to read PsLoadedModuleList
-    Unable to read KTHREAD address fffff8000281ccc0
-    **************************************************************************
-    Unable to read debugger data block header
-    **************************************************************************
+    Connected to target 10.137.0.19 on port 50000 on local IP 10.137.0.20.
+    You can get the target MAC address by running .kdtargetmac command.
+    Connected to Windows 10 19041 x64 target at (Thu Aug  3 14:05:48.069 2023 (UTC + 2:00)), ptr64 TRUE
     ~~~
 
-    ...then you're most likely a victim of the CRLF issue mentioned above. To get around it I wrote a small utility that basically does what socat would do and additionally corrects those replaced bytes in the stream. It's not pretty but it works:
-
-```c
-#include <errno.h>
-#include <stdio.h>
-#include <fcntl.h>
-#include <termios.h>
-
-int fd1, fd2;
-char mark = ' ';
-
-void out(unsigned char c)
-{
-    static int count = 0;
-    static unsigned char buf[17] = {0};
-
-    // relay to ouptput port
-    write(fd2, &c, 1);
-    fprintf(stderr, "%c", mark);
-
-    /* dump all data going over the line
-    if (count == 0)
-        fprintf(stderr, "%c", mark);
-    fprintf(stderr, "%02x ", c);
-    if (c >= 0x20 && c < 0x80)
-        buf[count] = c;
-    else
-        buf[count] = '.';
-    count++;
-    if (count == 0x10)
-    {
-        count = 0;
-        fprintf(stderr, " %s\n", buf);
-    }
-    */
-}
-
-int main(int argc, char* argv[])
-{
-    unsigned char c = 0;
-    struct termios tio;
-    ssize_t size;
-
-    if (argc < 3)
-    {
-        fprintf(stderr, "Usage: %s pty1 pty2 [mark character]\n", argv[0]);
-        return EINVAL;
-    }
-
-    fd1 = open(argv[1], O_RDONLY | O_NOCTTY);
-    if (fd1 <= 0)
-    {
-        perror("open fd1");
-        return errno;
-    }
-    fd2 = open(argv[2], O_WRONLY | O_NOCTTY);
-    if (fd2 <= 0)
-    {
-        perror("open fd2");
-        return errno;
-    }
-/*
-    // This doesn't make any difference which supports the theory
-    // that it's Xen who corrupts the byte stream.
-    cfmakeraw(&tio);
-    if (tcsetattr(fd1, TCSANOW, &tio) < 0)
-    {
-        perror("tcsetattr 1");
-        return errno;
-    }
-    if (tcsetattr(fd2, TCSANOW, &tio) < 0)
-    {
-        perror("tcsetattr 2");
-        return errno;
-    }
-*/
-    if (argc == 4)
-        mark = argv[3][0];
-
-    while (1)
-    {
-        size = read(fd1, &c, 1);
-        if (size <= 0)
-            break;
-
-parse:
-        if (c == 0x0d)
-        {
-            size = read(fd1, &c, 1);
-            if (size <= 0)
-            {
-                out(0x0d);
-                break;
-            }
-            if (c == 0x0a)
-            {
-                out(0x0a);
-            }
-            else
-            {
-                out(0x0d);
-                goto parse;
-            }
-        }
-        else
-            out(c);
-    }
-
-    close(fd1);
-    close(fd2);
-    return 0;
-}
-```
-
-> This utility is a unidirectional relay so you need to run two instances to get duplex communication, like:
->
->     #!/bin/sh
->
->     id1=$(xl domid "$1-dm")
->     id2=$(xl domid "$2-dm")
->     tty1=$(xenstore-read /local/domain/${id1}/device/console/3/tty)
->     tty2=$(xenstore-read /local/domain/${id2}/device/console/3/tty)
->     ./ptycrlf ${tty1} ${tty2} - &
->     ./ptycrlf ${tty2} ${tty1} + &
-
-> With this everything should be good:
->
-> ~~~
-> Opened \\.\com1
-> Waiting to reconnect...
-> Connected to Windows 7 7601 x64 target at (Wed Mar 19 20:56:31.371 2014 (UTC + 1:00)), ptr64 TRUE
-> Kernel Debugger connection established.
-> Symbol search path is: srv*c:\symbols*https://msdl.microsoft.com/download/symbols
-> Executable search path is:
-> Windows 7 Kernel Version 7601 MP (1 procs) Free x64
-> Built by: 7601.18247.amd64fre.win7sp1_gdr.130828-1532
-> Machine Name:
-> Kernel base = 0xfffff800`0261a000 PsLoadedModuleList = 0xfffff800`0285d6d0
-> System Uptime: not available
-> ~~~
-
-# Debugging HVMs in the Qubes R4.0
-
-There are two main issues to be adopted to get all things to work in the R4.0.
-
-## Add a virtual serial port
-
-Qemu in the stub domain with virtual serial port added in a recommended way (```<serial type="pty"/>```) fails to start (Could not open '/dev/hvc1': No such device). It seems like a lack of multiple xen consoles support/configuration. The only way that I have found is to attach serial port explicitly to the available console.
-
-1. Unpack stub domain in dom0:
-
-```shell_session
-$ mkdir stubroot
-$ cp /usr/lib/xen/boot/stubdom-linux-rootfs stubroot/stubdom-linux-rootfs.gz
-$ cd stubroot
-$ gunzip stubdom-linux-rootfs.gz
-$ cpio -i -d -H newc --no-absolute-filenames < stubdom-linux-rootfs
-$ rm stubdom-linux-rootfs
-```
-
-2. Edit Init script to remove last loop and to add "-serial /dev/hvc0" to the qemu command line.
-
-3. Apply changes:
-
-```shell_session
-$ find . -print0 | cpio --null -ov --format=newc | gzip -9 > ../stubdom-linux-rootfs
-$ sudo mv ../stubdom-linux-rootfs /usr/lib/xen/boot
-```
-
-## Connect two consoles
-
-Run the following script:
-
-```shell
-debugname1=win7new
-debugname2=win7dbg
-id1=$(xl domid "$debugname1-dm")
-id2=$(xl domid "$debugname2-dm")
-
-tty1=$(xenstore-read /local/domain/${id1}/console/tty)
-tty2=$(xenstore-read /local/domain/${id1}/console/tty)
-
-socat $tty1,raw $tty2,raw
-```
-
 Happy debugging!

From e284f64909b8ee5e39c767341fde81f17b0279fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rafa=C5=82=20Wojdy=C5=82a?= <omeg@invisiblethingslab.com>
Date: Sun, 10 Mar 2024 19:53:09 +0100
Subject: [PATCH 098/332] Fix typo
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Rafał Wojdyła <omeg@invisiblethingslab.com>
---
 developer/debugging/windows-debugging.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/developer/debugging/windows-debugging.md b/developer/debugging/windows-debugging.md
index aec81298..844273d5 100644
--- a/developer/debugging/windows-debugging.md
+++ b/developer/debugging/windows-debugging.md
@@ -10,7 +10,7 @@ ref: 50
 title: Windows debugging
 ---
 
-Debugging Windows code can be tricky in a virtualized environment. The guide below assumes Qubes 4.1 and Windows 7 or later VMs.
+Debugging Windows code can be tricky in a virtualized environment. The guide below assumes Qubes 4.2 and Windows 7 or later VMs.
 
 User-mode debugging is usually straightforward if it can be done on one machine. Just duplicate your normal debugging environment in the VM.
 

From 9da0acc630d604905e6552aba3e8668222473ef6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rafa=C5=82=20Wojdy=C5=82a?= <omeg@invisiblethingslab.com>
Date: Sun, 10 Mar 2024 19:53:18 +0100
Subject: [PATCH 099/332] Fix jinja escaping
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Rafał Wojdyła <omeg@invisiblethingslab.com>
---
 developer/debugging/windows-debugging.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/developer/debugging/windows-debugging.md b/developer/debugging/windows-debugging.md
index 844273d5..089dfecd 100644
--- a/developer/debugging/windows-debugging.md
+++ b/developer/debugging/windows-debugging.md
@@ -27,12 +27,12 @@ Things get complicated if you need to perform kernel debugging or troubleshoot p
 You will need to create a custom libvirt config for the target VM. See [the documentation](https://dev.qubes-os.org/projects/core-admin/en/latest/libvirt.html) for overview of how libvirt templates work in Qubes. The following assumes the target VM is named `target-vm`.
 
 - Edit `/usr/share/qubes/templates/libvirt/xen.xml` to prepare our custom config to override just the NIC part of the global template:
-  - add `{{ '{% block network %}' }}` before `{{ '{% if vm.netvm %}' }}`
-  - add `{{ '{% endblock %}' }}` after the matching `{{ '{% endif %}' }}`
+  - add `{% raw %}{% block network %}{% endraw %}` before `{% raw %}{% if vm.netvm %}{% endraw %}`
+  - add `{% raw %}{% endblock %}{% endraw %}` after the matching `{% raw %}{% endif %}{% endraw %}`
 - Copy `/usr/share/qubes/templates/libvirt/devices/net.xml` to `/etc/qubes/templates/libvirt/xen/by-name/target-vm.xml`.
 - Add `<model type='e1000'/>` to the `<interface>` section.
-- Enclose everything within `{{ '{% block network %}' }}` + `{{ '{% endblock %}' }}`.
-- Add `{{ "{% extends 'libvirt/xen.xml' %}" }}` at the start.
+- Enclose everything within `{% raw %}{% block network %}{% endraw %}` + `{% raw %}{% endblock %}{% endraw %}`.
+- Add `{% raw %}{% extends 'libvirt/xen.xml' %}{% endraw %}` at the start.
 - The final `target-vm.xml` should look something like this:
 
 ~~~

From 65444ee38f6a424b9d26113d10c93defb532ed43 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Tue, 12 Mar 2024 17:22:50 +0000
Subject: [PATCH 100/332] Fix formatting in warning notes

---
 developer/building/qubes-builder-details.md | 6 ++----
 developer/building/qubes-builder.md         | 3 +--
 developer/building/qubes-iso-building.md    | 3 +--
 3 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/developer/building/qubes-builder-details.md b/developer/building/qubes-builder-details.md
index 4e01c689..ad2b79f8 100644
--- a/developer/building/qubes-builder-details.md
+++ b/developer/building/qubes-builder-details.md
@@ -13,10 +13,8 @@ title: Qubes builder details
 
 <div class="alert alert-warning" role="alert">
   <i class="fa fa-exclamation-circle"></i>
-  <b>Note:</b> This information concern the older Qubes builder (v1). It supports
-  only building Qubes 4.1 or earlier. For building Qubes R4.2 or later and related
-  components, please see instead [qubes-builderv2](https://github.com/QubesOS/qubes-builderv2/).
-</div>
+  <b>Note:</b> This information concerns the old Qubes builder (v1). It supports
+  only building Qubes 4.1 or earlier.<br>The build process has been completely rewritten in <a href="https://github.com/QubesOS/qubes-builderv2/">qubes-builder v2</a>. This can be be used for building Qubes R4.1 and later, and all related components.</div>
 
 Components Makefile.builder file
 --------------------------------
diff --git a/developer/building/qubes-builder.md b/developer/building/qubes-builder.md
index ca04f084..4f7b0291 100644
--- a/developer/building/qubes-builder.md
+++ b/developer/building/qubes-builder.md
@@ -13,8 +13,7 @@ title: Qubes builder
 <div class="alert alert-warning" role="alert">
   <i class="fa fa-exclamation-circle"></i>
   <b>Note:</b> These instructions concern the older Qubes builder (v1). It supports
-  only building Qubes 4.1 or earlier. For building Qubes R4.2 or later and related
-  components, please see instead [qubes-builderv2](https://github.com/QubesOS/qubes-builderv2/).
+  only building Qubes 4.1 or earlier.<br>The build process has been completely rewritten in <a href="https://github.com/QubesOS/qubes-builderv2/">qubes-builder v2</a>. This can be be used for building Qubes R4.1 and later, and all related components.
 </div>
 
 **Note: See [ISO building instructions](/doc/qubes-iso-building/) for a streamlined overview on how to use the build system.**
diff --git a/developer/building/qubes-iso-building.md b/developer/building/qubes-iso-building.md
index 987a5d54..ac075443 100644
--- a/developer/building/qubes-iso-building.md
+++ b/developer/building/qubes-iso-building.md
@@ -15,8 +15,7 @@ title: Qubes ISO building
 <div class="alert alert-warning" role="alert">
   <i class="fa fa-exclamation-circle"></i>
   <b>Note:</b> These instructions concern the older Qubes builder (v1). It supports
-  only building Qubes 4.1 or earlier. For building Qubes R4.2 or later and related
-  components, please see instead [qubes-builderv2](https://github.com/QubesOS/qubes-builderv2/).
+  only building Qubes 4.1 or earlier.<br>The build process has been completely rewritten in <a href="https://github.com/QubesOS/qubes-builderv2/">qubes-builder v2</a>. This can be be used for building Qubes R4.1 and later, and all related components.
 </div>
 
 Build Environment

From 10bbeb1d80b40aba81dd12425ec246014ac10505 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gr=C3=A9goire?=
 <96051754+gregoire-mullvad@users.noreply.github.com>
Date: Thu, 14 Mar 2024 13:15:07 +0100
Subject: [PATCH 101/332] Fix formatting in firewall.md

Some code blocks that aren't rendering correctly in the website.
---
 user/security-in-qubes/firewall.md | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index 3cb7c42b..95b28673 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -66,12 +66,16 @@ Normally Qubes doesn't let the user stop a NetVM if there are other qubes runnin
 But in case the NetVM stops for whatever reason (e.g. it crashes, or the user forces its shutdown via qvm-kill via terminal in Dom0), Qubes R4.x will often automatically repair the connection.
 If it does not, then there is an easy way to restore the connection to the NetVM by issuing in dom0:
 
-` qvm-prefs <vm> netvm <netvm> `
+```
+qvm-prefs <vm> netvm <netvm>
+```
 
 Normally qubes do not connect directly to the actual NetVM (sys-net by default) which has networking devices, but rather to the default sys-firewall first, and in most cases it would be the NetVM that will crash, e.g. in response to S3 sleep/restore or other issues with WiFi drivers.
 In that case it is only necessary to issue the above command once, for the sys-firewall (this assumes default VM-naming used by the default Qubes installation):
 
-` qvm-prefs sys-firewall netvm sys-net `
+```
+qvm-prefs sys-firewall netvm sys-net
+```
 
 Network service qubes
 ---------------------

From adc3e9a14565234693bf58739a10b006a4ac4450 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marta=20Marczykowska-G=C3=B3recka?=
 <marmarta@users.noreply.github.com>
Date: Thu, 14 Mar 2024 21:13:12 +0100
Subject: [PATCH 102/332] New issue management guidelines

Added new issue guidelines.
---
 introduction/issue-tracking.md | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/introduction/issue-tracking.md b/introduction/issue-tracking.md
index 200dbc74..80d6dd08 100644
--- a/introduction/issue-tracking.md
+++ b/introduction/issue-tracking.md
@@ -83,7 +83,9 @@ A label of the form `affects-<RELEASE_NUMBER>` indicates that an issue affects t
 
 ### Projects
 
-According to GitHub, a [project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects) is "an adaptable spreadsheet, task-board, and road map that integrates with your issues and pull requests on GitHub to help you plan and track your work effectively." The issue tracker has several [projects](https://github.com/QubesOS/qubes-issues/projects). 
+According to GitHub, a [project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects) is "an adaptable spreadsheet, task-board, and road map that integrates with your issues and pull requests on GitHub to help you plan and track your work effectively." The issue tracker has several [projects](https://github.com/QubesOS/qubes-issues/projects). Github projects allows more detailed issue states, and also attaching more metadata to issues. They also allow more focused view.
+
+There is a special project in Qubes OS project: the [Current team tasks project](https://github.com/orgs/QubesOS/projects/19/views/1) which represents current work of the core team. Issues in this project's **backlog** section are not yet ready for work - they might be waiting for clarifications, blockers, decisions on priorities etc. Issues that are **ready** can be picked up by any team member. There should not be too many issues in **ready** column to decrease confusion and decision paralysis - good number is around 20. The **in review** state means that the developer is finished with the work (the completion state has been reached) - if something has to be postponed or abandoned, a justification should be posted in issue discussion.
 
 ### Meta-issues
 
@@ -211,3 +213,21 @@ In order to assist with this, we have a label called [backport pending](https://
 ### Understanding open and closed issues
 
 Every issue is always in one of two states: open or closed, with open being the default. The **open** and **closed** states mean that, according to our available information at present, the issue in question either **is** or **is not** (respectively) actionable for the Qubes team. The open and closed states do not mean anything more than this, and it's important not to read anything else into them. It's also important to understand that closing an issue is, in effect, nothing more than changing a virtual tag on an issue. Closing an issue is never "final" in any sense, and it does not affect the issue itself in any other way. Issues can be opened and closed instantly with a single button press an unlimited number of times at no cost. In fact, since the open and closed states reflect our available information at present, one should expect these states to change back and forth as new information becomes available. Closed issues are fully searchable, just like open issues, and we explicitly instruct all users of the issue tracker to search *both* open *and* closed issues, which GitHub makes easy.
+
+## Workflow and what do issue states mean
+
+There are some rules we use when assigning issues and tagging them.
+
+### Assigning issues
+
+To avoid a situation where an issue is "dead" - assigned to someone who is not actively working on it - and to help the team organize their work, an issue should be assigned to a person who currently works on it, or will start working on it in a very near future (about a week or two). One person can have several issues assigned at the same time (for example they may be working on one another issue while waiting for review), but if an issue is no longer actively being worked on (for example when it's blocked by something else),  it should be unassigned. At that point, if there is some partial work already done, there should be a comment about that, including link to the code (some WIP commit in some branch?) if applicable.
+
+Issues should not be assigned as a todo-list several months in the future, or assigned to someone without their explicit confirmation that they are currently working on that issue or will start doing it shortly.
+
+### Working on an issue
+
+Every issue should involve a clear statement of success: when is the issue finished? It might not be clear to the person making the issue, especially if it's an enhancement request, but before work starts, the person working on the issue should make sure that it includes clear completion criteria in the description (via editing the description, if necessary). The completion criteria would ideally be a checklist, and consist of a list of pull requests/features, each preferably no more than two weeks of work. It's also important to remember tests and documentation should also be part of the issue, if applicable. 
+
+An issue should also have a rough estimate how much time it needs, if it's more than one-two days. Of course this might be updated later, if an issue turns out to be more (or maybe less) complicated than it has initially seemed. 
+
+When an issue is done (that is, the completion checklist has been completed), the issue should be moved to **ready** column in the *Current team tasks* project.

From 2a20311e070151961aa7e4dd7c6d778ecbf8e239 Mon Sep 17 00:00:00 2001
From: deeplow <deeplower@protonmail.com>
Date: Thu, 21 Mar 2024 19:30:09 +0000
Subject: [PATCH 103/332] Fix typo

---
 user/security-in-qubes/mfa.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/security-in-qubes/mfa.md b/user/security-in-qubes/mfa.md
index b1f6938f..3d7e7ce0 100644
--- a/user/security-in-qubes/mfa.md
+++ b/user/security-in-qubes/mfa.md
@@ -12,7 +12,7 @@ title: Multi-factor Login
 ---
 
 
-## Multi-factor authentication within in particular qubes
+## Multi-factor authentication within particular qubes
 
 Most use cases for the hardware tokens can be achieved exactly as described by the
 manufacturer or other instructions found online. One usually just needs to

From 3042d62e55a20d181b8e9ed2fc982d3176a17029 Mon Sep 17 00:00:00 2001
From: deeplow <47065258+deeplow@users.noreply.github.com>
Date: Fri, 22 Mar 2024 16:55:08 -0400
Subject: [PATCH 104/332] Fix typo

---
 user/downloading-installing-upgrading/upgrade/4_2.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/downloading-installing-upgrading/upgrade/4_2.md b/user/downloading-installing-upgrading/upgrade/4_2.md
index ba088be1..cd0dce34 100644
--- a/user/downloading-installing-upgrading/upgrade/4_2.md
+++ b/user/downloading-installing-upgrading/upgrade/4_2.md
@@ -23,7 +23,7 @@ If you would prefer to perform a clean installation rather than upgrading
 in-place:
 
 1. (optional) Run the updater to ensure all of your templates are in their latest version.
-2. Install the `qubes-dist-upgrade` tool. This is the inplace upgrade tool, which is not what we're doing. However it will needed in order to prepare the templates for the 4.2 version. You install it with the following command in the dom0 terminal:
+2. Install the `qubes-dist-upgrade` tool. This is the inplace upgrade tool, which is not what we're doing. However it will be needed in order to prepare the templates for the 4.2 version. You install it with the following command in the dom0 terminal:
 
        sudo qubes-dom0-update -y qubes-dist-upgrade
 

From 8aa4e8eca33dd12de0afa377fa12e3f44f0ba9df Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sat, 23 Mar 2024 12:12:55 +0000
Subject: [PATCH 105/332] Include note on use of template tool to change
 templates when switching. Explicitly refer to default-mgmt-dvm.

---
 user/templates/templates.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/user/templates/templates.md b/user/templates/templates.md
index bab15cb9..2f7ac64a 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -273,6 +273,15 @@ new template:
    old template by clicking on the first one, holding shift, then clicking on
    the last one. With multiple qubes selected, right-click on any of them,
    hover your cursor over Template, then click on the new template.
+    Or in the `System` menu select `Manage templates for qubes`, select
+    any qubes using the old template and update them to the new template
+    using the drop down menu.
+
+4. **Change the template for the default-mgmt-dvm** If the old template
+    was used for management qubes, then you should change the template.
+    This is an *internal* qube which does not appear by default in the Qube manager.
+    In the `System` menu select `Manage templates for qubes`, and you will see the *default-mgmt-dvm* qube.
+    Change the template used for this disposable template to the new template.
 
 ## Advanced
 

From 1cb9453b318683cf9300d73743e19c181023fcce Mon Sep 17 00:00:00 2001
From: fz72 <fz72@gmx.de>
Date: Sat, 23 Mar 2024 20:48:39 +0000
Subject: [PATCH 106/332] Update firewall.md - route from outside the world

- correct: nft list table ip qubes instead of nft list table ip qubes-firewall
- location of firewall script in sys-net
- additional note for interface
---
 user/security-in-qubes/firewall.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index 95b28673..d4597e39 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -308,12 +308,12 @@ nft add rule qubes custom-forward iif == "ens6" ip saddr 192.168.x.y/24 ip daddr
 
 > Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
 
-> If you want to expose the service on multiple interfaces, repeat the steps 2 and 3 described above, for each interface.
+> If you want to expose the service on multiple interfaces, repeat the steps 2 and 3 described above, for each interface. Alternatively, you can leave out the interface completely.
 
 Verify the rules on sys-net firewall correctly match the packets you want by looking at its counters, check for the counter lines in the chains `custom-forward` and `custom-dnat-qubeDEST`:
 
 ```
-nft list table ip qubes-firewall
+nft list table ip qubes
 ```
 
 In this example, we can see 7 packets in the forward rule, and 3 packets in the dnat rule:
@@ -335,7 +335,7 @@ chain custom-dnat-qubeDEST {
 telnet 192.168.x.n 443
 ```
 
-Once you have confirmed that the counters increase, store the commands used in the previous steps in `/rw/config/rc.local` so they get set on sys-net start-up:
+Once you have confirmed that the counters increase, store the commands used in the previous steps in `/rw/config/qubes-firewall-user-script` so they get set on sys-net start-up:
 
 ```
 [user@sys-net user]$ sudo -i

From 5abde828d7e437dc6a88c836cdda743c7a3c543e Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sun, 31 Mar 2024 12:31:13 +0000
Subject: [PATCH 107/332] Add note on requirements for salting
 fedora-39-minimal templates

---
 user/templates/minimal-templates.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/user/templates/minimal-templates.md b/user/templates/minimal-templates.md
index 2da511ff..2e7c934e 100644
--- a/user/templates/minimal-templates.md
+++ b/user/templates/minimal-templates.md
@@ -165,6 +165,8 @@ list of packages to be installed):
 - `default-mgmt-dvm`: requires `qubes-core-agent-passwordless-root` and
   `qubes-mgmt-salt-vm-connector`.
 
+To manage fedora-39-minimal templates with salt, you may need to install `python3-urllib3` in older versions of the template. (This package is already installed in recent builds: see [discussion](https://github.com/QubesOS/qubes-issues/issues/8806).)
+
 In Qubes 4.0, additional packages from the `qubes-core-agent` suite may be
 needed to make the customized minimal template work properly. These packages
 are:

From c83e5d409c91e2abc120f14fc24f59eb26a4dc71 Mon Sep 17 00:00:00 2001
From: Michael Carbone <mfc@users.noreply.github.com>
Date: Tue, 2 Apr 2024 15:16:13 +0200
Subject: [PATCH 108/332] Update gsod.md for 2024

still needs some content
---
 developer/general/gsod.md | 80 +++++++++++++++++++++++----------------
 1 file changed, 48 insertions(+), 32 deletions(-)

diff --git a/developer/general/gsod.md b/developer/general/gsod.md
index ab8c0086..091f6acb 100644
--- a/developer/general/gsod.md
+++ b/developer/general/gsod.md
@@ -6,9 +6,9 @@ ref: 242
 title: Google Season of Docs (GSoD)
 ---
 
-Thank you for your interest in participating in the [2023 Google Season of Docs](https://developers.google.com/season-of-docs/) program with the [Qubes OS team](/team/). This page details our 2023 project idea as well as completed past projects. You can read more about the Google Season of Docs in the official [guides](https://developers.google.com/season-of-docs/docs/) and [FAQ](https://developers.google.com/season-of-docs/docs/faq).
+Thank you for your interest in participating in the [2024 Google Season of Docs](https://developers.google.com/season-of-docs/) program with the [Qubes OS team](/team/). This page details our 2024 project idea as well as completed past projects. You can read more about the Google Season of Docs in the official [guides](https://developers.google.com/season-of-docs/docs/) and [FAQ](https://developers.google.com/season-of-docs/docs/faq).
 
-## Instructional video series -- Qubes OS
+## Update and Expand How-To Guides -- Qubes OS
 
 ### About the Qubes OS Project
 
@@ -18,10 +18,54 @@ Qubes OS was launched in 2011 and has [received praise from security experts and
 
 ### The project's problem
 
-There is user demand for high-quality, up-to-date video guides that take users from zero Linux knowledge to using Qubes as a daily driver and performing specific tasks inside of Qubes, but almost no such videos exist. Although most of the required knowledge is documented, many users report that they would prefer to watch videos rather than read text or that they would find videos easier to understand and follow along with.
+to-be-written
 
 ### The project's scope
 
+to-be-written
+
+The project is estimated to need around six months to complete (see the timeline below). Qubes team members, including Michael Carbone, Andrew Wong, Marta Marczykowska-Górecka, and Marek Marczykowski-Górecki, will supervise and support the writer.
+
+### Measuring the project's success
+
+to-be-written
+
+### Timeline
+
+| Dates          | Action items                            |
+| -------------- | --------------------------------------- |
+| May            | Orientation                             |
+| June--November |             |
+| December       | Final project evaluation and case study |
+
+
+### Project budget
+
+| Expense                                 | Amount  |
+| --------------------------------------- | ------- |
+| writer (10 hours/week, 6 months)        | $12,000 |
+| TOTAL                                   | $12,000 |
+
+### Additional information
+
+Qubes OS regularly participates in Google Summer of Code and Google Season of Docs. This is our third time participating in Google Season of Docs. Our mentorships for GSoD 2019, 2020, and 2023 were successes, and the projects were completed within the times allotted. The past Google Season of Docs projects have given us experience in working with technical writers and have helped us to understand the benefits that technical writers can bring to our project. 
+
+## Past Projects
+
+You can view the project we had in 2019 in the [2019 GSoD archive](https://developers.google.com/season-of-docs/docs/2019/participants/project-qubes) and the [2019 writer's report](https://refre.ch/report-qubesos/).
+
+You can also view the project we had in 2020 in the [2020 GSoD archive](https://developers.google.com/season-of-docs/docs/2020/participants/project-qubesos-c1e0) and the [2020 writer's report](https://gist.github.com/PROTechThor/bfe9b8b28295d88c438b6f6c754ae733).
+
+Here are some successful projects which have been implemented in the past by Google Season of Docs participants. 
+
+### Instructional video series
+
+#### The project's problem
+
+There is user demand for high-quality, up-to-date video guides that take users from zero Linux knowledge to using Qubes as a daily driver and performing specific tasks inside of Qubes, but almost no such videos exist. Although most of the required knowledge is documented, many users report that they would prefer to watch videos rather than read text or that they would find videos easier to understand and follow along with.
+
+#### The project's scope
+
 This project consists of creating a series of instructional videos that satisfy the following criteria:
 
 - Prospective users who are not yet familiar with Linux or Qubes OS can easily understand and follow the videos.
@@ -68,7 +112,7 @@ Below is an example of the content (which is already [documented](/doc/)) that t
 
 The project is estimated to need around six months to complete (see the timeline below). Qubes team members, including Michael Carbone, Andrew Wong, and Marek Marczykowski-Górecki, will supervise and support the creator.
 
-### Measuring the project's success
+#### Measuring the project's success
 
 We will consider the project successful if, after publication of the video series:
 
@@ -76,34 +120,6 @@ We will consider the project successful if, after publication of the video serie
 - The reception to the videos is generally positive and complaints about quality and accuracy are minimal.
 - Appropriate analytics (e.g., YouTube metrics) are average or better for videos of this type (to be determined in consultation with the creator).
 
-### Timeline
-
-| Dates          | Action items                            |
-| -------------- | --------------------------------------- |
-| March          | Orientation                             |
-| April--October | Create Qubes OS video series            |
-| November       | Final project evaluation and case study |
-
-
-### Project budget
-
-| Expense                                 | Amount  |
-| --------------------------------------- | ------- |
-| Video creator (20 hours/week, 6 months) | $12,000 |
-| TOTAL                                   | $12,000 |
-
-### Additional information
-
-Qubes OS regularly participates in Google Summer of Code and Google Season of Docs. This is our third time participating in Google Season of Docs. Our mentorships for GSoD 2019 and 2020 were successes, and both projects were completed within the times allotted. The past Google Season of Docs projects have given us experience in working with technical writers and have helped us to understand the benefits that technical writers can bring to our project. While our experience in working with video creators is more limited, we are keenly aware of the benefits of high-quality video content, as well as the significant time, resources, and talent required to create it.
-
-## Past Projects
-
-You can view the project we had in 2019 in the [2019 GSoD archive](https://developers.google.com/season-of-docs/docs/2019/participants/project-qubes) and the [2019 writer's report](https://refre.ch/report-qubesos/).
-
-You can also view the project we had in 2020 in the [2020 GSoD archive](https://developers.google.com/season-of-docs/docs/2020/participants/project-qubesos-c1e0) and the [2020 writer's report](https://gist.github.com/PROTechThor/bfe9b8b28295d88c438b6f6c754ae733).
-
-Here are some successful projects which have been implemented in the past by Google Season of Docs participants. 
-
 ### Consolidate troubleshooting guides
 
 **Project**: Consolidate troubleshooting guides

From 558bb2a51c527fb3319ccbee00b4c56eae78a29c Mon Sep 17 00:00:00 2001
From: Michael Carbone <mfc@users.noreply.github.com>
Date: Tue, 2 Apr 2024 15:26:26 +0200
Subject: [PATCH 109/332] include link to 2023 gsod results

---
 developer/general/gsod.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/developer/general/gsod.md b/developer/general/gsod.md
index 091f6acb..088ce505 100644
--- a/developer/general/gsod.md
+++ b/developer/general/gsod.md
@@ -54,7 +54,9 @@ Qubes OS regularly participates in Google Summer of Code and Google Season of Do
 
 You can view the project we had in 2019 in the [2019 GSoD archive](https://developers.google.com/season-of-docs/docs/2019/participants/project-qubes) and the [2019 writer's report](https://refre.ch/report-qubesos/).
 
-You can also view the project we had in 2020 in the [2020 GSoD archive](https://developers.google.com/season-of-docs/docs/2020/participants/project-qubesos-c1e0) and the [2020 writer's report](https://gist.github.com/PROTechThor/bfe9b8b28295d88c438b6f6c754ae733).
+You can view the project we had in 2020 in the [2020 GSoD archive](https://developers.google.com/season-of-docs/docs/2020/participants/project-qubesos-c1e0) and the [2020 writer's report](https://gist.github.com/PROTechThor/bfe9b8b28295d88c438b6f6c754ae733).
+
+You can view the results of the project we had in 2023 [here](https://www.youtube.com/playlist?list=PLjwSYc73nX6aHcpqub-6lzJbL0vhLleTB).
 
 Here are some successful projects which have been implemented in the past by Google Season of Docs participants. 
 

From 1915add8534ceb64d7e4d8f00aa70bb2eaeaf8d0 Mon Sep 17 00:00:00 2001
From: Michael Carbone <mfc@users.noreply.github.com>
Date: Tue, 2 Apr 2024 15:48:48 +0200
Subject: [PATCH 110/332] add some text

---
 developer/general/gsod.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/developer/general/gsod.md b/developer/general/gsod.md
index 088ce505..cbd489da 100644
--- a/developer/general/gsod.md
+++ b/developer/general/gsod.md
@@ -32,11 +32,11 @@ to-be-written
 
 ### Timeline
 
-| Dates          | Action items                            |
-| -------------- | --------------------------------------- |
-| May            | Orientation                             |
-| June--November |             |
-| December       | Final project evaluation and case study |
+| Dates           | Action items                            |
+| --------------- | --------------------------------------- |
+| May             | Orientation                             |
+| June - November | Update & extend how-to guides           |
+| December        | Final project evaluation and case study |
 
 
 ### Project budget

From d40dfd10bbba597c877fb80bd8d3f411d736f191 Mon Sep 17 00:00:00 2001
From: xaki23 <tvguho-knxv23-tct.e23f2f1b@hashmail.org>
Date: Wed, 3 Apr 2024 01:10:49 +0200
Subject: [PATCH 111/332] try to improve/update chat section

---
 introduction/support.md | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/introduction/support.md b/introduction/support.md
index 4fc0185e..1d818d25 100644
--- a/introduction/support.md
+++ b/introduction/support.md
@@ -514,8 +514,11 @@ news.
 
 ## Chat
 
-If you'd like to chat, join us on the `#qubes` IRC channel (or its Matrix
-bridge: `#qubes:libera.chat`).
+If you'd like to chat, join us on
+- the `#qubes` channel on `irc.libera.chat` or
+- the `#qubes:invisiblethingslab.com` matrix channel.
+
+these two should be linked/bridged, but for technical reasons currently are not.
 
 ## Unofficial venues
 

From 2cf63497fa23f1fc7618b56b01ebefac40e744db Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Tue, 2 Apr 2024 23:42:18 -0700
Subject: [PATCH 112/332] Fill out "the project's problem" section

---
 developer/general/gsod.md | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/developer/general/gsod.md b/developer/general/gsod.md
index cbd489da..90ad8863 100644
--- a/developer/general/gsod.md
+++ b/developer/general/gsod.md
@@ -18,7 +18,11 @@ Qubes OS was launched in 2011 and has [received praise from security experts and
 
 ### The project's problem
 
-to-be-written
+- Some of the existing content is stale. It refers to previous Qubes releases and has not yet been updated to the cover the latest stable release.
+- There are important topic areas that the current guides do not completely cover, such as "understanding Qubes OS," "using Qubes OS in practice," "Qubes OS workflow for coding," "printing," and "audio."
+- The guides do not consistently address users of all skill and experience levels (beginner, intermediate, and expert).
+- Some of the guides lack relevant illustrations and screenshots.
+- When the developers update a software tool, they should update all the guides that mentions this tool. However, there is currently no way for the developers to know which guides mention which tools.
 
 ### The project's scope
 

From c664e19fe045a7e78d1f0c498bdb320d535cd5e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>
Date: Fri, 5 Apr 2024 23:02:20 +0200
Subject: [PATCH 113/332] gsod: update 2024 information

---
 developer/general/gsod.md | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/developer/general/gsod.md b/developer/general/gsod.md
index 90ad8863..0ca6b7af 100644
--- a/developer/general/gsod.md
+++ b/developer/general/gsod.md
@@ -26,13 +26,15 @@ Qubes OS was launched in 2011 and has [received praise from security experts and
 
 ### The project's scope
 
-to-be-written
-
 The project is estimated to need around six months to complete (see the timeline below). Qubes team members, including Michael Carbone, Andrew Wong, Marta Marczykowska-Górecka, and Marek Marczykowski-Górecki, will supervise and support the writer.
 
 ### Measuring the project's success
 
-to-be-written
+We will consider the project successful if:
+
+- Existing guides are updated to describe currently supported Qubes OS version
+- Missing common guides are identified
+- 2-3 new guides are written
 
 ### Timeline
 

From b7a07d53e530d227c6534de0d27acec1d723b294 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Fri, 12 Apr 2024 02:41:10 +0000
Subject: [PATCH 114/332] KDE-Delete reference to mailing list threads as
 images removed.

---
 user/advanced-topics/kde.md | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/user/advanced-topics/kde.md b/user/advanced-topics/kde.md
index dbffd245..c2553f7f 100644
--- a/user/advanced-topics/kde.md
+++ b/user/advanced-topics/kde.md
@@ -84,7 +84,3 @@ The safest way to remove (most of) KDE is:
 sudo dnf remove kdelibs plasma-workspace
 ~~~
 
-Mailing List Threads
---------------------
-
-* [Nalu's KDE customization thread](https://groups.google.com/d/topic/qubes-users/KhfzF19NG1s/discussion)

From a2ba6dca04e6f42d686bcf63bb19b0800c6f30f5 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Fri, 12 Apr 2024 02:49:37 +0000
Subject: [PATCH 115/332] Prepare for 4.2 installation guide

---
 .../installation-guide-4.1.md                 | 301 ++++++++++++++++++
 1 file changed, 301 insertions(+)
 create mode 100644 user/downloading-installing-upgrading/installation-guide-4.1.md

diff --git a/user/downloading-installing-upgrading/installation-guide-4.1.md b/user/downloading-installing-upgrading/installation-guide-4.1.md
new file mode 100644
index 00000000..dd76685a
--- /dev/null
+++ b/user/downloading-installing-upgrading/installation-guide-4.1.md
@@ -0,0 +1,301 @@
+---
+lang: en
+layout: doc
+permalink: /doc/installation-guide-4.1/
+redirect_from:
+ref: 901
+title: Qubes 4.1 Installation guide
+---
+
+Welcome to the Qubes OS installation guide! This guide will walk you through the process of installing Qubes. Please read it carefully and thoroughly, as it contains important information for ensuring that your Qubes OS installation is functional and secure.
+
+## Pre-installation
+
+### Hardware requirements
+
+<div class="alert alert-danger" role="alert">
+  <i class="fa fa-exclamation-triangle"></i>
+  <b>Warning:</b> Qubes has no control over what happens on your computer before you install it. No software can provide security if it is installed on compromised hardware. Do not install Qubes on a computer you don't trust. See <a href="/doc/install-security/">installation security</a> for more information.
+</div>
+
+Qubes OS has very specific [system requirements](/doc/system-requirements/). To ensure compatibility, we strongly recommend using [Qubes-certified hardware](/doc/certified-hardware/). Other hardware may require you to perform significant troubleshooting. You may also find it helpful to consult the [Hardware Compatibility List](/hcl/).
+
+Even on supported hardware, you must ensure that [IOMMU-based virtualization](https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit#Virtualization) is activated in the BIOS or UEFI. Without it, Qubes OS won't be able to enforce isolation. For Intel-based boards, this setting is called Intel Virtualization for Directed I/O (**Intel VT-d**) and for AMD-based boards, it is called  AMD I/O Virtualization Technology (or simply **AMD-Vi**). This parameter should be activated in your computer's BIOS or UEFI, alongside the standard Virtualization (**Intel VT-x**) and AMD Virtualization (**AMD-V**) extensions. This [external guide](https://web.archive.org/web/20200112220913/https://www.intel.in/content/www/in/en/support/articles/000007139/server-products.html) made for Intel-based boards can help you figure out how to enter your BIOS or UEFI to locate and activate those settings. If those settings are not nested under the Advanced tab, you might find them under the Security tab.
+
+<div class="alert alert-warning" role="alert">
+  <i class="fa fa-exclamation-circle"></i>
+  <b>Note:</b> Qubes OS is not meant to be installed inside a virtual machine as a guest hypervisor. In other words, <b>nested virtualization</b> is not supported. In order for a strict compartmentalization to be enforced, Qubes OS needs to be able to manage the hardware directly.
+</div>
+
+### Copying the ISO onto the installation medium
+
+Pick the most secure existing computer and OS you have available for downloading and copying the Qubes ISO onto the installation medium. [Download](/downloads/) a Qubes ISO.
+
+<div class="alert alert-danger" role="alert">
+  <i class="fa fa-exclamation-triangle"></i>
+  <b>Warning:</b> Any file you download from the internet could be malicious, even if it appears to come from a trustworthy source. Our philosophy is to <a href="/faq/#what-does-it-mean-to-distrust-the-infrastructure">distrust the infrastructure</a>. Regardless of how you acquire your Qubes ISO, <a href="/security/verifying-signatures/">verify its authenticity</a> before continuing.
+</div>
+
+Once the ISO has been verified as authentic, you should copy it onto the installation medium of your choice, such as a USB drive, dual-layer DVD, or Blu-ray disc. The size of each Qubes ISO is available on the [downloads](/downloads/) page by hovering over the download button. The instructions below assume you've chosen a USB drive as your medium. If you've chosen a different medium, please adapt the instructions accordingly.
+
+<div class="alert alert-warning" role="alert">
+  <i class="fa fa-exclamation-circle"></i>
+  <b>Note:</b> There are important <a href="/doc/install-security/">security considerations</a> to keep in mind when choosing an installation medium. Advanced users may wish to <a href="/security/verifying-signatures/#how-to-re-verify-installation-media-after-writing">re-verify their installation media after writing</a>.
+</div>
+
+<div class="alert alert-danger" role="alert">
+  <i class="fa fa-exclamation-triangle"></i>
+  <b>Warning:</b> Be careful to choose the correct device when copying the ISO, or you may lose data. We strongly recommended making a full backup before modifying any devices.
+</div>
+
+#### Linux ISO to USB
+
+On Linux, if you choose to use a USB drive, copy the ISO onto the USB device, e.g. using `dd`:
+
+```
+$ sudo dd if=Qubes-RX-x86_64.iso of=/dev/sdY status=progress bs=1048576 conv=fsync
+```
+
+Change `Qubes-RX-x86_64.iso` to the filename of the version you're installing, and change `/dev/sdY` to the correct target device e.g., `/dev/sdc`). Make sure to write to the entire device (e.g., `/dev/sdc`) rather than just a single partition (e.g., `/dev/sdc1`).
+
+#### Windows ISO to USB
+
+On Windows, you can use the [Rufus](https://rufus.akeo.ie/) tool to write the ISO to a USB key. Be sure to select "Write in DD Image mode" *after* selecting the Qubes ISO and pressing "START" on the Rufus main window.
+
+<div class="alert alert-info" role="alert">
+  <i class="fa fa-info-circle"></i>
+  <b>Note:</b> Using Rufus to create the installation medium means that you <a href="https://github.com/QubesOS/qubes-issues/issues/2051">won't be able</a> to choose the "Test this media and install Qubes OS" option mentioned in the example below. Instead, choose the "Install Qubes OS" option.
+</div>
+
+[![Rufus menu](/attachment/doc/rufus-menu.png)](/attachment/doc/rufus-menu.png)
+
+[![Rufus DD image mode](/attachment/doc/rufus-dd-image-mode.png)](/attachment/doc/rufus-dd-image-mode.png)
+
+## Installation
+
+This section will demonstrate a simple installation using mostly default settings.
+
+### Getting to the boot screen
+
+"Booting" is the process of starting your computer. When a computer boots up, it first runs low-level software before the main operating system. Depending on the computer, this low-level software is may be called the ["BIOS"](https://en.wikipedia.org/wiki/BIOS) or ["UEFI"](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface).
+
+Since you're installing Qubes OS, you'll need to access your computer's BIOS or UEFI menu so that you can tell it to boot from the USB drive to which you just copied the Qubes installer ISO.
+
+To begin, power off your computer and plug the USB drive into a USB port, but don't press the power button yet. Right after you press the power button, you'll have to immediately press a specific key to enter the BIOS or UEFI menu. The key to press varies from brand to brand. `Esc`, `Del`, and `F10` are common ones. If you're not sure, you can search the web for `<COMPUTER_MODEL> BIOS key` or `<COMPUTER_MODEL> UEFI key` (replacing `<COMPUTER_MODEL>` with your specific computer model) or look it up in your computer's manual.
+
+Once you know the key to press, press your computer's power button, then repeatedly press that key until you've entered your computer's BIOS or UEFI menu. To give you and idea of what you should be looking for, we've provided a couple of example photos below.
+
+Here's an example of what the BIOS menu looks like on a ThinkPad T430:
+
+[![ThinkPad T430 BIOS menu](/attachment/doc/Thinkpad-t430-bios-main.jpg)](/attachment/doc/Thinkpad-t430-bios-main.jpg)
+
+And here's an example of what a UEFI menu looks like:
+
+[![UEFI menu](/attachment/doc/uefi.jpeg)](/attachment/doc/uefi.jpeg)
+
+Once you access your computer's BIOS or UEFI menu, you'll want to go to the "boot menu," which is where you tell your computer which devices to boot from. The goal is to tell the computer to boot from your USB drive so that you can run the Qubes installer. If your boot menu lets you select which device to boot from first, simply select your USB drive. (If you have multiple entries that all look similar to your USB drive, and you're not sure which one is correct, one option is just to try each one until it works.) If, on the other hand, your boot menu presents you with a list of boot devices in order, then you'll want to move your USB drive to the top so that the Qubes installer runs before anything else.
+
+Once you're done on the boot menu, save your changes. How you do this depends on your BIOS or UEFI, but the instructions should be displayed right there on the screen or in a nearby tab. (If you're not sure whether you've saved your changes correctly, you can always reboot your computer and go back into the boot menu to check whether it still reflects your changes.) Once your BIOS or UEFI is configured the way you want it, reboot your computer. This time, don't press any special keys. Instead, let the BIOS or UEFI load and let your computer boot from your USB drive. If you're successful in this step, after a few seconds you'll be presented with the Qubes installer screen:
+
+[![Boot screen](/attachment/doc/boot-screen.png)](/attachment/doc/boot-screen.png)
+
+From here, you can navigate the boot screen using the arrow keys on your keyboard. Pressing the "Tab" key will reveal options. You can choose one of three options:
+
+* Install Qubes OS
+* Test this media and install Qubes OS
+* Troubleshooting
+ 
+Select the option to test this media and install Qubes OS. 
+
+<div class="alert alert-info" role="alert">
+  <i class="fa fa-info-circle"></i>
+  <b>Note:</b> If the latest stable release is not compatible with your hardware, you may wish to consider <a href="/doc/testing/">testing a newer release</a>.
+</div>
+
+If the boot screen does not appear, there are several options to troubleshoot. First, try rebooting your computer. If it still loads your currently installed operating system or does not detect your installation medium, make sure the boot order is set up appropriately. The process to change the boot order varies depending on the currently installed system and the motherboard manufacturer. If **Windows 10** is installed on your machine, you may need to follow specific instructions to change the boot order. This may require an [advanced reboot](https://support.microsoft.com/en-us/help/4026206/windows-10-find-safe-mode-and-other-startup-settings).
+
+### The installer home screen
+
+On the first screen, you are asked to select the language that will be used during the installation process. When you are done, select **Continue**.
+
+[![welcome](/attachment/doc/welcome-to-qubes-os-installation-screen.png)](/attachment/doc/welcome-to-qubes-os-installation-screen.png)
+
+Prior to the next screen, a compatibility test runs to check whether IOMMU-virtualization is active or not. If the test fails, a window will pop up. 
+
+[![Unsupported hardware detected](/attachment/doc/unsupported-hardware-detected.png)](/attachment/doc/unsupported-hardware-detected.png)
+
+Do not panic. It may simply indicate that IOMMU-virtualization hasn't been activated in the BIOS or UEFI. Return to the [hardware requirements](#hardware-requirements) section to learn how to activate it. If the setting is not configured correctly, it means that your hardware won't be able to leverage some Qubes security features, such as a strict isolation of the networking and USB hardware. 
+
+If the test passes, you will reach the installation summary screen. The installer loads Xen right at the beginning. If you can see the installer's graphical screen, and you pass the compatibility check that runs immediately afterward, Qubes OS is likely to work on your system!
+
+Like Fedora, Qubes OS uses the Anaconda installer. Those that are familiar with RPM-based distributions should feel at home. 
+
+### Installation summary
+
+<div class="alert alert-success" role="alert">
+  <i class="fa fa-check-circle"></i>
+  <b>Did you know?</b> The Qubes OS installer is completely offline. It doesn't even load any networking drivers, so there is no possibility of internet-based data leaks or attacks during the installation process.
+</div>
+
+The Installation summary screen allows you to change how the system will be installed and configured, including localization settings. At minimum, you are required to select the storage device on which Qubes OS will be installed. 
+
+[![Installation summary not ready](/attachment/doc/installation-summary-not-ready.png)](/attachment/doc/installation-summary-not-ready.png)
+
+### Localization
+
+Let's assume you wish to add a German keyboard layout. Go to Keyboard Layout, press the "Plus" symbol, search for "German" as indicated in the screenshot and press "Add". If you want it be your default language, select the "German" entry in the list and press the arrow button. Click on "Done" in the upper left corner, and you're ready to go!
+
+[![Keyboard layout selection](/attachment/doc/keyboard-layout-selection.png)](/attachment/doc/keyboard-layout-selection.png)
+
+The process to select a new language is similar to the process to select a new keyboard layout. Follow the same process in the "Language Support" entry.
+
+[![Language support selection](/attachment/doc/language-support-selection.png)](/attachment/doc/language-support-selection.png)
+
+You can have as many keyboard layout and languages as you want. Post-install, you will be able to switch between them and install others. 
+
+Don't forget to select your time and date by clicking on the Time & Date entry.
+
+[![Time and date](/attachment/doc/time-and-date.png)](/attachment/doc/time-and-date.png)
+
+### Software
+
+[![Add-ons](/attachment/doc/add-ons.png)](/attachment/doc/add-ons.png)
+
+On the software selection tab, you can choose which software to install in Qubes OS. Two options are available:
+
+* **Debian:** Select this option if you would like to use [Debian](/doc/templates/debian/) qubes in addition to the default Fedora qubes.
+* **Whonix:** Select this option if you would like to use [Whonix](https://www.whonix.org/wiki/Qubes) qubes. Whonix allows you to use [Tor](https://www.torproject.org/) securely within Qubes.
+
+Whonix lets you route some or all of your network traffic through Tor for greater privacy. Depending on your threat model, you may need to install Whonix templates right away.
+
+Regardless of your choices on this screen, you will always be able to install these and other [templates](/doc/templates/) later. If you're short on disk space, you may wish to deselect these options.
+
+By default, Qubes OS comes preinstalled with the lightweight Xfce4 desktop environment. Other desktop environments will be available to you after the installation is completed, though they may not be officially supported (see [advanced topics](/doc/#advanced-topics)).
+
+Press **Done** to go back to the installation summary screen.
+
+### Installation destination
+
+Under the System section, you must choose the installation destination. Select the storage device on which you would like to install Qubes OS.
+
+<div class="alert alert-danger" role="alert">
+  <i class="fa fa-exclamation-triangle"></i>
+  <b>Warning:</b> Be careful to choose the correct installation target, or you may lose data. We strongly recommended making a full backup before proceeding.
+</div>
+
+Your installation destination can be an internal or external storage drive, such as an SSD, HDD, or USB drive. The installation destination must have a least 32 GiB of free space available.
+
+<div class="alert alert-warning" role="alert">
+  <i class="fa fa-exclamation-circle"></i>
+  <b>Note:</b> The installation destination cannot be the same as the installation medium. For example, if you're installing Qubes OS <em>from</em> a USB drive <em>onto</em> a USB drive, they must be two distinct USB drives, and they must both be plugged into your computer at the same time. (Note: This may not apply to advanced users who partition their devices appropriately.)
+</div>
+
+Installing an operating system onto a USB drive can be a convenient way to try Qubes. However, USB drives are typically much slower than internal SSDs. We recommend a very fast USB 3.0 drive for decent performance. Please note that a minimum storage of 32 GiB is required. If you want to install Qubes OS onto a USB drive, just select the USB device as the target installation device. Bear in mind that the installation process is likely to take longer than it would on an internal storage device.
+
+[![Select storage device](/attachment/doc/select-storage-device.png)](/attachment/doc/select-storage-device.png)
+
+<div class="alert alert-success" role="alert">
+  <i class="fa fa-check-circle"></i>
+  <b>Did you know?</b> By default, Qubes OS uses <a href="https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup">LUKS</a>/<a href="https://en.wikipedia.org/wiki/Dm-crypt">dm-crypt</a> to encrypt everything except the <code>/boot</code> partition.
+</div>
+
+As soon as you press **Done**, the installer will ask you to enter a passphrase for disk encryption. The passphrase should be complex. Make sure that your keyboard layout reflects what keyboard you are actually using. When you're finished, press **Done**.
+
+<div class="alert alert-danger" role="alert">
+  <i class="fa fa-exclamation-triangle"></i>
+  <b>Warning:</b> If you forget your encryption passphrase, there is no way to recover it.
+</div>
+
+[![Select storage passhprase](/attachment/doc/select-storage-passphrase.png)](/attachment/doc/select-storage-passphrase.png)
+
+When you're ready, press **Begin Installation**.
+
+[![Installation summary ready](/attachment/doc/installation-summary-ready.png)](/attachment/doc/installation-summary-ready.png)
+
+### Create your user account
+
+While the installation process is running, you can create your user account. This is what you'll use to log in after disk decryption and when unlocking the screen locker. This is a purely local, offline account in dom0. By design, Qubes OS is a single-user operating system, so this is just for you.
+
+Select **User Creation** to define a new user with administrator privileges and a password. Just as for the disk encryption, this password should be complex. The root account is deactivated and should remain as such.
+
+[![Account name and password](/attachment/doc/account-name-and-password.png)](/attachment/doc/account-name-and-password.png)
+
+When the installation is complete, press **Reboot**. Don't forget to remove the installation medium, or else you may end up seeing the installer boot screen again.
+
+## Post-installation
+
+### First boot
+
+If the installation was successful, you should now see the GRUB menu during the boot process.
+
+[![Grub boot menu](/attachment/doc/grub-boot-menu.png)](/attachment/doc/grub-boot-menu.png)
+
+Just after this screen, you will be asked to enter your encryption passphrase.
+
+[![Unlock storage device screen](/attachment/doc/unlock-storage-device-screen.png)](/attachment/doc/unlock-storage-device-screen.png)
+
+### Initial Setup
+
+You're almost done. Before you can start using Qubes OS, some configuration is needed. 
+
+[![Initial setup menu](/attachment/doc/initial-setup-menu.png)](/attachment/doc/initial-setup-menu.png)
+
+By default, the installer will create a number of qubes (depending on the options you selected during the installation process). These are designed to give you a more ready-to-use environment from the get-go.
+
+[![Initial setup menu configuration](/attachment/doc/initial-setup-menu-configuration.png)](/attachment/doc/initial-setup-menu-configuration.png)
+
+Let's briefly go over the options:
+
+* **Create default system qubes:** These are the core components of the system, required for things like internet access.
+* **Create default application qubes:** These are how you compartmentalize your digital life. There's nothing special about the ones the installer creates. They're just suggestions that apply to most people. If you decide you don't want them, you can always delete them later, and you can always create your own.
+* **Create Whonix Gateway and Workstation qubes:** If you want to use Whonix, you should select this option.
+  * **Enabling system and template updates over the Tor anonymity network using Whonix:** If you select this option, then whenever you install or update software in dom0 or a template, the internet traffic will go through Tor.
+* **Create USB qube holding all USB controllers:** Just like the network qube for the network stack, the USB qube isolates the USB controllers.
+  * **Use sys-net qube for both networking and USB devices:** You should select this option if you rely on a USB device for network access, such as a USB modem or a USB Wi-Fi adapter.
+* **Do not configure anything:** This is for very advanced users only. If you select this option, you'll have to set everything up manually afterward.
+
+When you're satisfied with you choices, press **Done**. This configuration process may take a while, depending on the speed and compatibility of your system.
+
+After the configuration is done, you will be greeted by the login screen. Enter your password and log in.
+
+[![Login screen](/attachment/doc/login-screen.png)](/attachment/doc/login-screen.png)
+
+Congratulations, you are now ready to use Qubes OS!
+
+[![Desktop menu](/attachment/doc/desktop-menu.png)](/attachment/doc/desktop-menu.png)
+
+## Next steps
+
+### Updating
+
+Next, [update](/doc/how-to-update/) your installation to ensure you have the latest security updates. Frequently updating is one of the best ways to remain secure against new threats.
+
+### Security
+
+The Qubes OS Project occasionally issues [Qubes Security Bulletins (QSBs)](/security/qsb/) as part of the [Qubes Security Pack (qubes-secpack)](/security/pack/). It is important to make sure that you receive all QSBs in a timely manner so that you can take action to keep your system secure. (While [updating](#updating) will handle most security needs, there may be cases in which additional action from you is required.) For this reason, we strongly recommend that every Qubes user subscribe to the [qubes-announce](/support/#qubes-announce) mailing list.
+
+In addition to QSBs, the Qubes OS Project also publishes [Canaries](/security/canary/), XSA summaries, template releases and end-of-life notices, and other items of interest to Qubes users. Since these are not essential for all Qubes users to read, they are not sent to [qubes-announce](/support/#qubes-announce) in order to keep the volume on that list low. However, we expect that most users, especially novice users, will find them helpful. If you are interested in these additional items, we encourage you to subscribe to the [Qubes News RSS feed](/feed.xml) or join one of our other [venues](/support/), where these news items are also announced.
+
+For more information about Qubes OS Project security, please see the [security center](/security/).
+
+### Backups
+
+It is extremely important to make regular backups so that you don't lose your data unexpectedly. The [Qubes backup system](/doc/how-to-back-up-restore-and-migrate/) allows you to do this securely and easily.
+
+### Submit your HCL report
+
+Consider giving back to the Qubes community and helping other users by [generating and submitting a Hardware Compatibility List (HCL) report](/doc/how-to-use-the-hcl/#generating-and-submitting-new-reports).
+
+### Get Started
+
+Find out [Getting Started](/doc/getting-started/) with Qubes, check out the other [How-To Guides](/doc/#how-to-guides), and learn about [Templates](/doc/#templates).
+
+## Getting help
+
+* We work very hard to make the [documentation](/doc/) accurate, comprehensive useful and user friendly. We urge you to read it! It may very well contain the answers to your questions. (Since the documentation is a community effort, we'd also greatly appreciate your help in [improving](/doc/how-to-edit-the-documentation/) it!)
+
+* If issues arise during installation, see the [Installation Troubleshooting](/doc/installation-troubleshooting) guide. 
+
+* If you don't find your answer in the documentation, please see [Help, Support, Mailing Lists, and Forum](/support/) for places to ask.
+
+* Please do **not** email individual members of the Qubes team with questions about installation or other problems. Instead, please see [Help, Support, Mailing Lists, and Forum](/support/) for appropriate places to ask questions.

From c88aed00ebbebdb489b25af21a749a78d290e72c Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sun, 14 Apr 2024 01:38:06 +0000
Subject: [PATCH 116/332] Update installation guide for 4,2

---
 .../installation-guide.md                     | 74 ++++++++-----------
 1 file changed, 30 insertions(+), 44 deletions(-)

diff --git a/user/downloading-installing-upgrading/installation-guide.md b/user/downloading-installing-upgrading/installation-guide.md
index 6c9361ad..5f867684 100644
--- a/user/downloading-installing-upgrading/installation-guide.md
+++ b/user/downloading-installing-upgrading/installation-guide.md
@@ -111,19 +111,21 @@ Once you access your computer's BIOS or UEFI menu, you'll want to go to the "boo
 
 Once you're done on the boot menu, save your changes. How you do this depends on your BIOS or UEFI, but the instructions should be displayed right there on the screen or in a nearby tab. (If you're not sure whether you've saved your changes correctly, you can always reboot your computer and go back into the boot menu to check whether it still reflects your changes.) Once your BIOS or UEFI is configured the way you want it, reboot your computer. This time, don't press any special keys. Instead, let the BIOS or UEFI load and let your computer boot from your USB drive. If you're successful in this step, after a few seconds you'll be presented with the Qubes installer screen:
 
-[![Boot screen](/attachment/doc/boot-screen.png)](/attachment/doc/boot-screen.png)
+[![Boot screen](/attachment/doc/boot-screen-4.2.png)](/attachment/doc/boot-screen-4.2.png)
 
-From here, you can navigate the boot screen using the arrow keys on your keyboard. Pressing the "Tab" key will reveal options. You can choose one of three options:
+From here, you can navigate the boot screen using the arrow keys on your keyboard. Pressing the "Tab" key will reveal options. You can choose one of five options:
 
 * Install Qubes OS
 * Test this media and install Qubes OS
-* Troubleshooting
+* Troubleshooting - verbose boot
+* Rescue a Qubes SO system
+* Install Qubes OS 4.2.1 using kernel-latest
  
 Select the option to test this media and install Qubes OS. 
 
 <div class="alert alert-info" role="alert">
   <i class="fa fa-info-circle"></i>
-  <b>Note:</b> If the latest stable release is not compatible with your hardware, you may wish to consider <a href="/doc/testing/">testing a newer release</a>.
+  <b>Note:</b> If the latest stable release is not compatible with your hardware, you may wish to consider installing using the latest kernel. Be aware that this has not been as well testes as the standard kernel.
 </div>
 
 If the boot screen does not appear, there are several options to troubleshoot. First, try rebooting your computer. If it still loads your currently installed operating system or does not detect your installation medium, make sure the boot order is set up appropriately. The process to change the boot order varies depending on the currently installed system and the motherboard manufacturer. If **Windows 10** is installed on your machine, you may need to follow specific instructions to change the boot order. This may require an [advanced reboot](https://support.microsoft.com/en-us/help/4026206/windows-10-find-safe-mode-and-other-startup-settings).
@@ -132,7 +134,7 @@ If the boot screen does not appear, there are several options to troubleshoot. F
 
 On the first screen, you are asked to select the language that will be used during the installation process. When you are done, select **Continue**.
 
-[![welcome](/attachment/doc/welcome-to-qubes-os-installation-screen.png)](/attachment/doc/welcome-to-qubes-os-installation-screen.png)
+[![Language selection window](/attachment/doc/welcome-to-qubes-os-installation-screen-4.2.png)](/attachment/doc/welcome-to-qubes-os-installation-screen-4.2.png)
 
 Prior to the next screen, a compatibility test runs to check whether IOMMU-virtualization is active or not. If the test fails, a window will pop up. 
 
@@ -153,7 +155,7 @@ Like Fedora, Qubes OS uses the Anaconda installer. Those that are familiar with
 
 The Installation summary screen allows you to change how the system will be installed and configured, including localization settings. At minimum, you are required to select the storage device on which Qubes OS will be installed. 
 
-[![Installation summary not ready](/attachment/doc/installation-summary-not-ready.png)](/attachment/doc/installation-summary-not-ready.png)
+[![Installation summary screen awaiting input ](/attachment/doc/installation-summary-not-ready-4.2.png)](/attachment/doc/installation-summary-not-ready-4.2.png)
 
 ### Localization
 
@@ -170,24 +172,6 @@ You can have as many keyboard layout and languages as you want. Post-install, yo
 Don't forget to select your time and date by clicking on the Time & Date entry.
 
 [![Time and date](/attachment/doc/time-and-date.png)](/attachment/doc/time-and-date.png)
-
-### Software
-
-[![Add-ons](/attachment/doc/add-ons.png)](/attachment/doc/add-ons.png)
-
-On the software selection tab, you can choose which software to install in Qubes OS. Two options are available:
-
-* **Debian:** Select this option if you would like to use [Debian](/doc/templates/debian/) qubes in addition to the default Fedora qubes.
-* **Whonix:** Select this option if you would like to use [Whonix](https://www.whonix.org/wiki/Qubes) qubes. Whonix allows you to use [Tor](https://www.torproject.org/) securely within Qubes.
-
-Whonix lets you route some or all of your network traffic through Tor for greater privacy. Depending on your threat model, you may need to install Whonix templates right away.
-
-Regardless of your choices on this screen, you will always be able to install these and other [templates](/doc/templates/) later. If you're short on disk space, you may wish to deselect these options.
-
-By default, Qubes OS comes preinstalled with the lightweight Xfce4 desktop environment. Other desktop environments will be available to you after the installation is completed, though they may not be officially supported (see [advanced topics](/doc/#advanced-topics)).
-
-Press **Done** to go back to the installation summary screen.
-
 ### Installation destination
 
 Under the System section, you must choose the installation destination. Select the storage device on which you would like to install Qubes OS.
@@ -206,7 +190,7 @@ Your installation destination can be an internal or external storage drive, such
 
 Installing an operating system onto a USB drive can be a convenient way to try Qubes. However, USB drives are typically much slower than internal SSDs. We recommend a very fast USB 3.0 drive for decent performance. Please note that a minimum storage of 32 GiB is required. If you want to install Qubes OS onto a USB drive, just select the USB device as the target installation device. Bear in mind that the installation process is likely to take longer than it would on an internal storage device.
 
-[![Select storage device](/attachment/doc/select-storage-device.png)](/attachment/doc/select-storage-device.png)
+[![Select storage device screen](/attachment/doc/select-storage-device-4.2.png)](/attachment/doc/select-storage-device-4.2.png)
 
 <div class="alert alert-success" role="alert">
   <i class="fa fa-check-circle"></i>
@@ -220,21 +204,22 @@ As soon as you press **Done**, the installer will ask you to enter a passphrase
   <b>Warning:</b> If you forget your encryption passphrase, there is no way to recover it.
 </div>
 
-[![Select storage passhprase](/attachment/doc/select-storage-passphrase.png)](/attachment/doc/select-storage-passphrase.png)
-
-When you're ready, press **Begin Installation**.
-
-[![Installation summary ready](/attachment/doc/installation-summary-ready.png)](/attachment/doc/installation-summary-ready.png)
+[![Select storage passphrase](/attachment/doc/select-storage-passphrase.png)](/attachment/doc/select-storage-passphrase.png)
 
 ### Create your user account
 
-While the installation process is running, you can create your user account. This is what you'll use to log in after disk decryption and when unlocking the screen locker. This is a purely local, offline account in dom0. By design, Qubes OS is a single-user operating system, so this is just for you.
+Select "User Creation" to create your user account. This is what you'll use to log in after disk decryption and when unlocking the screen locker. This is a purely local, offline account in dom0. By design, Qubes OS is a single-user operating system, so this is just for you.
 
-Select **User Creation** to define a new user with administrator privileges and a password. Just as for the disk encryption, this password should be complex. The root account is deactivated and should remain as such.
+The new user you create has full administrator privileges and is protected by a password. Just as for the disk encryption, this password should be complex. The root account is deactivated and should remain as such.
 
-[![Account name and password](/attachment/doc/account-name-and-password.png)](/attachment/doc/account-name-and-password.png)
+[![Account name and password creation window. ](/attachment/doc/account-name-and-password-4.2.png)](/attachment/doc/account-name-and-password-4.2.png)
 
-When the installation is complete, press **Reboot**. Don't forget to remove the installation medium, or else you may end up seeing the installer boot screen again.
+### Installation
+When you have completed all the items marked with the warning icon, press **Begin Installation**.
+
+Installation can take some time. 
+[![Windows showing installation complete and Reboot button. ](/attachment/doc/installation-complete-4.2.png)](/attachment/doc/installation-complete-4.2.png)
+When the installation is complete, press **Reboot System**. Don't forget to remove the installation medium, or else you may end up seeing the installer boot screen again.
 
 ## Post-installation
 
@@ -252,25 +237,25 @@ Just after this screen, you will be asked to enter your encryption passphrase.
 
 You're almost done. Before you can start using Qubes OS, some configuration is needed. 
 
-[![Initial setup menu](/attachment/doc/initial-setup-menu.png)](/attachment/doc/initial-setup-menu.png)
+[![Window with link for final configuration ](/attachment/doc/initial-setup-menu.png)](/attachment/doc/initial-setup-menu.png)
+[![Initial configuration menu](/attachment/doc/initial-setup-menu-configuration-4.2.png)](/attachment/doc/initial-setup-menu-configuration-4.2.png)
 
 By default, the installer will create a number of qubes (depending on the options you selected during the installation process). These are designed to give you a more ready-to-use environment from the get-go.
 
-[![Initial setup menu configuration](/attachment/doc/initial-setup-menu-configuration.png)](/attachment/doc/initial-setup-menu-configuration.png)
-
 Let's briefly go over the options:
 
-* **Create default system qubes:** These are the core components of the system, required for things like internet access.
+* **Templates Configuration:** Here you can decide which [templates](../templates/) you want to have installed, and which will be the default template.
+* **Create default system qubes:** These are the core components of the system, required for things like internet access. You can opt to have some created as [disposables](../glossary#disposable)
 * **Create default application qubes:** These are how you compartmentalize your digital life. There's nothing special about the ones the installer creates. They're just suggestions that apply to most people. If you decide you don't want them, you can always delete them later, and you can always create your own.
-* **Create Whonix Gateway and Workstation qubes:** If you want to use Whonix, you should select this option.
-  * **Enabling system and template updates over the Tor anonymity network using Whonix:** If you select this option, then whenever you install or update software in dom0 or a template, the internet traffic will go through Tor.
-* **Create USB qube holding all USB controllers:** Just like the network qube for the network stack, the USB qube isolates the USB controllers.
+* **Use a qube to hold all USB controllers:** Just like the network qube for the network stack, the USB qube isolates the USB controllers.
   * **Use sys-net qube for both networking and USB devices:** You should select this option if you rely on a USB device for network access, such as a USB modem or a USB Wi-Fi adapter.
-* **Do not configure anything:** This is for very advanced users only. If you select this option, you'll have to set everything up manually afterward.
+* **Create Whonix Gateway and Workstation qubes:** If you want to use [Whonix](https://www.whonix.org/wiki/Qubes), you should select this option.
+  * **Enabling system and template updates over the Tor anonymity network using Whonix:** If you select this option, then whenever you install or update software in dom0 or a template, the internet traffic will go through Tor.
+* **Do not configure anything:** This is for very advanced users only. If you select this option, you will have to manually set up everything.
 
-When you're satisfied with you choices, press **Done**. This configuration process may take a while, depending on the speed and compatibility of your system.
+When you're satisfied with your choices, press **Done**. This configuration process may take a while, depending on the speed and compatibility of your system.
 
-After the configuration is done, you will be greeted by the login screen. Enter your password and log in.
+After configuration is done, you will be greeted by the login screen. Enter your password and log in.
 
 [![Login screen](/attachment/doc/login-screen.png)](/attachment/doc/login-screen.png)
 
@@ -313,3 +298,4 @@ Find out [Getting Started](/doc/getting-started/) with Qubes, check out the othe
 * If you don't find your answer in the documentation, please see [Help, Support, Mailing Lists, and Forum](/support/) for places to ask.
 
 * Please do **not** email individual members of the Qubes team with questions about installation or other problems. Instead, please see [Help, Support, Mailing Lists, and Forum](/support/) for appropriate places to ask questions.
+

From ca07c192fc9f07a114fa7cee1a59d882cd968ab4 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sun, 14 Apr 2024 12:20:42 +0000
Subject: [PATCH 117/332] Update installation guide for 4.2 with more
 screenshots

---
 user/downloading-installing-upgrading/installation-guide.md | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/user/downloading-installing-upgrading/installation-guide.md b/user/downloading-installing-upgrading/installation-guide.md
index 5f867684..7b755c34 100644
--- a/user/downloading-installing-upgrading/installation-guide.md
+++ b/user/downloading-installing-upgrading/installation-guide.md
@@ -231,13 +231,14 @@ If the installation was successful, you should now see the GRUB menu during the
 
 Just after this screen, you will be asked to enter your encryption passphrase.
 
-[![Unlock storage device screen](/attachment/doc/unlock-storage-device-screen.png)](/attachment/doc/unlock-storage-device-screen.png)
+[![Screen to enter device decryption password](/attachment/doc/unlock-storage-device-screen-4.2.png)](/attachment/doc/unlock-storage-device-screen-4.2.png)
 
 ### Initial Setup
 
 You're almost done. Before you can start using Qubes OS, some configuration is needed. 
 
-[![Window with link for final configuration ](/attachment/doc/initial-setup-menu.png)](/attachment/doc/initial-setup-menu.png)
+[![Window with link for final configuration ](/attachment/doc/initial-setup-menu-4.2.png)](/attachment/doc/initial-setup-menu-4.2.png)
+Click on the item marked with the warning triangle to enter the configuration screen.
 [![Initial configuration menu](/attachment/doc/initial-setup-menu-configuration-4.2.png)](/attachment/doc/initial-setup-menu-configuration-4.2.png)
 
 By default, the installer will create a number of qubes (depending on the options you selected during the installation process). These are designed to give you a more ready-to-use environment from the get-go.

From 39a9cf22839ec630358d2fc499b7eaf22972bc0e Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sun, 14 Apr 2024 14:06:47 +0000
Subject: [PATCH 118/332] Clarify levels of salting, and use of state.apply.
 make language consistent

---
 user/advanced-topics/salt.md | 126 ++++++++++++++++++++---------------
 1 file changed, 72 insertions(+), 54 deletions(-)

diff --git a/user/advanced-topics/salt.md b/user/advanced-topics/salt.md
index e5495377..8ea97e9c 100644
--- a/user/advanced-topics/salt.md
+++ b/user/advanced-topics/salt.md
@@ -31,7 +31,7 @@ its clients (called *minions*).
 In typical situations, it is intended that the administrator interacts only
 with the master and keeps the configurations there.
 In Qubes, we don't have a master.
-Instead we have one minion which resides in `dom0` and manages domains from
+Instead we have one minion which resides in `dom0` and manages qubes from
 there.
 This setup is also supported by Salt.
 
@@ -61,8 +61,26 @@ enforcing the state in a particular area.
 It exposes some *imperative* functions for the administrator.
 For example, there is a `system` module that has a `system.halt` function that,
 when issued, will immediately halt a domain.
-There is another function called `state.apply` which will synchronize the
-state of the system with the administrator's configuration/desires.
+
+In salt, there are different levels of functionality.
+The lowest level is a single state function, called like
+this `state.single pkg.installed name=firefox-esr`
+When the system compiles data from sls formulas, it generates *chunks* -
+low chunks are at the bottom of the compiler . You can call them with
+`state.low`
+Next up is the *lowstate* level - this is the list of all low chunks in
+order. - To see them you have `state.show_lowstate`, and use `state.lowstate` to apply them.
+At the top level is *highstate* - this is an interpretation of **all** the data represented in YAML
+in sls files. You can view it with `state.show_highstate`.
+
+When you want to apply a configuration, you can use `qubesctl state.highstate.`
+This will apply all the states you have included in highstate.
+
+There is another function, `state.apply`; `state.apply` has two uses.
+When used on its own, it will apply *highstate* - all the configuration that has been enabled.
+It can also be used to apply a specific state, like this: `state.apply browser` - this will apply the state specified in `browser.sls`.
+
+For simplicity we will use `state.apply` through this page, when we want to apply all configured states.
 
 ### Configuration
 
@@ -126,11 +144,11 @@ The official documentation has more details on the
 When configuring a system you will write one or more state files (`*.sls`) and
 put (or symlink) them into the main Salt directory `/srv/salt/`.
 Each state file contains multiple states and should describe some unit of
-configuration (e.g., a state file `mail.sls` could setup a VM for e-mail).
+configuration (e.g., a state file `mail.sls` could setup a qube for e-mail).
 
 #### Top Files
 
-After you have several state files, you need something to assign them to a VM.
+After you have several state files, you need something to assign them to a qube.
 This is done by `*.top` files ([official documentation](https://docs.saltproject.io/en/latest/ref/states/top.html)).
 Their structure looks like this:
 
@@ -142,8 +160,8 @@ environment:
 ```
 
 In most cases, the environment will be called `base`.
-The `target_matching_clause` will be used to select your minions (VMs).
-It can be either the name of a VM or a regular expression.
+The `target_matching_clause` will be used to select your minions (Templates or qubes).
+It can be either the name of a qube or a regular expression.
 If you are using a regular expressions, you need to give Salt a hint you are
 doing so:
 
@@ -212,17 +230,17 @@ However, the states that are part of the standard Qubes distribution are mostly
 templates and the configuration is done in pillars from formulas.
 
 The formulas are in `/srv/formulas`, including stock formulas for domains in
-`/srv/formulas/dom0/virtual-machines-formula/qvm`, which are used by firstboot.
+`/srv/formulas/dom0/virtual-machines-formula/qvm`, which are used by first boot.
 
 Because we use some code that is not found in older versions of Salt, there is
 a tool called `qubesctl` that should be run instead of `salt-call --local`.
 It accepts all the same arguments of the vanilla tool.
 
-## Configuring a VM's System from Dom0
+## Configuring a qube's System from Dom0
 
-Salt in Qubes can be used to configure VMs from dom0.
-Simply set the VM name as the target minion name in the top file.
-You can also use the `qubes` pillar module to select VMs with a particular
+Salt can be used to configure qubes from dom0.
+Simply set the qube name as the target minion name in the top file.
+You can also use the `qubes` pillar module to select qubes with a particular
 property (see below).
 If you do so, then you need to pass additional arguments to the `qubesctl` tool:
 
@@ -250,28 +268,28 @@ To apply a state to all templates, call `qubesctl --templates state.apply`.
 
 The actual configuration is applied using `salt-ssh` (running over `qrexec`
 instead of `ssh`).
-Which means you don't need to install anything special in a VM you want to
+Which means you don't need to install anything special in a qube you want to
 manage.
-Additionally, for each target VM, `salt-ssh` is started from a temporary VM.
-This way dom0 doesn't directly interact with potentially malicious target VMs;
-and in the case of a compromised Salt VM, because they are temporary, the
-compromise cannot spread from one VM to another.
+Additionally, for each target qube, `salt-ssh` is started from a temporary qube.
+This way dom0 doesn't directly interact with potentially malicious target qubes;
+and in the case of a compromised Salt qube, because they are temporary, the
+compromise cannot spread from one qube to another.
 
 Beginning with Qubes 4.0 and after [QSB #45](/news/2018/12/03/qsb-45/), we implemented two changes:
 
-1. Added the `management_dispvm` VM property, which specifies the disposable
+1. Added the `management_dispvm` qube property, which specifies the disposable
    Template that should be used for management, such as Salt
    configuration.  App qubes inherit this property from their
    parent templates.  If the value is not set explicitly, the default
    is taken from the global `management_dispvm` property. The
-   VM-specific property is set with the `qvm-prefs` command, while the
+   qube-specific property is set with the `qvm-prefs` command, while the
    global property is set with the `qubes-prefs` command.
 
 2. Created the `default-mgmt-dvm` disposable template, which is hidden from
    the menu (to avoid accidental use), has networking disabled, and has
-   a black label (the same as templates). This VM is set as the global
+   a black label (the same as templates). This qube is set as the global
    `management_dispvm`. Keep in mind that this disposable template has full control
-   over the VMs it's used to manage.
+   over the qubes it's used to manage.
 
 ## Writing Your Own Configurations
 
@@ -289,17 +307,17 @@ my new and shiny VM:
       - proxy
 ```
 
-It uses the Qubes-specific `qvm.present` state, which ensures that the domain is
+It uses the Qubes-specific `qvm.present` state, which ensures that the qube is
 present (if not, it creates it).
 
-- The `name` flag informs Salt that the domain should be named `salt-test` (not
+- The `name` flag informs Salt that the qube should be named `salt-test` (not
   `my new and shiny VM`).
-- The `template` flag informs Salt which template should be used for the domain.
-- The `label` flag informs Salt what color the domain should be.
-- The `mem` flag informs Salt how much RAM should be allocated to the domain.
+- The `template` flag informs Salt which template should be used for the qube.
+- The `label` flag informs Salt what color the qube should be.
+- The `mem` flag informs Salt how much RAM should be allocated to the qube.
 - The `vcpus` flag informs Salt how many Virtual CPUs should be allocated to the
-  domain
-- The `proxy` flag informs Salt that the domain should be a ProxyVM.
+  qube
+- The `proxy` flag informs Salt that the qube should be a ProxyVM.
 
 As you will notice, the options are the same (or very similar) to those used in
 `qvm-prefs`.
@@ -328,7 +346,7 @@ To apply the state:
 $ qubesctl state.apply
 ```
 
-### Example of Configuring a VM's System from Dom0
+### Example of Configuring Templates from Dom0
 
 Lets make sure that the `mc` package is installed in all templates.
 Similar to the previous example, you need to create a state file
@@ -364,11 +382,11 @@ $ qubesctl --all state.apply
 
 ### `qvm.present`
 
-As in the example above, it creates a domain and sets its properties.
+As in the example above, it creates a qube and sets its properties.
 
 ### `qvm.prefs`
 
-You can set properties of an existing domain:
+You can set properties of an existing qube:
 
 ```
 my preferences:
@@ -377,13 +395,13 @@ my preferences:
     - netvm: sys-firewall
 ```
 
-***Note*** The `name:` option will not change the name of a domain, it will only
-be used to match a domain to apply the configurations to it.
+***Note*** The `name:` option will not change the name of a qube, it will only
+be used to match a qube to apply the configurations to it.
 
 ### `qvm.service`
 
 ```
-services in my domain:
+services in my qube:
   qvm.service:
     - name: salt-test3
     - enable:
@@ -400,18 +418,18 @@ This enables, disables, or sets to default, services as in `qvm-service`.
 
 ### `qvm.running`
 
-Ensures the specified domain is running:
+Ensures the specified qube is running:
 
 ```
-domain is running:
+qube is running:
   qvm.running:
     - name: salt-test4
 ```
 
 ## Virtual Machine Formulae
 
-You can use these formulae to download, install, and configure VMs in Qubes.
-These formulae use pillar data to define default VM names and configuration details.
+You can use these formulae to download, install, and configure qubes in Qubes.
+These formulae use pillar data to define default qube names and configuration details.
 The default settings can be overridden in the pillar data located in:
 
 ```
@@ -419,7 +437,7 @@ The default settings can be overridden in the pillar data located in:
 ```
 
 In dom0, you can apply a single state with `sudo qubesctl state.sls STATE_NAME`.
-For example, `sudo qubesctl state.sls qvm.personal` will create a `personal` VM (if it does not already exist) with all its dependencies (template, `sys-firewall`, and `sys-net`).
+For example, `sudo qubesctl state.sls qvm.personal` will create a `personal` qube (if it does not already exist) with all its dependencies (template, `sys-firewall`, and `sys-net`).
 
 ### Available states
 
@@ -429,16 +447,16 @@ System NetVM
 
 #### `qvm.sys-usb`
 
-System USB VM
+System USB qube
 
 #### `qvm.sys-net-as-usbvm`
 
-System USB VM bundled into NetVM. Do not enable together with `qvm.sys-usb`.
+System USB qube bundled into NetVM. Do not enable together with `qvm.sys-usb`.
 
 #### `qvm.usb-keyboard`
 
-Enable USB keyboard together with USB VM, including for early system boot (for LUKS passhprase).
-This state implicitly creates a USB VM (`qvm.sys-usb` state), if not already done.
+Enable USB keyboard together with USB qube, including for early system boot (for LUKS passhprase).
+This state implicitly creates a USB qube (`qvm.sys-usb` state), if not already done.
 
 #### `qvm.sys-firewall`
 
@@ -525,7 +543,7 @@ Useful options:
 - `--max-concurrency` --- Limits how many templates are updated at the same time.
   Adjust to your available RAM.
   The default is 4, and the GUI updater sets it to 1.
-- `--targets=vm1,vm2,...` --- Limit to specific VMs, instead of all of them.
+- `--targets=vm1,vm2,...` --- Limit to specific qubes, instead of all of them.
   (Use instead of `--templates` or `--standalones`.)
 - `--show-output` --- Show an update summary instead of just OK/FAIL.
 
@@ -539,31 +557,31 @@ Additional pillar data is available to ease targeting configurations (for exampl
 
 ### `qubes:type`
 
-VM type. Possible values:
+qube type. Possible values:
 
-- `admin` - Administration domain (`dom0`)
+- `admin` - Administration qube (`dom0`)
 - `template` - template
-- `standalone` - Standalone VM
+- `standalone` - Standalone qube
 - `app` - Template based app qube
 
 ### `qubes:template`
 
-Template name on which a given VM is based (if any).
+Template name on which a given qube is based (if any).
 
 ### `qubes:netvm`
 
-VM which provides network to the given VM
+qube which provides network to the given qube
 
 ## Debugging
 
-The output for each VM is logged in `/var/log/qubes/mgmt-VM_NAME.log`.
+The output for each qube is logged in `/var/log/qubes/mgmt-VM_NAME.log`.
 
 If the log does not contain useful information:
 1. Run `sudo qubesctl --skip-dom0 --target=VM_NAME state.apply`
-2. When your VM is being started (yellow) press Ctrl-z on qubesctl.
-3. Open terminal in disp-mgmt-VM_NAME.
+2. When your qube is being started (yellow) press Ctrl-z on qubesctl.
+3. Open terminal in disp-mgmt-qube_NAME.
 4. Look at /etc/qubes-rpc/qubes.SaltLinuxVM - this is what is
-   executed in the management VM.
+   executed in the management qube.
 5. Get the last two lines:
 
     ```shell_session
@@ -607,4 +625,4 @@ install template and shutdown updateVM:
 - [Top files](https://docs.saltproject.io/en/latest/ref/states/top.html)
 - [Jinja templates](https://palletsprojects.com/p/jinja/)
 - [Qubes specific modules](https://github.com/QubesOS/qubes-mgmt-salt-dom0-qvm/blob/master/README.rst)
-- [Formulas for default Qubes VMs](https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/tree/master/qvm)
+- [Formulas for default Qubes qubes](https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/tree/master/qvm)

From be6a36f7ea6a53b9593ef5f1def9f26714303aac Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Tue, 16 Apr 2024 07:14:45 -0700
Subject: [PATCH 119/332] Note that 4.2 does not support Debian 11 templates

---
 developer/releases/4_2/release-notes.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/developer/releases/4_2/release-notes.md b/developer/releases/4_2/release-notes.md
index 109becca..9e41bbf0 100644
--- a/developer/releases/4_2/release-notes.md
+++ b/developer/releases/4_2/release-notes.md
@@ -50,6 +50,10 @@ Also see the [full list of open bug reports affecting Qubes 4.2](https://github.
 
 We strongly recommend [updating Qubes OS](/doc/how-to-update/) immediately after installation in order to apply all available bug fixes.
 
+## Notes
+
+- Qubes 4.2 does not support Debian 11 templates (see [supported template releases](/doc/supported-releases/#templates)). Please [upgrade your Debian templates](/doc/templates/debian/#upgrading) to Debian 12.
+
 ## Download
 
 All Qubes ISOs and associated [verification files](/security/verifying-signatures/) are available on the [downloads](/downloads/) page.

From f8326123ca5c693d166e80e40ef8b33ac52c0b12 Mon Sep 17 00:00:00 2001
From: Christian Foerster <christian.foerster@mailfence.com>
Date: Thu, 18 Apr 2024 00:35:20 +0200
Subject: [PATCH 120/332] make easier to resolve conflicts with PR 1372

---
 user/security-in-qubes/mfa.md | 92 ++++++++++++++++++++++++++++++++++-
 1 file changed, 91 insertions(+), 1 deletion(-)

diff --git a/user/security-in-qubes/mfa.md b/user/security-in-qubes/mfa.md
index 2a8a73a2..62a72e17 100644
--- a/user/security-in-qubes/mfa.md
+++ b/user/security-in-qubes/mfa.md
@@ -27,6 +27,94 @@ By default Qubes has two protection mechanisms against attackers.
 The first is full disk encryption and the second the user login screen / lockscreen. 
 This article section concerns only adding multi-factor authentication to the second one.
 
+### Time-based One-time Password (TOTP)
+
+As the name implies, this generates authentication code that is time-dependent. You can save the TOTP secret in a mobile app like [FreeOTP](https://en.wikipedia.org/wiki/FreeOTP)
+and then use it as an additional factor to login to your Qubes system.
+
+> **Warning**: remember to keep backup access codes.
+
+1. Download `google-authenticator` in dom0:
+
+    ```
+    sudo qubes-dom0-update google-authenticator
+    ```
+
+2. Run google authenticator:
+
+    ```
+    google-authenticator
+    ```
+
+3. Walk through the setup instructions 2 which will also generate your QR code for your auth app of choice:
+
+   ```
+   Do you want me to update your “/home/user/.google_authenticator” file (y/n) y
+
+   Do you want to disallow multiple uses of the same authentication token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n)
+
+   By default, tokens are good for 30 seconds, and to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. If you experience problems with poor time synchronization, you can increase the window from its default size of 1:30min to about 4min. Do you want to do so (y/n)
+
+   If the computer that you are logging into isn’t hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s. Do you want to enable rate-limiting (y/n)
+   ```
+
+> **Warning**: in the next session if incorrectly performed, there is the risk of locking yourself out. Before procedding ensure that you have an up-to-date backup.
+>
+> For advanced users, to make sure you can quickly recover, you can also open another loging session in a tty. To do this, you do <kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>F2</kbd> and login normally. Should anything go wrong, as long as you don't shut the computer down, you can still access this tty by entering the same key combination and reverting the changes. After you've opened this "backup" login, you can get to your graphical desktop with <kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>F1</kbd>.
+
+Now we are going to add the authenticator as a login requirement:
+
+1. `sudo authselect create-profile mfa --base-on sssd`
+
+2. Edit the custom system authentication template with `sudo nanois encouraged /etc/authselect/custom/mfa/system-auth`.
+
+   Add the following line right after `auth required pam_faildelay.so delay=2000000`:
+
+   ```
+   auth required pam_google_authenticator.so
+   ```
+
+   After the change, the top of the file should look like this:
+
+   ```
+   {imply "with-smartcard" if "with-smartcard-required"}
+   auth required pam_env.so
+   auth required pam_faildelay.so delay=2000000
+   auth required pam_google_authenticator.so
+   ```
+
+3. Lastly, activate this authentication method with:
+
+   ```
+   sudo authselect select custom/mfa
+   ```
+
+Now you can test by locking the screen with <kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>l</kbd>. If it was successful and you are pleased with the results, restart your computer.
+
+**Note**: When logging in. the first thing you put is the TOTP secret and then the password. This is true in the screen locker and as well as the session manager (the login window that shows right after you put the disk encryption passphrase).
+
+After this is done, its recommended to do a backup. This is because as long as you incude dom0 in the backup, your authentication code will be backed up as well.
+
+#### Troubleshooting
+
+The following assumes you haven't restarted your computer since setting up TOTP secret.
+
+1. Switch to TTY2 with <kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>F2</kbd>.
+2. Revert to the original policy with:
+   ```
+   sudo authselect select sssd
+   ```
+3. Switch back to the graphical desktop with <kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>F1</kbd>. You should be able to login normally (without multi-factor authentication).
+4. Change the mfa custom policy and apply it again.
+
+#### Lost TOTP / authentication device?
+
+In case you've lost your TOTP authentication device, you have two options.
+
+The first option is backup codes. When generating the TOTP secret you must have saved some recovery codes. Those can be used in place of the TOTP code, but they're discarded after use. So make sure you redo the multi-factor authentications intructions.
+
+The second option is recovery from a backup. It will work as long as you included dom0 in said backup. After restoring the dom0 backup, open a terminal in dom0 and the file should be located in `/home/<USER>/home-restore-<DATE>/dom0-home/<USER>/.google_authenticator`.
+
 ### Login with a YubiKey / NitroKey3
 
 The YubiKey / NitroKey3 is a hardware authentication device manufactured by Yubico / NitroKey
@@ -88,7 +176,7 @@ Note that setting up both a YubiKey and a NitroKey3 is not supported.
    Follow the installation instructions on the official [NitroKey 
 website](https://docs.nitrokey.com/software/nitropy/all-platforms/installation).
    
-   **WARNING**: *as of February 2024 the official instructions involve using pipx to
+   **WARNING**: *as of April 2024 the official instructions involve using pipx to
             install the pynitrokey package and its dependencies without any GPG
             verification! This is not a recommended practice, but will soon be
             fixed by NitroKey when they start providing release artifacts with
@@ -157,6 +245,8 @@ the secret for multiple of them, but you must always use the same NitroKey, beca
 HOTP counter will be incremented in dom0 as well as the used NitroKey whenever you make use
 of this method. If you want to switch to a different NitroKey later, delete the file
 `/etc/qubes/yk-keys/nk-hotp-counter` in dom0 first to make it work with a fresh NitroKey 3.
+Do the same if for some reason your counters get desynchronized (it stops working), e.g. due
+to connectivity issues (NitroKey3A Minis are known to wear out quickly).
 
 4. **YubiKey**
 

From bd464e2bfd500c347c195c3671deb312d7f22b94 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Thu, 18 Apr 2024 13:17:22 +0000
Subject: [PATCH 121/332] Fix broken link to news post

---
 user/security-in-qubes/device-handling-security.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/security-in-qubes/device-handling-security.md b/user/security-in-qubes/device-handling-security.md
index 233b1ab3..2301020f 100644
--- a/user/security-in-qubes/device-handling-security.md
+++ b/user/security-in-qubes/device-handling-security.md
@@ -71,4 +71,4 @@ Locking the screen (with a traditional password) does not solve the problem, bec
 One possibility is to set up the screen locker to require an additional step to unlock (i.e., two-factor authentication).
 One way to achieve this is to use a [YubiKey](/doc/YubiKey/), or some other hardware token, or even to manually enter a one-time password.
 
-Support for [two factor authentication](/news/2018/09/11/qubes-ctap-proxy/) was recently added, though there are [issues](https://github.com/QubesOS/qubes-issues/issues/4661).
+Support for [two factor authentication](/news/2018/09/11/qubes-u2f-proxy/) was recently added, though there are [issues](https://github.com/QubesOS/qubes-issues/issues/4661).

From 101cad161bfa303b5460f7becb1980e5cb28d7a2 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sat, 20 Apr 2024 13:31:58 +0000
Subject: [PATCH 122/332] Minimal templates - suggest ntpd in Debian minimal
 templates

---
 user/templates/minimal-templates.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/templates/minimal-templates.md b/user/templates/minimal-templates.md
index 6fe840be..7940018a 100644
--- a/user/templates/minimal-templates.md
+++ b/user/templates/minimal-templates.md
@@ -242,8 +242,8 @@ list of packages to be installed):
 - [FirewallVM](/doc/firewall/), such as the template for `sys-firewall`: at
   least `qubes-core-agent-networking`, and also `qubes-core-agent-dom0-updates`
   if you want to use it as the `UpdateVM` (which is normally `sys-firewall`).
-- NetVM, such as the template for `sys-net`: `qubes-core-agent-networking`
-  `qubes-core-agent-network-manager` `systemd-timesyncd`(or other NTP Service).
+- NetVM, such as the template for `sys-net`: `qubes-core-agent-networking`,
+  `qubes-core-agent-network-manager`, `ntpd` (or other NTP Service).
   If your network devices need extra packages for a network VM, use the `lspci` command to identify the devices,
   then find the package that provides necessary firmware and install it. If you
   need utilities for debugging and analyzing network connections, install the

From 387619a113df3994e640934a30d8d6a318d52a28 Mon Sep 17 00:00:00 2001
From: "Dr. Gerhard Weck" <GerhardWeck@online.de>
Date: Tue, 23 Apr 2024 12:20:11 +0200
Subject: [PATCH 123/332] Add information on manual download of QWT

---
 user/templates/windows/qubes-windows-tools-4-1.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/user/templates/windows/qubes-windows-tools-4-1.md b/user/templates/windows/qubes-windows-tools-4-1.md
index 338af8af..59b0e58f 100644
--- a/user/templates/windows/qubes-windows-tools-4-1.md
+++ b/user/templates/windows/qubes-windows-tools-4-1.md
@@ -26,7 +26,7 @@ Qubes Windows Tools (QWT) are a set of programs and drivers that provide integra
 - **Audio** - Audio support is available even without QWT installation if `qvm-features audio-model` is set as `ich6`
 
 
-**Note:** Due to the security problems described in [QSB-091](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-091-2023.txt), installation of Qubes Windows Tools is currently blocked. Instead, a text file containing a warning is displayed. Currently, it is difficult to estimate the severity of the risks posed by the sources of the Xen drivers used in QWT possibly being compromised, so it was decided not to offer direct QWT installation until this problem could be treated properly. While Windows qubes are, in Qubes, generally not regarded as being very trustworthy, a possible compromise of the Xen drivers used in Qubes Windows Tools might create a risk for Xen or dom0 and thus be dangerous for Qubes itself. If you **understand** this risk and are **willing to take it**, you can still install the previous versions of Qubes Windows Tools, using the command
+**Note:** Due to the security problems described in [QSB-091](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-091-2023.txt), installation of Qubes Windows Tools is currently blocked. Instead, a text file containing a warning is displayed. Currently, it is difficult to estimate the severity of the risks posed by the sources of the Xen drivers used in QWT possibly being compromised, so it was decided not to offer direct QWT installation until this problem could be treated properly. While Windows qubes are, in Qubes, generally not regarded as being very trustworthy, a possible compromise of the Xen drivers used in Qubes Windows Tools might create a risk for Xen or `dom0` and thus be dangerous for Qubes itself. This risk may be small or even non-existent, as stated in QSB-091. If you **understand** this risk and are **willing to take it**, you can still install the previous versions of Qubes Windows Tools, using the command
 
 	sudo qubes-dom0-update qubes-windows-tools-4.1.68
 
@@ -34,9 +34,9 @@ for Qubes R4.1.2, or
 
 	sudo qubes-dom0-update qubes-windows-tools-4.1.69
 
-for Qubes R4.2.0, respectively, instead of the command listed in step 1 of the installation described below. This will provide the .iso file to be presented as installation drive to the Windows qube in step 3 of the QWT installation.
+for Qubes R4.2.0, respectively, instead of the command listed in step 1 of the installation described below. This will provide the .iso file to be presented as an installation drive to the Windows qube in step 3 of the QWT installation.
 
-If you prefer to download the corresponding .rpm files for manual QWT installation, these are still available from the repositories (version [4.1.68-1](https://yum.qubes-os.org/r4.1/current/dom0/fc32/rpm/qubes-windows-tools-4.1.68-1.noarch.rpm) for Qubes R4.1.2 and version [4.1.69-1](https://yum.qubes-os.org/r4.2/current/dom0/fc37/rpm/qubes-windows-tools-4.1.69-1.fc37.noarch.rpm) for Qubes R4.2.0).
+If you prefer to download the corresponding .rpm files for manual QWT installation, these are still available from the repositories (version [4.1.68-1](https://yum.qubes-os.org/r4.1/current/dom0/fc32/rpm/qubes-windows-tools-4.1.68-1.noarch.rpm) for Qubes R4.1.2 and version [4.1.69-1](https://yum.qubes-os.org/r4.2/current/dom0/fc37/rpm/qubes-windows-tools-4.1.69-1.fc37.noarch.rpm) for Qubes R4.2.0). After downloading, copy the file to `dom0` as described in [How to copy from dom0](https://www.qubes-os.org/doc/how-to-copy-from-dom0/#copying-to-dom0) and install it via `sudo dnf install /path/to/rpmfile`. Now you can proceed according to step 3 of the description below.
 
 **Warning**: These older versions of Qubes Windows Tools will be replaced during the next dom0 update by the current dummy version 4.1.70-1. This can be inhibited by appending the line `exclude=qubes-windows-tools` to the file `/etc/dnf/dnf.conf` in dom0. But this will also stop any further QWT updates - so be sure to remove this line when - hopefully - a new functional version 4.1.71-1 of Qubes Windows Tools will be made available!!!
 

From b6b621151c3a03ad490eb4fcfbe7a60abc9851cc Mon Sep 17 00:00:00 2001
From: "Dr. Gerhard Weck" <GerhardWeck@online.de>
Date: Wed, 24 Apr 2024 14:52:14 +0200
Subject: [PATCH 124/332] Update app-menu-shortcut-troubleshooting.mdChange the
 wine description for Qubes R4.2

---
 .../app-menu-shortcut-troubleshooting.md      | 21 ++-----------------
 1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/user/troubleshooting/app-menu-shortcut-troubleshooting.md b/user/troubleshooting/app-menu-shortcut-troubleshooting.md
index 718b5764..aafbbf63 100644
--- a/user/troubleshooting/app-menu-shortcut-troubleshooting.md
+++ b/user/troubleshooting/app-menu-shortcut-troubleshooting.md
@@ -29,7 +29,7 @@ The above image shows that Windows HVMs are also supported (provided that Qubes
 What if my application has not been automatically included in the list of available apps?
 -----------------------------------------------------------------------------------------
 
-Some times applications may not have included a `.desktop` file and may not be detected by `qvm-sync-appmenus`.
+Sometimes applications may not have included a `.desktop` file and may not be detected by `qvm-sync-appmenus`.
 Other times, you may want to make a web shortcut available from the Qubes start menu.
 
 You can manually create new entries in the "available applications" list of shortcuts for all app qubes based on a template.
@@ -116,21 +116,4 @@ Examples: `qvm-run -q -a --service -- %VMNAME% qubes.StartApp+7-Zip-7-Zip_File_M
 
 Note that you can create a shortcut that points to a .desktop file in your app qube with e.g. `qvm-run -q -a --service -- personal qubes.StartApp+firefox`.
 
-While this works well for standard applications, creating a menu entry for Windows application running under wine may need an additional step in order to establish the necessary environment in wine. Installing software under wine may create the needed `.desktop` file in the target Linux VM. This file is expected to be in the directory `~/.local/share/applications`, but it may be that it is stored in a subdirectory thereof, determined by the Windows menu structure, where it may not be found. The solution is to copy or move this file from its location to `~/.local/share/applications`.  The name of this file has to be the name used in the `.desktop` file in dom0. So if the shortcut in dom0 points to  `qvm-run -q -a --service -- personal qubes.StartApp+Excel`, the correspondig file in the AppVM has to be called `Excel.desktop`.
-
-If necessary, you can create the `.desktop` file neeeded to start the wine application manually. For Excel, e.g., it will look like this
-
-~~~
-[Desktop Entry]
-Version=1.0
-Type=Application
-Terminal=false
-X-Qubes-VmName=personal
-Icon=/usr/share/icons/hicolor/48x48/apps/Excel.png
-Name=Microsoft Excel
-Categories=X-Qubes-VM;
-Exec=env WINEPREFIX="/home/user/.wine" /usr/bin/wine C:\\\\windows\\\\command\\\\start.exe /Unix /home/user/.wine/dosdevices/c:/users/user/Start\\ Menu/Programs/Microsoft\ Excel.lnk
-StartupWMClass=Excel.exe
-~~~
-
-The rather complicated line `Exec=...` points to an entry in the Windows menu structure calling Excel, not to the executable itself.
+While this works well for standard applications, creating a menu entry for Windows applications running under wine may need an additional step in order to establish the necessary environment in wine. Installing software under wine may create the needed `.desktop` file in the target Linux VM. If the name of this file contains spaces, it will not be found. The solution is to remove these spaces by renaming the desktop file accordingly. Refreshing the menu structure will then build working menu entries.

From 7b487c54b0680923acabc6e5f32f8098d1ae0e98 Mon Sep 17 00:00:00 2001
From: Karlo Bartha <rixxxxx@users.noreply.github.com>
Date: Thu, 25 Apr 2024 07:39:15 +0200
Subject: [PATCH 125/332] Update minimal-templates.md

add pipewire package name for >= QubesOS 4.2.x
---
 user/templates/minimal-templates.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/templates/minimal-templates.md b/user/templates/minimal-templates.md
index 7940018a..370694c8 100644
--- a/user/templates/minimal-templates.md
+++ b/user/templates/minimal-templates.md
@@ -135,7 +135,7 @@ list of packages to be installed):
 
 - Commonly used utilities: `pciutils` `vim-minimal` `less` `psmisc`
   `gnome-keyring`.
-- Audio: `pulseaudio-qubes`.
+- Audio: `pulseaudio-qubes` (QubesOS version <= 4.1.x) `pipewire-qubes` (QubesOS >= 4.2.x).
 - Networking: `qubes-core-agent-networking`, and whatever network tools
   you want. N.B. minimal templates do not include any browser.
 - [FirewallVM](/doc/firewall/), such as the template for `sys-firewall`: at

From 7a15cd1a162564da3e18efc15a39291b76c57b5d Mon Sep 17 00:00:00 2001
From: "Dmitry V. Levin" <ldv@altlinux.org>
Date: Fri, 26 Apr 2024 08:00:00 +0000
Subject: [PATCH 126/332] Fix a few typos

---
 developer/building/qubes-builder-details.md            | 2 +-
 developer/building/qubes-builder.md                    | 2 +-
 developer/building/qubes-iso-building.md               | 2 +-
 developer/general/package-contributions.md             | 2 +-
 developer/services/qrexec-internals.md                 | 2 +-
 developer/system/gui.md                                | 2 +-
 introduction/issue-tracking.md                         | 2 +-
 introduction/support.md                                | 2 +-
 user/advanced-topics/bind-dirs.md                      | 2 +-
 user/advanced-topics/disposable-customization.md       | 2 +-
 user/advanced-topics/standalones-and-hvms.md           | 2 +-
 user/advanced-topics/volume-backup-revert.md           | 2 +-
 user/hardware/certified-hardware.md                    | 2 +-
 user/how-to-guides/how-to-use-block-storage-devices.md | 2 +-
 user/security-in-qubes/firewall.md                     | 2 +-
 user/troubleshooting/pci-troubleshooting.md            | 2 +-
 16 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/developer/building/qubes-builder-details.md b/developer/building/qubes-builder-details.md
index ad2b79f8..1f5e9f3f 100644
--- a/developer/building/qubes-builder-details.md
+++ b/developer/building/qubes-builder-details.md
@@ -14,7 +14,7 @@ title: Qubes builder details
 <div class="alert alert-warning" role="alert">
   <i class="fa fa-exclamation-circle"></i>
   <b>Note:</b> This information concerns the old Qubes builder (v1). It supports
-  only building Qubes 4.1 or earlier.<br>The build process has been completely rewritten in <a href="https://github.com/QubesOS/qubes-builderv2/">qubes-builder v2</a>. This can be be used for building Qubes R4.1 and later, and all related components.</div>
+  only building Qubes 4.1 or earlier.<br>The build process has been completely rewritten in <a href="https://github.com/QubesOS/qubes-builderv2/">qubes-builder v2</a>. This can be used for building Qubes R4.1 and later, and all related components.</div>
 
 Components Makefile.builder file
 --------------------------------
diff --git a/developer/building/qubes-builder.md b/developer/building/qubes-builder.md
index 4f7b0291..31755705 100644
--- a/developer/building/qubes-builder.md
+++ b/developer/building/qubes-builder.md
@@ -13,7 +13,7 @@ title: Qubes builder
 <div class="alert alert-warning" role="alert">
   <i class="fa fa-exclamation-circle"></i>
   <b>Note:</b> These instructions concern the older Qubes builder (v1). It supports
-  only building Qubes 4.1 or earlier.<br>The build process has been completely rewritten in <a href="https://github.com/QubesOS/qubes-builderv2/">qubes-builder v2</a>. This can be be used for building Qubes R4.1 and later, and all related components.
+  only building Qubes 4.1 or earlier.<br>The build process has been completely rewritten in <a href="https://github.com/QubesOS/qubes-builderv2/">qubes-builder v2</a>. This can be used for building Qubes R4.1 and later, and all related components.
 </div>
 
 **Note: See [ISO building instructions](/doc/qubes-iso-building/) for a streamlined overview on how to use the build system.**
diff --git a/developer/building/qubes-iso-building.md b/developer/building/qubes-iso-building.md
index ac075443..a8d6cd57 100644
--- a/developer/building/qubes-iso-building.md
+++ b/developer/building/qubes-iso-building.md
@@ -15,7 +15,7 @@ title: Qubes ISO building
 <div class="alert alert-warning" role="alert">
   <i class="fa fa-exclamation-circle"></i>
   <b>Note:</b> These instructions concern the older Qubes builder (v1). It supports
-  only building Qubes 4.1 or earlier.<br>The build process has been completely rewritten in <a href="https://github.com/QubesOS/qubes-builderv2/">qubes-builder v2</a>. This can be be used for building Qubes R4.1 and later, and all related components.
+  only building Qubes 4.1 or earlier.<br>The build process has been completely rewritten in <a href="https://github.com/QubesOS/qubes-builderv2/">qubes-builder v2</a>. This can be used for building Qubes R4.1 and later, and all related components.
 </div>
 
 Build Environment
diff --git a/developer/general/package-contributions.md b/developer/general/package-contributions.md
index f73c9bd2..f0f1af06 100644
--- a/developer/general/package-contributions.md
+++ b/developer/general/package-contributions.md
@@ -71,7 +71,7 @@ The review procedure is as follows:
 1. Someone, S, wishes to make a change to a package, P.
 2. S submits a fast-forwardable pull request against the fork of P's repo owned by [QubesOS-contrib](https://github.com/QubesOS-contrib).
 3. The PM reviews the pull request.
-   If the the pull request passes the PM's review, the PM adds a [signed](/doc/code-signing/) *comment* on the pull request stating that it has passed review.
+   If the pull request passes the PM's review, the PM adds a [signed](/doc/code-signing/) *comment* on the pull request stating that it has passed review.
    (In cases in which S = PM, the PM can simply add a [signed](/doc/code-signing/) *tag* to the HEAD commit prior to submitting the pull request.)
    If the pull request does not pass the PM's review, the PM leaves a comment on the pull request explaining why not.
 4. The QCR reviews the pull request.
diff --git a/developer/services/qrexec-internals.md b/developer/services/qrexec-internals.md
index 72a2b8c1..8f0a10ac 100644
--- a/developer/services/qrexec-internals.md
+++ b/developer/services/qrexec-internals.md
@@ -251,6 +251,6 @@ It is a [socket-based Qubes RPC service](/doc/qrexec-socket-services/). Requests
 There are two endpoints:
 
 - `policy.Ask` - ask the user about whether to execute a given action
-- `policy.Notify` - notify the user about about an action.
+- `policy.Notify` - notify the user about an action.
 
 See [qrexec-policy-agent.rst](https://github.com/QubesOS/qubes-core-qrexec/blob/master/Documentation/qrexec-policy-agent.rst) for protocol details.
diff --git a/developer/system/gui.md b/developer/system/gui.md
index ff2dc866..dfd04801 100644
--- a/developer/system/gui.md
+++ b/developer/system/gui.md
@@ -49,7 +49,7 @@ In the case of Qubes, `qubes-gui` does not transfer all changed pixels via vchan
   and pass this to dom0 via the deprecated `MFNDUMP` message.
 - New `qubes-gui` versions will rely on `qubes-drv` having allocated
   memory using gntalloc, and then pass the grant table indexes gntalloc
-  has chosen to the GUI daemon using using the `WINDOW_DUMP` message.
+  has chosen to the GUI daemon using the `WINDOW_DUMP` message.
 
 Now, `qubes-guid` has to tell the dom0 Xorg server about the location of the buffer.
 There is no supported way (e.g. Xorg extension) to do this zero-copy style.
diff --git a/introduction/issue-tracking.md b/introduction/issue-tracking.md
index 80d6dd08..3296210e 100644
--- a/introduction/issue-tracking.md
+++ b/introduction/issue-tracking.md
@@ -67,7 +67,7 @@ There are three issue **types**: `T: bug`, `T: enhancement`, and `T: task`.
 - `T: enhancement` --- Type: enhancement. A new feature that does not yet exist **or** improvement of existing functionality.
 - `T: task` --- Type: task. An action item that is neither a bug nor an enhancement.
 
-Every open issue should have **exactly one** type. An open issue should not have more than one type, and it should not lack a type entirely. Bug reports are for problems in things that already exist. If something doesn't exist yet, but you think it ought to exist, then use `T: enhancement` instead. If something already exists, but you think it could be improved in some way, you should again use `T: enhancement`. `T: task` is for issues that fall under under neither `T: bug` nor `T: enhancement`.
+Every open issue should have **exactly one** type. An open issue should not have more than one type, and it should not lack a type entirely. Bug reports are for problems in things that already exist. If something doesn't exist yet, but you think it ought to exist, then use `T: enhancement` instead. If something already exists, but you think it could be improved in some way, you should again use `T: enhancement`. `T: task` is for issues that fall under neither `T: bug` nor `T: enhancement`.
 
 #### Priority
 
diff --git a/introduction/support.md b/introduction/support.md
index 1d818d25..b12bb55f 100644
--- a/introduction/support.md
+++ b/introduction/support.md
@@ -419,7 +419,7 @@ account is **not** required. Any email address will work.) To post a message to
 the list, address your email to `qubes-project@googlegroups.com`. If your post
 does not appear immediately, please allow time for moderation to occur. To
 unsubscribe, send a blank email to
-`qubes-project+unsubscribe@googlegroups.com`. This list also also has a
+`qubes-project+unsubscribe@googlegroups.com`. This list also has a
 [traditional mail
 archive](https://www.mail-archive.com/qubes-project@googlegroups.com/) and an
 optional [Google Groups web
diff --git a/user/advanced-topics/bind-dirs.md b/user/advanced-topics/bind-dirs.md
index c1ecb418..acdc515d 100644
--- a/user/advanced-topics/bind-dirs.md
+++ b/user/advanced-topics/bind-dirs.md
@@ -60,7 +60,7 @@ In this example, we want to make `/var/lib/tor` persistent. Enter all of the fol
 
 From now on, all files in the `/var/lib/tor` directory will persist across reboots.
 
-You can make make as many files or folders persist as you want simply by making multiple entries in the `50_user.conf` file, each on a separate line.
+You can make as many files or folders persist as you want simply by making multiple entries in the `50_user.conf` file, each on a separate line.
 For example, if you added the file `/etc/tor/torrc` to the `binds` variable, any modifications to *that* file would also persist across reboots.
 
 ```
diff --git a/user/advanced-topics/disposable-customization.md b/user/advanced-topics/disposable-customization.md
index 86186de4..7590adb9 100644
--- a/user/advanced-topics/disposable-customization.md
+++ b/user/advanced-topics/disposable-customization.md
@@ -27,7 +27,7 @@ Additionally, if you want to have menu entries for starting applications in disp
 [user@dom0 ~]$ qvm-features <DISPOSABLE_TEMPLATE> appmenus-dispvm 1
 ```
 
-**Note:** Application shortcuts that existed before setting this feature will not be updated automatically. Please go the the "Applications" tab in the qube's "Settings" dialog and unselect all existing shortcuts by clicking "<<", then click "OK" and close the dialog. Give it a few seconds time and then reopen and re-select all the shortcuts you want to see in the menu. See [this page](/doc/managing-appvm-shortcuts) for background information.
+**Note:** Application shortcuts that existed before setting this feature will not be updated automatically. Please go the "Applications" tab in the qube's "Settings" dialog and unselect all existing shortcuts by clicking "<<", then click "OK" and close the dialog. Give it a few seconds time and then reopen and re-select all the shortcuts you want to see in the menu. See [this page](/doc/managing-appvm-shortcuts) for background information.
 
 ## Security
 
diff --git a/user/advanced-topics/standalones-and-hvms.md b/user/advanced-topics/standalones-and-hvms.md
index 3664107b..f2420ffd 100644
--- a/user/advanced-topics/standalones-and-hvms.md
+++ b/user/advanced-topics/standalones-and-hvms.md
@@ -197,7 +197,7 @@ you would install it into a normal HVM. Generally, you should install in to the
 first "system" disk. (Resize it as needed before starting installation.)
 
 You can then create a new qube using the new template. If you use this Template
-as is, then any HVMs based on it it will effectively be disposables. All file
+as is, then any HVMs based on it will effectively be disposables. All file
 system changes will be wiped when the HVM is shut down.
 
 Please see [this
diff --git a/user/advanced-topics/volume-backup-revert.md b/user/advanced-topics/volume-backup-revert.md
index 50351107..85bb4062 100644
--- a/user/advanced-topics/volume-backup-revert.md
+++ b/user/advanced-topics/volume-backup-revert.md
@@ -42,7 +42,7 @@ qvm-volume config vmname:private revisions_to_keep 2
 ```
 
 With the VM stopped, you may revert to an older snapshot of the private volume
-from the the above list of "Available revisions (for revert)", where the last
+from the above list of "Available revisions (for revert)", where the last
 item on the list with the largest integer is the most recent snapshot:
 
 ```
diff --git a/user/hardware/certified-hardware.md b/user/hardware/certified-hardware.md
index dbe50dd3..a5ef3789 100644
--- a/user/hardware/certified-hardware.md
+++ b/user/hardware/certified-hardware.md
@@ -86,7 +86,7 @@ If you are a hardware vendor, you can have your hardware certified as compatible
 
 **Note:** This section describes the requirements for hardware *certification*, *not* the requirements for *running* Qubes OS. For the latter, please see the [system requirements](/doc/system-requirements/). A brief list of the requirements described in this section is available [here](/doc/system-requirements/#qubes-certified-hardware).
 
-A basic requirement is that all Qubes-certified devices must be be available for purchase with Qubes OS preinstalled. Customers may be offered the option to select from a list of various operating systems (or no operating system at all) to be preinstalled, but Qubes OS must be on that list in order to maintain Qubes hardware certification.
+A basic requirement is that all Qubes-certified devices must be available for purchase with Qubes OS preinstalled. Customers may be offered the option to select from a list of various operating systems (or no operating system at all) to be preinstalled, but Qubes OS must be on that list in order to maintain Qubes hardware certification.
 
 One of the most important security improvements introduced with the release of Qubes 4.0 was to replace paravirtualization (PV) technology with **hardware-enforced memory virtualization**, which recent processors have made possible thanks to so-called Second Level Address Translation ([SLAT](https://en.wikipedia.org/wiki/Second_Level_Address_Translation)), also known as [EPT](https://ark.intel.com/Search/FeatureFilter?productType=processors&ExtendedPageTables=true&MarketSegment=Mobile) in Intel parlance. SLAT (EPT) is an extension to Intel VT-x virtualization, which originally was capable of only CPU virtualization but not memory virtualization and hence required a complex Shadow Page Tables approach. We hope that embracing SLAT-based memory virtualization will allow us to prevent disastrous security bugs, such as the infamous [XSA-148](https://xenbits.xen.org/xsa/advisory-148.html), which --- unlike many other major Xen bugs --- regrettably did [affect](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-022-2015.txt) Qubes OS. Consequently, we require SLAT support of all certified hardware beginning with Qubes OS 4.0.
 
diff --git a/user/how-to-guides/how-to-use-block-storage-devices.md b/user/how-to-guides/how-to-use-block-storage-devices.md
index 742ec369..5658682a 100644
--- a/user/how-to-guides/how-to-use-block-storage-devices.md
+++ b/user/how-to-guides/how-to-use-block-storage-devices.md
@@ -122,7 +122,7 @@ If you don't see anything that looks like your drive, run `sudo udevadm trigger
 
 ## Recovering From Premature Device Destruction
 
-If the you fail to detach the device before it's destroyed in the sourceVM (e.g. by physically detaching the thumbdrive), [there will be problems](https://github.com/QubesOS/qubes-issues/issues/1082).
+If you fail to detach the device before it's destroyed in the sourceVM (e.g. by physically detaching the thumbdrive), [there will be problems](https://github.com/QubesOS/qubes-issues/issues/1082).
 
 To recover from this error state, in dom0 run
 
diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index d4597e39..a94f087a 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -284,7 +284,7 @@ Note the IP addresses you will need, they will be required in the next steps.
 
 For the following example, we assume that the physical interface ens6 in sys-net is on the local network 192.168.x.y with the IP 192.168.x.n, and that the IP address of sys-firewall is 10.137.1.z.
 
-In the sys-net VM's Terminal, the first step is to to define an ntables chain that will receive DNAT rules to relay the network traffic on a given port to the qube NetVM, we recommend to define a new chain for each destination qube to ease rules management:
+In the sys-net VM's Terminal, the first step is to define an ntables chain that will receive DNAT rules to relay the network traffic on a given port to the qube NetVM, we recommend to define a new chain for each destination qube to ease rules management:
 
 ```
 nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
diff --git a/user/troubleshooting/pci-troubleshooting.md b/user/troubleshooting/pci-troubleshooting.md
index 42d30254..6c121f10 100644
--- a/user/troubleshooting/pci-troubleshooting.md
+++ b/user/troubleshooting/pci-troubleshooting.md
@@ -104,7 +104,7 @@ While using the `no-strict-reset` flag, do not require PCI device to be reset be
 qvm-pci attach --persistent --option permissive=true --option no-strict-reset=true sys-usb dom0:<BDF_OF_DEVICE>
 ~~~
 
-Be sure to replace `<BDF_OF_DEVICE>` with the BDF of your PCI device, which can be be obtained from running `qvm-pci`.
+Be sure to replace `<BDF_OF_DEVICE>` with the BDF of your PCI device, which can be obtained from running `qvm-pci`.
 
 You can also configure strict reset directly from the Qubes interface by following these steps:
 

From 8805362897fa26b6a527cb3704fd547b4b51a82d Mon Sep 17 00:00:00 2001
From: "Dr. Gerhard Weck" <GerhardWeck@online.de>
Date: Fri, 26 Apr 2024 10:47:38 +0200
Subject: [PATCH 127/332] Clarify renaming of desktop files

---
 .../app-menu-shortcut-troubleshooting.md             | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/user/troubleshooting/app-menu-shortcut-troubleshooting.md b/user/troubleshooting/app-menu-shortcut-troubleshooting.md
index aafbbf63..a64a5d00 100644
--- a/user/troubleshooting/app-menu-shortcut-troubleshooting.md
+++ b/user/troubleshooting/app-menu-shortcut-troubleshooting.md
@@ -101,8 +101,8 @@ $ rm -i ~/.local/share/applications/my-old-vm-*
 Behind the scenes
 -----------------
 
-`qvm-sync-appmenus` works by invoking *GetAppMenus* [Qubes service](/doc/qrexec/) in the target domain.
-This service enumerates installed applications and sends formatted info back to the dom0 script (`/usr/libexec/qubes-appmenus/qubes-receive-appmenus`) which creates .desktop files in the app qube/template directory.
+`qvm-sync-appmenus` works by invoking the *GetAppMenus* [Qubes service](/doc/qrexec/) in the target domain.
+This service enumerates applications installed in that VM and sends formatted info back to the dom0 script (`/usr/libexec/qubes-appmenus/qubes-receive-appmenus`) which creates `.desktop` files in the app qube/template directory of dom0.
 
 For Linux VMs the service script is in `/etc/qubes-rpc/qubes.GetAppMenus`.
 In Windows it's a PowerShell script located in `c:\Program Files\Invisible Things Lab\Qubes OS Windows Tools\qubes-rpc-services\get-appmenus.ps1` by default.
@@ -111,9 +111,11 @@ The list of installed applications for each app qube is stored in dom0's `~/.loc
 Each menu entry is a file that follows the [.desktop file format](https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html) with some wildcards (*%VMNAME%*, *%VMDIR%*).
 Applications selected to appear in the menu are stored in `~/.local/share/qubes-appmenus/<vmname>/apps`.
 
-Actual command lines for the menu shortcuts involve `qvm-run` command which starts a process in another domain.
+Actual command lines for the menu shortcuts involve the `qvm-run` command which starts a process in another domain.
 Examples: `qvm-run -q -a --service -- %VMNAME% qubes.StartApp+7-Zip-7-Zip_File_Manager` or `qvm-run -q -a --service -- %VMNAME% qubes.StartApp+firefox`
 
-Note that you can create a shortcut that points to a .desktop file in your app qube with e.g. `qvm-run -q -a --service -- personal qubes.StartApp+firefox`.
+Note that you can create a shortcut that points to a `.desktop` file in your app qube with e.g. `qvm-run -q -a --service -- personal qubes.StartApp+firefox`.
 
-While this works well for standard applications, creating a menu entry for Windows applications running under wine may need an additional step in order to establish the necessary environment in wine. Installing software under wine may create the needed `.desktop` file in the target Linux VM. If the name of this file contains spaces, it will not be found. The solution is to remove these spaces by renaming the desktop file accordingly. Refreshing the menu structure will then build working menu entries.
+While this works well for standard applications, creating a menu entry for Windows applications running under *wine* may need an additional step in order to establish the necessary environment in *wine*. Installing software under *wine* will create the needed `.desktop` file in the target Linux VM in the directory `~/.local/share/applications/wine/Programs/` or a subdirectory thereof, depending on the Windows menu structure seen under *wine*. If the name of this file contains spaces, it will not be found, because the `qvm-run` command is falsely seen as terminating at this space. The solution is to remove these spaces by renaming the `.desktop` file accordingly, e.g. by renaming `Microsoft Excel.desktop` to `Excel.desktop`. Refreshing the menu structure will then build working menu entries.
+
+**Note:** Applications installed under *wine* are installed in AppVMs, not in the template on which these AppVMs are based, as the file strcuture used by *wine* is stored under `~/.wine`, which is part of the persistent data of the AppVM and not inherited from its template.

From 6fb630189f0a88ba688ca83da41ed5b30986a1f2 Mon Sep 17 00:00:00 2001
From: Aidan Leuenberger <71840866+Ogyeet10@users.noreply.github.com>
Date: Sat, 27 Apr 2024 20:22:27 -0500
Subject: [PATCH 128/332] fixed typo

Qubes OS was misspelled as Qubes SO, fixed.
---
 user/downloading-installing-upgrading/installation-guide.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/downloading-installing-upgrading/installation-guide.md b/user/downloading-installing-upgrading/installation-guide.md
index 7b755c34..acd5a9ec 100644
--- a/user/downloading-installing-upgrading/installation-guide.md
+++ b/user/downloading-installing-upgrading/installation-guide.md
@@ -118,7 +118,7 @@ From here, you can navigate the boot screen using the arrow keys on your keyboar
 * Install Qubes OS
 * Test this media and install Qubes OS
 * Troubleshooting - verbose boot
-* Rescue a Qubes SO system
+* Rescue a Qubes OS system
 * Install Qubes OS 4.2.1 using kernel-latest
  
 Select the option to test this media and install Qubes OS. 

From 661a2ca160c5f34b463385e34df8b6abcb9efb87 Mon Sep 17 00:00:00 2001
From: Ludovic Bellier <lbellier-gth@zyrianes.net>
Date: Sun, 28 Apr 2024 09:32:24 +0000
Subject: [PATCH 129/332] Fix action/options policy separator

---
 user/security-in-qubes/split-gpg.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/security-in-qubes/split-gpg.md b/user/security-in-qubes/split-gpg.md
index a10ca40f..8335d9e6 100644
--- a/user/security-in-qubes/split-gpg.md
+++ b/user/security-in-qubes/split-gpg.md
@@ -140,10 +140,10 @@ work-email  work-gpg  allow
 
 where `work-email` is the Thunderbird + Enigmail app qube and `work-gpg` contains your GPG keys.
 
-You may also edit the qrexec policy file for Split GPG in order to tell Qubes your default gpg vm (qrexec prompts will appear with the gpg vm preselected as the target, instead of the user needing to type a name in manually). To do this, append `,default_target=<vmname>` to `ask` in `/etc/qubes-rpc/policy/qubes.Gpg`. For the examples given on this page:
+You may also edit the qrexec policy file for Split GPG in order to tell Qubes your default gpg vm (qrexec prompts will appear with the gpg vm preselected as the target, instead of the user needing to type a name in manually). To do this, append `default_target=<vmname>` to `ask` in `/etc/qubes-rpc/policy/qubes.Gpg`. For the examples given on this page:
 
 ```
-@anyvm  @anyvm  ask,default_target=work-gpg
+@anyvm  @anyvm  ask default_target=work-gpg
 ```
 
 Note that, because this makes it easier to accept Split GPG's qrexec authorization prompts, it may decrease security if the user is not careful in reviewing presented prompts. This may also be inadvisable if there are multiple app qubes with Split GPG set up.

From 8552da57b7bbb8f2a3b7707e099864a051c8a197 Mon Sep 17 00:00:00 2001
From: Fl1tzi <git@fl1tzi.com>
Date: Wed, 1 May 2024 21:43:01 +0200
Subject: [PATCH 130/332] admin-api: add missing admin.vm.deviceclass.List

---
 developer/services/admin-api.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/developer/services/admin-api.md b/developer/services/admin-api.md
index 8fa12417..0087bcaf 100644
--- a/developer/services/admin-api.md
+++ b/developer/services/admin-api.md
@@ -106,6 +106,7 @@ to set the policy using current mechanism.
 | `admin.vm.firewall.Get`                | vm        | -         | -                                         | `<rule>\n`                                                | rules syntax as in [firewall interface](/doc/vm-interface/#firewall-rules-in-4x) with addition of `expire=` and `comment=` options; `comment=` (if present) must be the last option
 | `admin.vm.firewall.Set`                | vm        | -         | `<rule>\n`                                | -                                                         | set firewall rules, see `admin.vm.firewall.Get` for syntax
 | `admin.vm.firewall.Reload`             | vm        | -         | -                                         | -                                                         | force reload firewall without changing any rule
+| `admin.vm.deviceclass.List`            | `dom0`    | -         | -                                         | `<class>\n`                                               |
 | `admin.vm.device.<class>.Attach`       | vm        | device    | options                                   | -                                                         | `device` is in form `<backend-name>+<device-ident>` <br/>optional options given in `key=value` format, separated with spaces; <br/>options can include `persistent=True` to "persistently" attach the device (default is temporary)
 | `admin.vm.device.<class>.Detach`       | vm        | device    | -                                         | -                                                         | `device` is in form `<backend-name>+<device-ident>`
 | `admin.vm.device.<class>.Set.persistent`| vm       | device    | `True`\|`False`                            | -                                                         | `device` is in form `<backend-name>+<device-ident>`

From 6df6dea5fd992178068cfd1baecb026e6b6b8ea5 Mon Sep 17 00:00:00 2001
From: "Dr. Gerhard Weck" <GerhardWeck@onlinehome.de>
Date: Thu, 10 Aug 2023 13:26:20 +0200
Subject: [PATCH 131/332] Update how-to-organize-your-qubes.md Add an example
 for a simple VM layout

Describe the VMs used by a teacher who has no time to build something complicated
---
 .../how-to-organize-your-qubes.md             | 58 +++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/user/how-to-guides/how-to-organize-your-qubes.md b/user/how-to-guides/how-to-organize-your-qubes.md
index 406d346d..c58411b2 100644
--- a/user/how-to-guides/how-to-organize-your-qubes.md
+++ b/user/how-to-guides/how-to-organize-your-qubes.md
@@ -425,6 +425,64 @@ templates and even her Bitcoin full node qube, but she'll skip them if she
 doesn't have time or space, since she knows she can always recreate them again
 later and download what she needs from the Internet.
 
+## John, the teacher
+
+John is a teacher at a high school, teaching mathematics and history. He is used
+to setting up his workstation but has not the time or inclination to dive deeper
+into technical details. So he has installed Qubes in a rather simple way mainly
+using the installation defaults and just adding a few well-documented features
+like Split GPG.
+
+[![Simple VM setup](/attachment/doc/Simple_Setup.png)](/attachment/doc/Simple_Setup.png)
+
+-	**One qube for surfing.** `untrusted` is just the standard qube coming with the Qubes
+installation, based on the standard Fedora template, but with Thunderbird removed.
+It is intended for surfing arbitrary locations and may be at risk from some websites.
+Consequently, it does not keep any valuable data and has no facilities to view or
+edit office documents.
+
+-	**One offline qube for writing.** `work` is the qube used to edit documents – even
+MS office documents. It is based on an extended Fedora template containing additional
+software like LibreOffice, GIMP, Wine, and some Windows applications. It has no netVM
+and so the risk of an infected document contacting a hacker’s control server is minimized.
+
+- **One qube for access to trusted servers.** `personal` is used to access only trusted
+websites like home banking, and the firewall rules for this qube restrict it to these
+locations. It is based on the same extended Fedora template. John uses this qube for
+access to his mail server, too, but does not process any documents received by mail
+in this qube. Any office documents from this qube are only opened in disposables in order
+to reduce the risk of infection.
+
+- **One qube for preparing teaching material for his students.** `Windows` is the workhorse
+used to execute anything needed for teaching. It is based on a Windows 7 template with QWT
+installed as most of John’s students work with Windows PCs. In order to reduce the risks
+for such an AppVM, and possible risks caused by it, its internet access is limited, again
+by a firewall rule, to the servers providing material for teaching.
+
+- **One qube for protected access to sensible websites.** `whonix` is just the standard
+AppVM `anon-whonix` based on the `whonix-ws` coming with the Qubes installation. It is
+used for all accesses over Tor and could as well be replaced by a disposable. John, who is
+engaged in a project for helping mentally disabled people, uses this qube to avoid tracking
+his access to the project’s server.
+
+- **One offline qube for keeping the private PGP key.** `vault` is the key part of Split GPG,
+just as described in the Qubes documentation, keeping the private PGP key.
+
+- **One offline qube for permanent data storage.** `storage` finally is a qube based on the
+standard Debian template and, having no applications and no network access, it is used
+explicitly and only for permanent data storage, and it is the only qube whose data is regarded
+as valuable and worth keeping. The Fedora-based qubes might even be configured as disposables, and,
+if you are willing to accept the rather slow start of Windows, even the qube `Windows` might be
+created as a disposable.
+
+This is a rather simplistic design, intended to show that with a minimum effort a decent level
+of security can be reached, and it is a first implementation showing how John can compartmentalize
+his digital life, as described in the Qubes documentation. Once the templates are are set up with
+the necessary software like LibreOffice and
+Split GPG is installed, setting up this structure takes only a few minutes, but it is much more
+secure than, for instance, a Windows 10 installation based on the available hardening studies,
+which are quite useless for a practical environment, especially for a user like John.
+
 
 ## Conclusion
 

From cbd8cde8f1925060c04c418fa0b47332c6b665bc Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sat, 4 May 2024 02:45:29 +0000
Subject: [PATCH 132/332] Fix minor typos

---
 .../app-menu-shortcut-troubleshooting.md           | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/user/troubleshooting/app-menu-shortcut-troubleshooting.md b/user/troubleshooting/app-menu-shortcut-troubleshooting.md
index a64a5d00..4b918736 100644
--- a/user/troubleshooting/app-menu-shortcut-troubleshooting.md
+++ b/user/troubleshooting/app-menu-shortcut-troubleshooting.md
@@ -16,11 +16,11 @@ Clicking on such shortcut runs the assigned application in its app qube.
 
 ![dom0-menu.png"](/attachment/doc/r4.0-dom0-menu.png)
 
-To make applications newly installed via the OS's package manager show up in the menu, use the `qvm-sync-appmenus` command (Linux VMs do this automatically):
+To make applications newly installed via the OS's package manager show up in the menu, use the `qvm-sync-appmenus` command (Linux qubes do this automatically):
 
 `qvm-sync-appmenus vmname`
 
-After that, select the *Add more shortcuts* entry in the VM's submenu to customize which applications are shown:
+After that, select the *Add more shortcuts* entry in the qube's submenu to customize which applications are shown:
 
 ![dom0-appmenu-select.png"](/attachment/doc/r4.0-dom0-appmenu-select.png)
 
@@ -75,7 +75,7 @@ If you only want to create a shortcut for a single app qube, you can create a cu
    </Menu>
    ~~~
 
-What about applications in DispVMs?
+What about applications in disposables?
 -----------------------------------
 
 [See here](/doc/disposable-customization/).
@@ -102,9 +102,9 @@ Behind the scenes
 -----------------
 
 `qvm-sync-appmenus` works by invoking the *GetAppMenus* [Qubes service](/doc/qrexec/) in the target domain.
-This service enumerates applications installed in that VM and sends formatted info back to the dom0 script (`/usr/libexec/qubes-appmenus/qubes-receive-appmenus`) which creates `.desktop` files in the app qube/template directory of dom0.
+This service enumerates applications installed in that qube and sends formatted info back to the dom0 script (`/usr/libexec/qubes-appmenus/qubes-receive-appmenus`) which creates `.desktop` files in the app qube/template directory of dom0.
 
-For Linux VMs the service script is in `/etc/qubes-rpc/qubes.GetAppMenus`.
+For Linux qubes the service script is in `/etc/qubes-rpc/qubes.GetAppMenus`.
 In Windows it's a PowerShell script located in `c:\Program Files\Invisible Things Lab\Qubes OS Windows Tools\qubes-rpc-services\get-appmenus.ps1` by default.
 
 The list of installed applications for each app qube is stored in dom0's `~/.local/share/qubes-appmenus/<vmname>/apps.templates`.
@@ -116,6 +116,6 @@ Examples: `qvm-run -q -a --service -- %VMNAME% qubes.StartApp+7-Zip-7-Zip_File_M
 
 Note that you can create a shortcut that points to a `.desktop` file in your app qube with e.g. `qvm-run -q -a --service -- personal qubes.StartApp+firefox`.
 
-While this works well for standard applications, creating a menu entry for Windows applications running under *wine* may need an additional step in order to establish the necessary environment in *wine*. Installing software under *wine* will create the needed `.desktop` file in the target Linux VM in the directory `~/.local/share/applications/wine/Programs/` or a subdirectory thereof, depending on the Windows menu structure seen under *wine*. If the name of this file contains spaces, it will not be found, because the `qvm-run` command is falsely seen as terminating at this space. The solution is to remove these spaces by renaming the `.desktop` file accordingly, e.g. by renaming `Microsoft Excel.desktop` to `Excel.desktop`. Refreshing the menu structure will then build working menu entries.
+While this works well for standard applications, creating a menu entry for Windows applications running under *wine* may need an additional step in order to establish the necessary environment in *wine*. Installing software under *wine* will create the needed `.desktop` file in the target Linux qube in the directory `~/.local/share/applications/wine/Programs/` or a subdirectory thereof, depending on the Windows menu structure seen under *wine*. If the name of this file contains spaces, it will not be found, because the `qvm-run` command is falsely seen as terminating at this space. The solution is to remove these spaces by renaming the `.desktop` file accordingly, e.g. by renaming `Microsoft Excel.desktop` to `Excel.desktop`. Refreshing the menu structure will then build working menu entries.
 
-**Note:** Applications installed under *wine* are installed in AppVMs, not in the template on which these AppVMs are based, as the file strcuture used by *wine* is stored under `~/.wine`, which is part of the persistent data of the AppVM and not inherited from its template.
+**Note:** Applications installed under *wine* are installed in AppVMs, not in the template on which these AppVMs are based, as the file structure used by *wine* is stored under `~/.wine`, which is part of the persistent data of the AppVM and not inherited from its template.

From 28b68b04068381fd8457b7fb60b7c50fe5733e3b Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Sat, 11 May 2024 03:18:21 -0700
Subject: [PATCH 133/332] Fix title

Since we don't publish release notes for patch releases, I suppose each
major or minor release's notes should apply to all releases in that
release series, in which case a patch number should not be specified in
the version number in the title.
---
 developer/releases/4_2/release-notes.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/developer/releases/4_2/release-notes.md b/developer/releases/4_2/release-notes.md
index 9e41bbf0..10fd2d1b 100644
--- a/developer/releases/4_2/release-notes.md
+++ b/developer/releases/4_2/release-notes.md
@@ -1,6 +1,6 @@
 ---
 layout: doc
-title: Qubes OS 4.2.0 release notes
+title: Qubes OS 4.2 release notes
 permalink: /doc/releases/4.2/release-notes/
 ---
 

From 6ee8ac5bb191b80e1375ec771f42de2612b089e1 Mon Sep 17 00:00:00 2001
From: Tai Lam <47955724+taivlam@users.noreply.github.com>
Date: Tue, 14 May 2024 16:56:13 +0000
Subject: [PATCH 134/332] Fix typo in split-gpg.md

Add missing period
---
 user/security-in-qubes/split-gpg.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/security-in-qubes/split-gpg.md b/user/security-in-qubes/split-gpg.md
index 8335d9e6..eeb6f92b 100644
--- a/user/security-in-qubes/split-gpg.md
+++ b/user/security-in-qubes/split-gpg.md
@@ -32,7 +32,7 @@ While this might be true (unless the attacker can find a usually-very-expensive-
 However, there is usually nothing that could stop the attacker from requesting the smart card to perform decryption of all the user documents the attacker has found or need to decrypt.
 In other words, while protecting the user's private key is an important task, we should not forget that ultimately it is the user data that are to be protected and that the smart card chip has no way of knowing the requests to decrypt documents are now coming from the attacker's script and not from the user sitting in front of the monitor.
 (Similarly the smart card doesn't make the process of digitally signing a document or a transaction in any way more secure -- the user cannot know what the chip is really signing.
-Unfortunately this problem of signing reliability is not solvable by Split GPG)
+Unfortunately this problem of signing reliability is not solvable by Split GPG.)
 
 With Qubes Split GPG this problem is drastically minimized, because each time the key is to be used the user is asked for consent (with a definable time out, 5 minutes by default), plus is always notified each time the key is used via a tray notification from the domain where GPG backend is running.
 This way it would be easy to spot unexpected requests to decrypt documents.

From bf13e5866c848618419c84f66a12bee49cdf78aa Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Wed, 15 May 2024 02:04:13 -0700
Subject: [PATCH 135/332] Remove Fedora 38 from supported template releases
 (EOL)

https://www.qubes-os.org/news/2024/02/13/fedora-39-templates-available-fedora-38-approaching-eol/
---
 user/downloading-installing-upgrading/supported-releases.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/downloading-installing-upgrading/supported-releases.md b/user/downloading-installing-upgrading/supported-releases.md
index 5bbcf993..a0f94e94 100644
--- a/user/downloading-installing-upgrading/supported-releases.md
+++ b/user/downloading-installing-upgrading/supported-releases.md
@@ -57,8 +57,8 @@ It is the responsibility of each distribution to clearly notify its users in adv
 
 | Qubes OS    | Fedora | Debian |
 | ----------- | ------ | ------ |
-| Release 4.1 | 38, 39 | 11, 12 |
-| Release 4.2 | 38, 39 | 12     |
+| Release 4.1 | 39     | 11, 12 |
+| Release 4.2 | 39     | 12     |
 
 ### Note on Debian support
 

From f071c5698ce8c52c89b377dfea8d94539e9f9971 Mon Sep 17 00:00:00 2001
From: Ben Grande <ben.grande.b@gmail.com>
Date: Wed, 15 May 2024 23:59:30 +0200
Subject: [PATCH 136/332] Document tags and features in pillar

For: https://github.com/QubesOS/qubes-mgmt-salt-base/pull/17
---
 user/advanced-topics/salt.md | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/user/advanced-topics/salt.md b/user/advanced-topics/salt.md
index 8ea97e9c..2aa2c124 100644
--- a/user/advanced-topics/salt.md
+++ b/user/advanced-topics/salt.md
@@ -555,6 +555,17 @@ Additional pillar data is available to ease targeting configurations (for exampl
 
 **Note:** This list is subject to change in future releases.
 
+### `qubes:features`
+
+Features the qube has. Only some values are included:
+
+- `service.*` - services enabled or disabled in the qube
+- `vm-config.*` - features also exposed to qubesdb
+
+### `qubes:tags`
+
+Tags the qube has.
+
 ### `qubes:type`
 
 qube type. Possible values:

From 7598bbe1569fbdf4522c13a2703199452f9a96f6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>
Date: Tue, 21 May 2024 16:36:00 +0200
Subject: [PATCH 137/332] Various formatting fixes

---
 developer/debugging/vm-interface.md               | 2 +-
 developer/services/dom0-secure-updates.md         | 4 ++--
 user/advanced-topics/managing-vm-kernels.md       | 2 +-
 user/advanced-topics/standalones-and-hvms.md      | 2 +-
 user/security-in-qubes/split-gpg.md               | 4 ++--
 user/templates/windows/qubes-windows-tools-4-0.md | 4 ++--
 user/templates/windows/qubes-windows-tools-4-1.md | 4 ++--
 7 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/developer/debugging/vm-interface.md b/developer/debugging/vm-interface.md
index 9c54619d..730c76e7 100644
--- a/developer/debugging/vm-interface.md
+++ b/developer/debugging/vm-interface.md
@@ -28,7 +28,7 @@ Qubes VM have some settings set by dom0 based on VM settings. There are multiple
   - `full` - all disks
   - `rw-only` - only `/rw` disk
   - `none` - none
-- `/qubes-timezone - name of timezone based on dom0 timezone. For example `Europe/Warsaw`
+- `/qubes-timezone` - name of timezone based on dom0 timezone. For example `Europe/Warsaw`
 - `/qubes-keyboard` (deprecated in R4.1) - keyboard layout based on dom0 layout. Its syntax is suitable for `xkbcomp` command (after expanding escape sequences like `\n` or `\t`). This is meant only as some default value, VM can ignore this option and choose its own keyboard layout (this is what keyboard setting from Qubes Manager does). This entry is created as part of gui-daemon initialization (so not available when gui-daemon disabled, or not started yet).
 - `/keyboard-layout` - keyboard layout based on GuiVM layout. Its syntax can be `layout+variant+options`, `layout+variant`, `layout++options` or simply `layout`. For example, `fr+oss`, `pl++compose:caps` or `fr`. This is meant only as some default value, VM can ignore this option and choose its own keyboard layout (this is what keyboard setting from Qubes Manager does).
 - `/qubes-debug-mode` - flag whether VM has debug mode enabled (qvm-prefs setting). One of `1`, `0`
diff --git a/developer/services/dom0-secure-updates.md b/developer/services/dom0-secure-updates.md
index cc2a4d75..ad922a88 100644
--- a/developer/services/dom0-secure-updates.md
+++ b/developer/services/dom0-secure-updates.md
@@ -33,11 +33,11 @@ Keeping Dom0 not connected to any network makes it hard, however, to provide upd
 
 The update process is initiated by [qubes-dom0-update script](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-dom0-update), running in Dom0.
 
-Updates (\*.rpm files) are checked and downloaded by UpdateVM, which by default is the same as the firewall VM, but can be configured to be any other, network-connected VM. This is done by [qubes-download-dom0-updates.sh script](https://github.com/QubesOS/qubes-core-agent-linux/blob/release2/misc/qubes-download-dom0-updates.sh) (this script is executed using qrexec by the previously mentioned qubes-dom0-update). Note that we assume that this script might get compromised and fetch maliciously compromised downloads -- this is not a problem as Dom0 verifies digital signatures on updates later. The downloaded rpm files are placed in a ~~~/var/lib/qubes/dom0-updates~~~ directory on UpdateVM filesystem (again, they might get compromised while being kept there, still this isn't a problem). This directory is passed to yum using the ~~~--installroot=~~~ option.
+Updates (`*.rpm` files) are checked and downloaded by UpdateVM, which by default is the same as the firewall VM, but can be configured to be any other, network-connected VM. This is done by [qubes-download-dom0-updates.sh script](https://github.com/QubesOS/qubes-core-agent-linux/blob/release2/misc/qubes-download-dom0-updates.sh) (this script is executed using qrexec by the previously mentioned qubes-dom0-update). Note that we assume that this script might get compromised and fetch maliciously compromised downloads -- this is not a problem as Dom0 verifies digital signatures on updates later. The downloaded rpm files are placed in a ~~~/var/lib/qubes/dom0-updates~~~ directory on UpdateVM filesystem (again, they might get compromised while being kept there, still this isn't a problem). This directory is passed to yum using the ~~~--installroot=~~~ option.
 
 Once updates are downloaded, the update script that runs in UpdateVM requests an RPM service [qubes.ReceiveUpdates](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes.ReceiveUpdates) to be executed in Dom0. This service is implemented by [qubes-receive-updates script](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-receive-updates) running in Dom0. The Dom0's qubes-dom0-update script (which originally initiated the whole update process) waits until qubes-receive-updates finished.
 
-The qubes-receive-updates script processes the untrusted input from Update VM: it first extracts the received \*.rpm files (that are sent over qrexec data connection) and then verifies digital signature on each file. The qubes-receive-updates script is a security-critical component of the Dom0 update process (as is the [qfile-dom0-unpacker.c](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qfile-dom0-unpacker.c) and the rpm utility, both used by the qubes-receive-updates for processing the untrusted input).
+The qubes-receive-updates script processes the untrusted input from Update VM: it first extracts the received `*.rpm` files (that are sent over qrexec data connection) and then verifies digital signature on each file. The qubes-receive-updates script is a security-critical component of the Dom0 update process (as is the [qfile-dom0-unpacker.c](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qfile-dom0-unpacker.c) and the rpm utility, both used by the qubes-receive-updates for processing the untrusted input).
 
 Once qubes-receive-updates finished unpacking and verifying the updates, the updates are placed in ``qubes-receive-updates`` directory in Dom0 filesystem. Those updates are now trusted. Dom0 is configured (see /etc/yum.conf in Dom0) to use this directory as a default (and only) [yum repository](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-cached.repo).
 
diff --git a/user/advanced-topics/managing-vm-kernels.md b/user/advanced-topics/managing-vm-kernels.md
index 24d2be6d..b25f78fb 100644
--- a/user/advanced-topics/managing-vm-kernels.md
+++ b/user/advanced-topics/managing-vm-kernels.md
@@ -313,7 +313,7 @@ Go to dom0 -> Qubes VM Manger -> right click on the VM -> Qube settings -> Advan
 Depends on `Virtualization` mode setting:
 
 * `Virtualization` mode `PV`: Possible, however use of `Virtualization` mode `PV` mode is discouraged for security purposes.
-  * If you require `Virtualization` mode `PV` mode, install `grub2-xen-pvh` in dom0. This can be done by running command `sudo qubes-dom0-update pvgrub2-pvh in dom0.
+  * If you require `Virtualization` mode `PV` mode, install `grub2-xen-pvh` in dom0. This can be done by running command `sudo qubes-dom0-update pvgrub2-pvh` in dom0.
 * `Virtualization` mode `PVH`: Possible.
 * `Virtualization` mode `HVM`: Possible.
 
diff --git a/user/advanced-topics/standalones-and-hvms.md b/user/advanced-topics/standalones-and-hvms.md
index f2420ffd..198dab42 100644
--- a/user/advanced-topics/standalones-and-hvms.md
+++ b/user/advanced-topics/standalones-and-hvms.md
@@ -34,7 +34,7 @@ virtualization extensions of the host CPU. These are typically contrasted with
 Paravirtualized (PV) VMs.
 
 HVMs allow you to create qubes based on any OS for which you have an
-installation ISO, so you can easily have qubes running Windows, \*BSD, or any
+installation ISO, so you can easily have qubes running Windows, `*BSD`, or any
 Linux distribution. You can also use HVMs to run "live" distros.
 
 By default, every qube runs in PVH mode (which has security advantages over
diff --git a/user/security-in-qubes/split-gpg.md b/user/security-in-qubes/split-gpg.md
index 8335d9e6..58f2c1aa 100644
--- a/user/security-in-qubes/split-gpg.md
+++ b/user/security-in-qubes/split-gpg.md
@@ -361,10 +361,10 @@ Once the master secret key is in the `work-email` VM, the attacker could simply
 
 In the alternative setup described in this section (i.e., the subkey setup), even an attacker who manages to gain access to the `work-gpg` VM will not be able to obtain the user's master secret key since it is simply not there.
 Rather, the master secret key remains in the `vault` VM, which is extremely unlikely to be compromised, since nothing is ever copied or transferred into it.
-<sup>\*</sup> The attacker might nonetheless be able to leak the secret subkeys from the `work-gpg` VM in the manner described above, but even if this is successful, the secure master secret key can simply be used to revoke the compromised subkeys and to issue new subkeys in their place.
+[^a-note] The attacker might nonetheless be able to leak the secret subkeys from the `work-gpg` VM in the manner described above, but even if this is successful, the secure master secret key can simply be used to revoke the compromised subkeys and to issue new subkeys in their place.
 (This is significantly less devastating than having to create a new *master* keypair.)
 
-<sup>\*</sup>In order to gain access to the `vault` VM, the attacker would require the use of, e.g., a general Xen VM escape exploit or a [signed, compromised package which is already installed in the template](/doc/templates/#trusting-your-templates) upon which the `vault` VM is based.
+[^a-note]: In order to gain access to the `vault` VM, the attacker would require the use of, e.g., a general Xen VM escape exploit or a [signed, compromised package which is already installed in the template](/doc/templates/#trusting-your-templates) upon which the `vault` VM is based.
 
 ### Subkey Tutorials and Discussions
 
diff --git a/user/templates/windows/qubes-windows-tools-4-0.md b/user/templates/windows/qubes-windows-tools-4-0.md
index 0c4e2443..830020c7 100644
--- a/user/templates/windows/qubes-windows-tools-4-0.md
+++ b/user/templates/windows/qubes-windows-tools-4-0.md
@@ -270,7 +270,7 @@ Qubes Windows Tools (QWT for short) contain several components than can be enabl
    - Xen PV Disk Drivers: paravirtual storage drivers.
    - Xen PV Network Drivers: paravirtual network drivers.
 - Qubes Core Agent: qrexec agent and services. Needed for proper integration with Qubes.
-   - Move user profiles: user profile directory (c:\users) is moved to VM's private disk backed by private.img file in dom0 (useful mainly for HVM templates).
+   - Move user profiles: user profile directory (`c:\users`) is moved to VM's private disk backed by private.img file in dom0 (useful mainly for HVM templates).
 - Qubes GUI Agent: video driver and gui agent that enable seamless showing of Windows applications on the secure Qubes desktop.
 - Disable UAC: User Account Control may interfere with QWT and doesn't really provide any additional benefits in Qubes environment.
 
@@ -331,7 +331,7 @@ If the VM is inaccessible (doesn't respond to qrexec commands, gui is not functi
 
 Safe Mode should at least give you access to logs (see above).
 
-**Please include appropriate logs when reporting bugs/problems.** Starting from version 2.4.2 logs contain QWT version, but if you're using an earlier version be sure to mention which one. If the OS crashes (BSOD) please include the BSOD code and parameters in your bug report. The BSOD screen should be visible if you run the VM in debug mode (`qvm-start --debug vmname`). If it's not visible or the VM reboots automatically, try to start Windows in safe mode (see above) and 1) disable automatic restart on BSOD (Control Panel - System - Advanced system settings - Advanced - Startup and recovery), 2) check the system event log for BSOD events. If you can, send the `memory.dmp` dump file from c:\Windows.
+**Please include appropriate logs when reporting bugs/problems.** Starting from version 2.4.2 logs contain QWT version, but if you're using an earlier version be sure to mention which one. If the OS crashes (BSOD) please include the BSOD code and parameters in your bug report. The BSOD screen should be visible if you run the VM in debug mode (`qvm-start --debug vmname`). If it's not visible or the VM reboots automatically, try to start Windows in safe mode (see above) and 1) disable automatic restart on BSOD (Control Panel - System - Advanced system settings - Advanced - Startup and recovery), 2) check the system event log for BSOD events. If you can, send the `memory.dmp` dump file from `c:\Windows`.
 Xen logs (/var/log/xen/console/guest-*) are also useful as they contain pvdrivers diagnostic output.
 
 If a specific component is malfunctioning, you can increase its log verbosity as explained above to get more troubleshooting information. Below is a list of components:
diff --git a/user/templates/windows/qubes-windows-tools-4-1.md b/user/templates/windows/qubes-windows-tools-4-1.md
index 59b0e58f..d02f2dbf 100644
--- a/user/templates/windows/qubes-windows-tools-4-1.md
+++ b/user/templates/windows/qubes-windows-tools-4-1.md
@@ -263,7 +263,7 @@ Windows qubes can be used as disposables, like any other Linux-based qubes. On c
 		- Type `shell:startup`.
 		- An explorer window will open, which is positioned to the `Autostart` folder.
 	- Right-click and select the option "New -> Link".
-	- Select `C:\Windows\System32\CMD.exe`as executable.
+	- Select `C:\Windows\System32\CMD.exe` as executable.
 	- Name the link, e.g. as `Command Prompt`.
 	- Close the Window with `OK`.
 	- Shut down this AppVM.
@@ -273,7 +273,7 @@ Windows qubes can be used as disposables, like any other Linux-based qubes. On c
 - Still in the Advanced tab, select your Windows qube as its own `Default disposable template`. Alternatively, in dom0 execute the command `qvm-prefs <VMname> default_dispvm <VMname>`.
 - Close the Qube Manager by clicking `OK`.
 
-Now you should have a menu `Disposable: <VMname>` containing the applications that can be started in a disposable Windows VM. If you set the newly created and configured Windows VM as `Default disposable template`for any other Windows- (or Linux-) based qube, this qube can use the Windows-based dispvm like any other disposable.
+Now you should have a menu `Disposable: <VMname>` containing the applications that can be started in a disposable Windows VM. If you set the newly created and configured Windows VM as `Default disposable template` for any other Windows- (or Linux-) based qube, this qube can use the Windows-based dispvm like any other disposable.
 
 For further information on usage of disposables, see [How to use disposables](/doc/how-to-use-disposables/).
 

From b8f24e762e998858f1ff1a9693933479f779ff97 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>
Date: Tue, 21 May 2024 16:36:12 +0200
Subject: [PATCH 138/332] Remove obsolete EFI config (xen.cfg) section

Grub is used for both for a long time already
---
 .../how-to-install-software-in-dom0.md         | 18 +-----------------
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/user/advanced-topics/how-to-install-software-in-dom0.md b/user/advanced-topics/how-to-install-software-in-dom0.md
index ddd7f869..b7040a6c 100644
--- a/user/advanced-topics/how-to-install-software-in-dom0.md
+++ b/user/advanced-topics/how-to-install-software-in-dom0.md
@@ -209,23 +209,7 @@ to do a lot of work yourself](https://groups.google.com/d/msg/qubes-users/m8sWoy
 
 This section describes changing the default kernel in dom0. It is sometimes
 needed if you have upgraded to a newer kernel and are having problems booting,
-for example. The procedure varies depending on if you are booting with UEFI or
-grub. On the next kernel update, the default will revert to the newest.
-
-### EFI
-
-~~~
-sudo nano /boot/efi/EFI/qubes/xen.cfg
-~~~
-
-In the `[global]` section at the top, change the `default=` line to match one
-of the three boot entries listed below. For example:
-
-~~~
-default=4.19.67-1.pvops.qubes.x86_64
-~~~
-
-### Grub2
+for example. On the next kernel update, the default will revert to the newest.
 
 ~~~
 sudo nano /etc/default/grub

From c600b5495d472664bfaf0064080c3189e3c6916b Mon Sep 17 00:00:00 2001
From: Pierre Alain <pierre.alain@tuta.io>
Date: Tue, 28 May 2024 16:44:52 +0200
Subject: [PATCH 139/332] initramfs is optional (qubes-core-admin#586)

---
 user/advanced-topics/managing-vm-kernels.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/advanced-topics/managing-vm-kernels.md b/user/advanced-topics/managing-vm-kernels.md
index b25f78fb..7303a158 100644
--- a/user/advanced-topics/managing-vm-kernels.md
+++ b/user/advanced-topics/managing-vm-kernels.md
@@ -224,7 +224,7 @@ Kernel for a VM is stored in `/var/lib/qubes/vm-kernels/KERNEL_VERSION` director
 * `modules.img` - ext4 filesystem image containing Linux kernel modules (to be mounted at `/lib/modules`); additionally it should contain a copy of `vmlinuz` and `initramfs` in its root directory (for loading by qemu inside stubdomain)
 * `default-kernelopts-common.txt` - default kernel options, in addition to those specified with `kernelopts` qube property (can be disabled with `no-default-kernelopts` feature)
 
-All the files besides `vmlinuz` and `initramfs` are optional in Qubes R4.0 or newer.
+All the files besides `vmlinuz` are optional in Qubes R4.2 or newer.
 
 ## Using kernel installed in the VM
 

From 36c283d209809a3122f2e65df75bcf217dc5dc22 Mon Sep 17 00:00:00 2001
From: deeplow <47065258+deeplow@users.noreply.github.com>
Date: Thu, 30 May 2024 17:09:12 -0400
Subject: [PATCH 140/332] vm-interface.md: add missing entry
 /qubes-base-template

---
 developer/debugging/vm-interface.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/developer/debugging/vm-interface.md b/developer/debugging/vm-interface.md
index 730c76e7..dc33827c 100644
--- a/developer/debugging/vm-interface.md
+++ b/developer/debugging/vm-interface.md
@@ -22,6 +22,7 @@ Qubes VM have some settings set by dom0 based on VM settings. There are multiple
 
 ### Keys exposed by dom0 to VM
 
+- `/qubes-base-template` - base template
 - `/qubes-vm-type` - VM type, the same as `type` field in `qvm-prefs`. One of `AppVM`, `ProxyVM`, `NetVM`, `TemplateVM`, `HVM`, `TemplateHVM`
 - `/qubes-vm-updatable` - flag whether VM is updatable (whether changes in root.img will survive VM restart). One of `True`, `False`
 - `/qubes-vm-persistence` - what data do persist between VM restarts:
@@ -33,7 +34,7 @@ Qubes VM have some settings set by dom0 based on VM settings. There are multiple
 - `/keyboard-layout` - keyboard layout based on GuiVM layout. Its syntax can be `layout+variant+options`, `layout+variant`, `layout++options` or simply `layout`. For example, `fr+oss`, `pl++compose:caps` or `fr`. This is meant only as some default value, VM can ignore this option and choose its own keyboard layout (this is what keyboard setting from Qubes Manager does).
 - `/qubes-debug-mode` - flag whether VM has debug mode enabled (qvm-prefs setting). One of `1`, `0`
 - `/qubes-service/SERVICE_NAME` - subtree for VM services controlled from dom0 (using the `qvm-service` command or Qubes Manager). One of `1`, `0`. Note that not every service will be listed here, if entry is missing, it means "use VM default". A list of currently supported services is in the `qvm-service` man page.
-- `/qubes-netmask` - network mask (only when VM has netvm set); currently hardcoded "255.255.255.0"
+- `/qubes-netm ask` - network mask (only when VM has netvm set); currently hardcoded "255.255.255.0"
 - `/qubes-ip` - IP address for this VM (only when VM has netvm set)
 - `/qubes-gateway` - default gateway IP (only when VM has netvm set); VM should add host route to this address directly via eth0 (or whatever default interface name is)
 - `/qubes-primary-dns` - primary DNS address (only when VM has netvm set)

From be4bbda177b69d1187891087594eed59f4ae37eb Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sat, 1 Jun 2024 13:08:36 +0200
Subject: [PATCH 141/332] add newline for better rst conversion

---
 introduction/screenshots.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/introduction/screenshots.md b/introduction/screenshots.md
index 1f4b04d0..36aea7f3 100644
--- a/introduction/screenshots.md
+++ b/introduction/screenshots.md
@@ -61,6 +61,7 @@ Qubes is all about seamless integration from the user’s point of view. Here yo
 [![r4.0-manager-and-sysnet-network-prompt.png](/attachment/doc/r4.0-manager-and-sysnet-network-prompt.png)](/attachment/doc/r4.0-manager-and-sysnet-network-prompt.png)
 
 All the networking runs in a special, unprivileged NetVM. (Notice the red frame around the Network Manager dialog box on the screen above.) This means that in the event that your network card driver, Wi-Fi stack, or DHCP client is compromised, the integrity of the rest of the system will not be affected! This feature requires Intel VT-d or AMD IOMMU hardware (e.g., Core i5/i7 systems)
+
 * * * * *
 
 [![r4.0-software-update.png](/attachment/doc/r4.0-software-update.png)](/attachment/doc/r4.0-software-update.png)

From d04ee197c95d184ea462d9aa6b13a1acfd93e527 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sat, 1 Jun 2024 14:32:45 +0200
Subject: [PATCH 142/332] add newlines for better rst conversion

---
 introduction/issue-tracking.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/introduction/issue-tracking.md b/introduction/issue-tracking.md
index 3296210e..13ebb449 100644
--- a/introduction/issue-tracking.md
+++ b/introduction/issue-tracking.md
@@ -95,10 +95,12 @@ Meta-issues must abide by the following rules:
 
 - Only members of the core team may create meta-issues (or convert existing issues into meta-issues).
 
+
   Rationale: The purpose of meta-issues is to track the development of certain features that fit into the overall goals of the Qubes OS Project, which requires making informed project-management decisions with the approval of the project lead.
 
 - Meta-issues must be [locked](https://docs.github.com/en/communities/moderating-comments-and-conversations/locking-conversations).
 
+
   Rationale: One of the historical problems we've experienced with meta-issues (and one of the reasons they were discouraged for a long time) is that each meta-issue tends to turn into a discussion thread that becomes hopelessly long to the point where the person who is supposed to work on it has no idea what is supposed to be done or where to start, and it eventually just gets closed. Locking is intended to prevent that from happening again.
 
 - Meta-issues must have informative descriptions, not just lists of issues. In particular, each meta-issue should explain its goal, what is in scope, and what the relevant categories and priorities are.

From 0f1268e25e12d6d7f613f380daddaf9cd856c039 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sat, 1 Jun 2024 14:33:23 +0200
Subject: [PATCH 143/332] Remove space for better rst conversion

---
 introduction/faq.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/introduction/faq.md b/introduction/faq.md
index 2258ee1b..dd34b511 100644
--- a/introduction/faq.md
+++ b/introduction/faq.md
@@ -144,7 +144,7 @@ Briefly, here are some of the main pros and cons of this approach relative to Qu
   (For example, you might find it natural to lock your secure laptop in a safe when you take your unsecure laptop out with you.)
 
 <div class="focus">
-    <i class="fa fa-times"></i> <strong>Cons</strong>
+  <i class="fa fa-times"></i> <strong>Cons</strong>
 </div>
 
 - Physical separation can be cumbersome and expensive, since we may have to obtain and set up a separate physical machine for each security level we need.

From 20972f27981f7b1a7c262f541d2bfa52fa52e0b6 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sat, 1 Jun 2024 16:03:52 +0200
Subject: [PATCH 144/332] add newline for better rst conversion

---
 introduction/support.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/introduction/support.md b/introduction/support.md
index b12bb55f..a21b73cf 100644
--- a/introduction/support.md
+++ b/introduction/support.md
@@ -515,6 +515,7 @@ news.
 ## Chat
 
 If you'd like to chat, join us on
+
 - the `#qubes` channel on `irc.libera.chat` or
 - the `#qubes:invisiblethingslab.com` matrix channel.
 

From 6cf2fd5ea1ef85a439036137218a9a62c82c1f54 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sat, 1 Jun 2024 16:38:24 +0200
Subject: [PATCH 145/332] add new line for better rst conv

---
 .../backup-emergency-restore-v3.md              | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/user/how-to-guides/backup-emergency-restore-v3.md b/user/how-to-guides/backup-emergency-restore-v3.md
index 2b54406f..1b47ee06 100644
--- a/user/how-to-guides/backup-emergency-restore-v3.md
+++ b/user/how-to-guides/backup-emergency-restore-v3.md
@@ -55,6 +55,7 @@ any GNU/Linux system with the following procedure.
     **Note:** The hash values should match. If they do not match, then the
     backup file may have been tampered with, or there may have been a storage
     error.
+    
 
     **Note:** If your backup was hashed with a message digest algorithm other
     than `sha512`, you must substitute the correct message digest command. This
@@ -64,7 +65,7 @@ any GNU/Linux system with the following procedure.
     supported message digest algorithms can be found with `openssl
     list-message-digest-algorithms`.
 
- 4. Read the `backup-header`. You'll need some of this information later. The
+ 5. Read the `backup-header`. You'll need some of this information later. The
     file will look similar to this:
 
         [user@restore ~]$ cat backup-header
@@ -78,7 +79,7 @@ any GNU/Linux system with the following procedure.
     **Note:** If you see `version=2` here, go to [Emergency Backup Recovery -
     format version 2](/doc/backup-emergency-restore-v2/) instead.
 
- 5. Verify the integrity of the `private.img` file which houses your data.
+ 6. Verify the integrity of the `private.img` file which houses your data.
 
         [user@restore ~]$ cd vm1/
         [user@restore vm1]$ openssl dgst -sha512 -hmac "$backup_pass" private.img.000
@@ -90,13 +91,14 @@ any GNU/Linux system with the following procedure.
     backup file may have been tampered with, or there may have been a storage
     error.
 
+
     **Note:** If your backup was hashed with a message digest algorithm other
     than `sha512`, you must substitute the correct message digest command. This
     information is contained in the `backup-header` file (see step 4). A
     complete list of supported message digest algorithms can be found with
     `openssl list-message-digest-algorithms`.
 
- 6. Decrypt the `private.img` file.
+ 7. Decrypt the `private.img` file.
 
         [user@restore vm1]$ find -name 'private.img.*[0-9]' | sort -V | xargs cat | openssl enc -d -md MD5 -pass pass:"$backup_pass" -aes-256-cbc -out private.img.dec
 
@@ -106,7 +108,7 @@ any GNU/Linux system with the following procedure.
     complete list of supported cipher algorithms can be found with `openssl
     list-cipher-algorithms`.
 
- 7. Decompress the decrypted `private.img` file.
+ 8. Decompress the decrypted `private.img` file.
 
         [user@restore vm1]$ zforce private.img.dec
         private.img.dec -- replaced with private.img.dec.gz
@@ -120,20 +122,21 @@ any GNU/Linux system with the following procedure.
         [user@restore vm1]$ mv private.img.dec private.img.dec.bz2
         [user@restore vm1]$ bunzip2 private.img.dec.bz2
 
- 8. Untar the decrypted and decompressed `private.img` file.
+ 9. Untar the decrypted and decompressed `private.img` file.
 
         [user@restore vm1]$ tar -xvf private.img.dec
         vm1/private.img
 
- 9. Mount the private.img file and access your data.
+ 10. Mount the private.img file and access your data.
 
         [user@restore vm1]$ sudo mkdir /mnt/img
         [user@restore vm1]$ sudo mount -o loop vm1/private.img /mnt/img/
         [user@restore vm1]$ cat /mnt/img/home/user/your_data.txt
         This data has been successfully recovered!
 
-10. Success! If you wish to recover data from more than one VM in your backup,
+11. Success! If you wish to recover data from more than one VM in your backup,
     simply repeat steps 5--9 for each additional VM.
+    
 
     **Note:** You may wish to store a copy of these instructions with your
     Qubes backups in the event that you fail to recall the above procedure

From 3ef2cd78aefafd23670eb81b9ea8c3f05910ac7e Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sat, 1 Jun 2024 17:36:57 +0200
Subject: [PATCH 146/332] new lines rst conv

---
 user/how-to-guides/backup-emergency-restore-v3.md | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/user/how-to-guides/backup-emergency-restore-v3.md b/user/how-to-guides/backup-emergency-restore-v3.md
index 1b47ee06..7a460d4e 100644
--- a/user/how-to-guides/backup-emergency-restore-v3.md
+++ b/user/how-to-guides/backup-emergency-restore-v3.md
@@ -57,6 +57,7 @@ any GNU/Linux system with the following procedure.
     error.
     
 
+
     **Note:** If your backup was hashed with a message digest algorithm other
     than `sha512`, you must substitute the correct message digest command. This
     information is contained in the `backup-header` file (see step 4), however
@@ -92,6 +93,7 @@ any GNU/Linux system with the following procedure.
     error.
 
 
+
     **Note:** If your backup was hashed with a message digest algorithm other
     than `sha512`, you must substitute the correct message digest command. This
     information is contained in the `backup-header` file (see step 4). A
@@ -136,7 +138,8 @@ any GNU/Linux system with the following procedure.
 
 11. Success! If you wish to recover data from more than one VM in your backup,
     simply repeat steps 5--9 for each additional VM.
-    
+
+
 
     **Note:** You may wish to store a copy of these instructions with your
     Qubes backups in the event that you fail to recall the above procedure

From 3dcfa93aa71068ca4ab1c4c520853a3b663d6b95 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sat, 1 Jun 2024 17:37:25 +0200
Subject: [PATCH 147/332] new line rst conv

---
 user/how-to-guides/how-to-use-devices.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/user/how-to-guides/how-to-use-devices.md b/user/how-to-guides/how-to-use-devices.md
index 3b65f1e6..c8d2c0eb 100644
--- a/user/how-to-guides/how-to-use-devices.md
+++ b/user/how-to-guides/how-to-use-devices.md
@@ -26,6 +26,7 @@ In Qubes 3.X, the Qubes VM Manager dealt with attachment as well.
 This functionality was moved to the Qubes Device Widget, the tool tray icon with a yellow square located in the top right of your screen by default.
 
 There are currently four categories of devices Qubes understands:
+
  - Microphones
  - Block devices
  - USB devices

From 6b2ad28033e09934a6227fa488d04e8bf995ff61 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sat, 1 Jun 2024 17:37:40 +0200
Subject: [PATCH 148/332] newline rst conv

---
 user/how-to-guides/how-to-use-disposables.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/user/how-to-guides/how-to-use-disposables.md b/user/how-to-guides/how-to-use-disposables.md
index 7999d8b7..e4aaa9a9 100644
--- a/user/how-to-guides/how-to-use-disposables.md
+++ b/user/how-to-guides/how-to-use-disposables.md
@@ -149,6 +149,7 @@ In dom0, add the following line at the beginning of the file `/etc/qubes-rpc/pol
 ~~~
 
 This line means:
+
 - FROM: Any qube
 - TO: A disposable based on `<ONLINE_DISPOSABLE_TEMPLATE>`
 - WHAT: Allow sending an "Open URL" request

From 54c3246c1d065fbe58f51aff7f169eec83fcca7b Mon Sep 17 00:00:00 2001
From: "B. Burt" <162539390+beeburrt@users.noreply.github.com>
Date: Thu, 6 Jun 2024 00:43:28 -0600
Subject: [PATCH 149/332] Update installation-guide.md

No testes
---
 user/downloading-installing-upgrading/installation-guide.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/downloading-installing-upgrading/installation-guide.md b/user/downloading-installing-upgrading/installation-guide.md
index acd5a9ec..c38cbc35 100644
--- a/user/downloading-installing-upgrading/installation-guide.md
+++ b/user/downloading-installing-upgrading/installation-guide.md
@@ -125,7 +125,7 @@ Select the option to test this media and install Qubes OS.
 
 <div class="alert alert-info" role="alert">
   <i class="fa fa-info-circle"></i>
-  <b>Note:</b> If the latest stable release is not compatible with your hardware, you may wish to consider installing using the latest kernel. Be aware that this has not been as well testes as the standard kernel.
+  <b>Note:</b> If the latest stable release is not compatible with your hardware, you may wish to consider installing using the latest kernel. Be aware that this has not been as well tested as the standard kernel.
 </div>
 
 If the boot screen does not appear, there are several options to troubleshoot. First, try rebooting your computer. If it still loads your currently installed operating system or does not detect your installation medium, make sure the boot order is set up appropriately. The process to change the boot order varies depending on the currently installed system and the motherboard manufacturer. If **Windows 10** is installed on your machine, you may need to follow specific instructions to change the boot order. This may require an [advanced reboot](https://support.microsoft.com/en-us/help/4026206/windows-10-find-safe-mode-and-other-startup-settings).

From 5050b8d1aa2d822fdbbd0efc481a8c8d38e961e7 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sat, 8 Jun 2024 20:03:50 +0200
Subject: [PATCH 150/332] better comv for rst prep

---
 user/how-to-guides/how-to-reinstall-a-template.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/user/how-to-guides/how-to-reinstall-a-template.md b/user/how-to-guides/how-to-reinstall-a-template.md
index cc7cce67..baf99ce7 100644
--- a/user/how-to-guides/how-to-reinstall-a-template.md
+++ b/user/how-to-guides/how-to-reinstall-a-template.md
@@ -48,11 +48,13 @@ If you want to reinstall more than one template, repeat these instructions for e
 
 1. Clone the existing target template.
 
+
    This can be a good idea if you've customized the existing template and want to keep your customizations.
    On the other hand, if you suspect that this template is broken, misconfigured, or compromised, be certain you do not start any VMs using it in the below procedure.
 
 2. Temporarily change all VMs based on the target template to the new clone template, or remove them.
 
+
    This can be a good idea if you have user data in these VMs that you want to keep.
    On the other hand, if you suspect that these VMs (or the templates on which they are based) are broken, misconfigured, or compromised, you may want to remove them instead.
    You can do this in Qubes Manager by right-clicking on the VM and clicking **Remove VM**, or you can use the command `qvm-remove <vm-name>` in dom0.

From 9cb521989d2b977c070c80713b8874ee3040d21c Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sun, 9 Jun 2024 15:50:22 +0000
Subject: [PATCH 151/332] Minor change to how-to-use-disposables page.

---
 user/how-to-guides/how-to-use-disposables.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/user/how-to-guides/how-to-use-disposables.md b/user/how-to-guides/how-to-use-disposables.md
index d13c467b..2a0f7eaa 100644
--- a/user/how-to-guides/how-to-use-disposables.md
+++ b/user/how-to-guides/how-to-use-disposables.md
@@ -26,23 +26,23 @@ This diagram provides a general example of how disposables can be used to safely
 
 There is a difference between [named disposable qubes](/doc/glossary/#named-disposable) and [disposable templates](/doc/glossary/#disposable-template).
 
-In a default QubesOS Installation, you would probably use the 'whonix-ws-16-dvm' disposable template to, for example, browse the Tor network with an disposable qube. Every time you start an application using this disposable template, a new disposable qube - named `dispX` (where X is a random number) starts. If you close the application window, the `dispX` qube shuts down and vanished from your system. That is how disposable templates are used.
+In a default QubesOS Installation, you would probably use the 'whonix-ws-16-dvm' disposable template to, for example, browse the Tor network with an disposable qube. Every time you start an application using this disposable template, a new disposable qube - named `dispX` (where X is a random number) starts. If you close the application window, the `dispX` qube shuts down and vanishes from your system. That is how disposable templates are used.
 
-In named disposables every application starts in the same qube, the qube itself has a fixed name and you need to manually shutdown the qube. Except from the non-persistance, they feel like usual app qubes. Named disposables are built upon disposable templates.
+Named disposables are also built upon disposable templates, but they have a fixed name. The named disposable seems to behave like an ordinary app qube - every application you open will start in the same qube, and you need to manually shutdown the qube. But when you shutdown *any changes you made in the named disposable will be lost*. Except for this non-persistance, they feel like usual app qubes.
 
 ### How to create disposable templates
 
 First, you need to create an app qube. You can run it normally, set up any necessary settings (like browser settings) you wish to be applied to every disposable qube ran from this template. Next, go to 'Qube Settings' of the app qube, set it as a _Disposable template_ in the _Advanced_ section and apply the change. 
 
-In Qubes 4.1, from now on, the entry in the Application menu is not named 'Qube' anymore, but split into 'Disposable' and 'Template (disp)'. The settings for the disposable can be changed under **'Application Menu -> Template (disp) -> Template: Qubes Settings**
+In Qubes 4.1, the entry in the Application menu is split into 'Disposable' and 'Template (disp)'. The settings for the disposable can be changed under **'Application Menu -> Template (disp) -> Template: Qubes Settings**
 
-In Qubes 4.2, the qube will now appear in the menu as a disposable template (in the Apps section), from which you can launch new disposable qubes. To change the settings of the template itself or run programs in it, use the menu position for this qube located in the Templates section.
+In Qubes 4.2, the qube will now appear in the menu as a disposable template (in the Apps section), from which you can launch new disposable qubes. To change the settings of the template itself or run programs in it, use the menu item for the disposable template located in the Templates section.
 
 ### How to create named disposables
 
 In Qubes 4.1: named disposables can be created under **Application Menu -> Create Qubes VM**, set the qube type  to be _DisposableVM_.
 
-In Qubes 4.2: named disposables can be created by **Application Menu -> Settings -> Qubes Settings -> Create New Qube**. Set the qube type to _Named disposable_
+In Qubes 4.2: named disposables can be created by **Application Menu -> Settings -> Qubes Settings -> Create New Qube**. Set the qube type to Named disposable_
 
 ## Security
 

From 0584c50257f54a11070c8404c26343ef5498c379 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Tue, 11 Jun 2024 18:41:20 -0700
Subject: [PATCH 152/332] Add Fedora 40 support for Qubes 4.2

QubesOS/qubes-issues#8915
---
 user/downloading-installing-upgrading/supported-releases.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/downloading-installing-upgrading/supported-releases.md b/user/downloading-installing-upgrading/supported-releases.md
index a0f94e94..8711facc 100644
--- a/user/downloading-installing-upgrading/supported-releases.md
+++ b/user/downloading-installing-upgrading/supported-releases.md
@@ -58,7 +58,7 @@ It is the responsibility of each distribution to clearly notify its users in adv
 | Qubes OS    | Fedora | Debian |
 | ----------- | ------ | ------ |
 | Release 4.1 | 39     | 11, 12 |
-| Release 4.2 | 39     | 12     |
+| Release 4.2 | 39, 40 | 12     |
 
 ### Note on Debian support
 

From 112e9996eb9f1350f4cc38d05dba83014b5d6ca7 Mon Sep 17 00:00:00 2001
From: deeplow <47065258+deeplow@users.noreply.github.com>
Date: Wed, 12 Jun 2024 05:19:49 -0400
Subject: [PATCH 153/332] qubes-builderv1 still support 4.2 builds

---
 developer/building/qubes-builder.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/developer/building/qubes-builder.md b/developer/building/qubes-builder.md
index 31755705..58573dea 100644
--- a/developer/building/qubes-builder.md
+++ b/developer/building/qubes-builder.md
@@ -13,7 +13,7 @@ title: Qubes builder
 <div class="alert alert-warning" role="alert">
   <i class="fa fa-exclamation-circle"></i>
   <b>Note:</b> These instructions concern the older Qubes builder (v1). It supports
-  only building Qubes 4.1 or earlier.<br>The build process has been completely rewritten in <a href="https://github.com/QubesOS/qubes-builderv2/">qubes-builder v2</a>. This can be used for building Qubes R4.1 and later, and all related components.
+  only building Qubes 4.2 or earlier.<br>The build process has been completely rewritten in <a href="https://github.com/QubesOS/qubes-builderv2/">qubes-builder v2</a>. This can be used for building Qubes R4.2 and later, and all related components.
 </div>
 
 **Note: See [ISO building instructions](/doc/qubes-iso-building/) for a streamlined overview on how to use the build system.**

From ee6a768d329edb1af52b66ef2c94986a13ffe825 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Wed, 12 Jun 2024 18:18:45 +0200
Subject: [PATCH 154/332] better conv for rst

---
 user/templates/windows/windows-qubes-4-1.md | 57 +++++++++++++--------
 1 file changed, 37 insertions(+), 20 deletions(-)

diff --git a/user/templates/windows/windows-qubes-4-1.md b/user/templates/windows/windows-qubes-4-1.md
index 4d38a4bb..f4f6f3c9 100644
--- a/user/templates/windows/windows-qubes-4-1.md
+++ b/user/templates/windows/windows-qubes-4-1.md
@@ -46,6 +46,7 @@ For better integration, a set of drivers and services, called Qubes Windows Tool
 However, if you are an expert or want to do it manually you may continue below.
 
 **Notes:**
+
 - The instructions may work on other versions than Windows 7, 8.1, 10 and 11 x64 but haven't been tested.
 - Qubes Windows Tools (QWT) only supports Windows 7, 8.1, 10 and 11 x64. For installation, see [Qubes Windows Tools](/doc/templates/windows/qubes-windows-tools-4-1).
 
@@ -63,7 +64,9 @@ Create a VM named WindowsNew in [HVM](/doc/hvm/) mode (Xen's current PVH limitat
 
 - Using Qube Manager
 
+
    In order to create the new qube, select the command Qube -> New Qube in the Qube Manager::
+  
      - Name: `WindowsNew`, Color: `orange` (for a standalone qubes, `black` for a template)
      - Type: `StandaloneVM (fully persistent)` or `TemplateVM (template home, persistent root)`
      - Template: `(none)`
@@ -86,21 +89,26 @@ Create a VM named WindowsNew in [HVM](/doc/hvm/) mode (Xen's current PVH limitat
 - Using CLI in a dom0 terminal
  
    - This can also be done via the following CLI commands in dom0, for a standalone qube:
-      ~~~
-      qvm-create --class StandaloneVM --label orange --property virt_mode=hvm WindowsNew
-      ~~~
-     and for a template:
-      ~~~
-      qvm-create --class TemplateVM --label black --property virt_mode=hvm WindowsNew
-      ~~~
+
+    ~~~
+    qvm-create --class StandaloneVM --label orange --property virt_mode=hvm WindowsNew
+    ~~~
+
+    and for a template:
+
+    ~~~
+    qvm-create --class TemplateVM --label black --property virt_mode=hvm WindowsNew
+    ~~~
+   
    - After creation, set the following parameters via CLI in a dom0 terminal:
-      ~~~
-      qvm-volume extend WindowsNew:root 60g
-      qvm-prefs WindowsNew memory 4096
-      qvm-prefs WindowsNew maxmem 4096
-      qvm-prefs WindowsNew kernel ''
-      qvm-prefs WindowsNew qrexec_timeout 7200
-      ~~~
+
+    ~~~
+    qvm-volume extend WindowsNew:root 60g
+    qvm-prefs WindowsNew memory 4096
+    qvm-prefs WindowsNew maxmem 4096
+    qvm-prefs WindowsNew kernel ''
+    qvm-prefs WindowsNew qrexec_timeout 7200
+    ~~~
 
 These parameters are set for the following reasons:
   
@@ -109,13 +117,14 @@ These parameters are set for the following reasons:
 - Setting memory to 4096MB may work in most cases, but using 6144MB (or even 8192MB) may reduce the likelihood of crashes during installation, especially for Windows 10 or 11. This is important as Windows qubes have to be created without memory balancing, as requested by the parameter settings described above.
 
 - The Windows' installer requires a significant amount of memory or else the VM will crash with such errors:
-  ~~~
-  /var/log/xen/console/hypervisor.log:
+    ~~~
+    /var/log/xen/console/hypervisor.log:
 
-  p2m_pod_demand_populate: Dom120 out of PoD memory! (tot=102411 ents=921600 dom120)
-  (XEN) domain_crash called from p2m-pod.c:1218
-  (XEN) Domain 120 (vcpu#0) crashed on cpu#3:
-  ~~~
+    p2m_pod_demand_populate: Dom120 out of PoD memory! (tot=102411 ents=921600 dom120)
+    (XEN) domain_crash called from p2m-pod.c:1218
+    (XEN) Domain 120 (vcpu#0) crashed on cpu#3:
+    ~~~
+    
   So, increase the VM's memory to 4096MB (memory = maxmem because we don't use memory balancing), or 6144MB / 8192MB, as recommended above.
      
 - Disable direct boot so that the VM will go through the standard cdrom/HDD boot sequence. This is done by setting the qube's kernel to an empty value.
@@ -135,6 +144,7 @@ These parameters are set for the following reasons:
      - Click "OK" to boot into the windows installer.
 
    This can also be done via the following CLI command in dom0 (assuming that the Windows installer ISO is stored in the directory `/home/user/` in the AppVM `untrusted`):
+
     ~~~
     qvm-start --cdrom=untrusted:/home/user/windows_install.iso WindowsNew
     ~~~
@@ -175,8 +185,10 @@ These parameters are set for the following reasons:
 
 - On systems shipped with a Windows license, the product key may be read from flash via root in dom0:
 
+
     `strings < /sys/firmware/acpi/tables/MSDM`
 
+
     Alternatively, you can also try a Windows 7 license key (as of 2018/11 they are still accepted for a free upgrade to Windows 10).
     
  - The VM will shutdown after the installer completes the extraction of Windows installation files. It's a good idea to clone the VM now (eg. `qvm-clone WindowsNew WindowsNewbkp1`). Then, (re)start the VM via the Qubes Manager or with `qvm-start WindowsNew` from a dom0 terminal (without the `--cdrom` parameter!).
@@ -186,9 +198,11 @@ These parameters are set for the following reasons:
 **After Windows installation**
 
   - From the Windows command line, disable hibernation in order to avoid incomplete Windows shutdown, which could lead to corruption of the VM's disk. 
+
      ~~~
      powercfg -H off
      ~~~
+
     Also, recent versions of Windows won’t show the CD-ROM drive after starting the qube with `qvm-start vm --cdrom ...` (or using the GUI). The solution is to disable hibernation in Windows with this command. (That command is included in QWT’s setup but it’s necessary to run it manually in order to be able to open QWT’s setup ISO/CD-ROM in Windows).
 
   - In case you switch from `sys-firewall` to `sys-whonix`, you'll need a static IP network configuration, DHCP won't work for `sys-whonix`. Sometimes this may also happen if you keep using `sys-firewall`. In both cases, proceed as follows:
@@ -202,6 +216,7 @@ These parameters are set for the following reasons:
 
   - Given the higher than usual memory requirements of Windows, you may get a `Not enough memory to start domain 'WindowsNew'` error. In that case try to shutdown unneeded VMs to free memory before starting the Windows VM.
 
+
     At this point you may open a tab in dom0 for debugging, in case something goes amiss:
 
      ~~~
@@ -234,6 +249,7 @@ For additional information on configuring a Windows qube, see the [Customizing W
 As described above Windows 7, 8.1, 10 and 11 can be installed as TemplateVM. To have the user data stored in AppVMs depending on this template, the option `Move User Profiles` has to be selected on installation of Qubes Windows Tools. For Windows 7, before installing QWT, the private disk `D:` has to be renamed to `Q:`, see the QWT installation documentation in [Qubes Windows Tools](/doc/templates/windows/qubes-windows-tools-4-1).
 
 AppVMs based on these templates can be created the normal way by using the Qube Manager or by specifying
+
 ~~~
 qvm-create --class=AppVM --template=<VMname> 
 ~~~
@@ -243,6 +259,7 @@ On starting the AppVM, sometimes a message is displayed that the Xen PV Network
 **Caution:** These AppVMs must not be started while the corresponding TemplateVM is running, because they share the TemplateVM's license data. Even if this could work sometimes, it would be a violation of the license terms.
 
 Furthermore, if manual IP setup was used for the template, the IP address selected for the template will also be used for the AppVM, as it inherits this address from the template. Qubes, however, will have assigned a different address to the AppVM, which will have to changed to that of the template (e.g. 10.137.0.x) so that the AppVM can access the network, vis the CLI command in a dom0 terminal:
+
 ~~~
 qvm-prefs WindowsNew ip 10.137.0.x
 ~~~

From 607d525d43464f3e3f69faf326ca666e93aafa4e Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Wed, 12 Jun 2024 18:44:05 +0200
Subject: [PATCH 155/332] better conv 4 rst

---
 user/templates/windows/windows-qubes-4-1.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/templates/windows/windows-qubes-4-1.md b/user/templates/windows/windows-qubes-4-1.md
index f4f6f3c9..7b998681 100644
--- a/user/templates/windows/windows-qubes-4-1.md
+++ b/user/templates/windows/windows-qubes-4-1.md
@@ -65,7 +65,7 @@ Create a VM named WindowsNew in [HVM](/doc/hvm/) mode (Xen's current PVH limitat
 - Using Qube Manager
 
 
-   In order to create the new qube, select the command Qube -> New Qube in the Qube Manager::
+   In order to create the new qube, select the command Qube -> New Qube in the Qube Manager:
   
      - Name: `WindowsNew`, Color: `orange` (for a standalone qubes, `black` for a template)
      - Type: `StandaloneVM (fully persistent)` or `TemplateVM (template home, persistent root)`

From 9745db8fc5913a3377219ec2ccfb1f041d1f0b83 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Tue, 18 Jun 2024 00:15:13 -0700
Subject: [PATCH 156/332] Update R4.1 support status to "extended security
 support"

---
 user/downloading-installing-upgrading/supported-releases.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/downloading-installing-upgrading/supported-releases.md b/user/downloading-installing-upgrading/supported-releases.md
index 8711facc..3f8d790f 100644
--- a/user/downloading-installing-upgrading/supported-releases.md
+++ b/user/downloading-installing-upgrading/supported-releases.md
@@ -22,7 +22,7 @@ Qubes OS releases are supported for **six months** after each subsequent major o
 | Release 3.1 | 2016-03-09 | 2017-03-29 | Unsupported    |
 | Release 3.2 | 2016-09-29 | 2019-03-28 | Unsupported    |
 | Release 4.0 | 2018-03-28 | 2022-08-04 | Unsupported    |
-| Release 4.1 | 2022-02-04 | 2024-06-18 | Supported      |
+| Release 4.1 | 2022-02-04 | 2024-06-18 | [Extended security support](/news/2024/06/18/qubes-os-4-1-has-reached-end-of-life/)|
 | Release 4.2 | 2023-12-18 | TBA        | Supported      |
 | Release 4.3 | TBA        | TBA        | In development |
 

From 637c712ee32dd378a5e9fb491f4decdd633c3bb4 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Tue, 18 Jun 2024 00:22:56 -0700
Subject: [PATCH 157/332] Update link

---
 user/downloading-installing-upgrading/supported-releases.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/downloading-installing-upgrading/supported-releases.md b/user/downloading-installing-upgrading/supported-releases.md
index 3f8d790f..0e319bab 100644
--- a/user/downloading-installing-upgrading/supported-releases.md
+++ b/user/downloading-installing-upgrading/supported-releases.md
@@ -22,7 +22,7 @@ Qubes OS releases are supported for **six months** after each subsequent major o
 | Release 3.1 | 2016-03-09 | 2017-03-29 | Unsupported    |
 | Release 3.2 | 2016-09-29 | 2019-03-28 | Unsupported    |
 | Release 4.0 | 2018-03-28 | 2022-08-04 | Unsupported    |
-| Release 4.1 | 2022-02-04 | 2024-06-18 | [Extended security support](/news/2024/06/18/qubes-os-4-1-has-reached-end-of-life/)|
+| Release 4.1 | 2022-02-04 | 2024-06-18 | [Extended security support](/news/2024/06/18/qubes-os-4-1-has-reached-end-of-life-extended-security-support-continues-until-2024-07-31/)|
 | Release 4.2 | 2023-12-18 | TBA        | Supported      |
 | Release 4.3 | TBA        | TBA        | In development |
 

From cb4ec61ea9af0b5946e2b3b91837403475b4e874 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Sun, 23 Jun 2024 22:43:26 -0700
Subject: [PATCH 158/332] Update release notes for Qubes OS 4.2.2

QubesOS/qubes-issues#9316
QubesOS/qubes-posts#135
---
 developer/releases/4_2/release-notes.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/developer/releases/4_2/release-notes.md b/developer/releases/4_2/release-notes.md
index 10fd2d1b..000f486a 100644
--- a/developer/releases/4_2/release-notes.md
+++ b/developer/releases/4_2/release-notes.md
@@ -54,6 +54,8 @@ We strongly recommend [updating Qubes OS](/doc/how-to-update/) immediately after
 
 - Qubes 4.2 does not support Debian 11 templates (see [supported template releases](/doc/supported-releases/#templates)). Please [upgrade your Debian templates](/doc/templates/debian/#upgrading) to Debian 12.
 
+- Qubes 4.2.2 includes a fix for [#8332: File-copy qrexec service is overly restrictive](https://github.com/QubesOS/qubes-issues/issues/8332). As explained in the issue comments, a change was introduced 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. This was a backward-incompatible change that should not have been introduced in a minor release. The fix replaces the default file-copy qrexec service that exists in Qubes 4.2.0 and 4.2.1 (`qubes.Filecopy`) with a less restrictive file-copy qrexec service that restores the pre-4.2 behavior (`qubes.Filecopy+allow-all-bytes`). Users who wish to preserve the more restrictive 4.2.0 and 4.2.1 behavior can do so by modifying their RPC policy rules to use the more restrictive service. 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 a "deny" rule for `qubes.Filecopy+allow-all-bytes` before all other relevant rules. For more information, see [RPC policies](/doc/rpc-policy/) and [Qube configuration interface](/doc/vm-interface/#qubes-rpc).
+
 ## Download
 
 All Qubes ISOs and associated [verification files](/security/verifying-signatures/) are available on the [downloads](/downloads/) page.

From 8da080c19472d6a8037dd4e2cdf115baf4877ac6 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Tue, 25 Jun 2024 01:23:19 -0700
Subject: [PATCH 159/332] Update QubesOS/qubes-issues#8332 service name and
 explanation

---
 developer/releases/4_2/release-notes.md | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/developer/releases/4_2/release-notes.md b/developer/releases/4_2/release-notes.md
index 000f486a..3c459af2 100644
--- a/developer/releases/4_2/release-notes.md
+++ b/developer/releases/4_2/release-notes.md
@@ -54,7 +54,11 @@ We strongly recommend [updating Qubes OS](/doc/how-to-update/) immediately after
 
 - Qubes 4.2 does not support Debian 11 templates (see [supported template releases](/doc/supported-releases/#templates)). Please [upgrade your Debian templates](/doc/templates/debian/#upgrading) to Debian 12.
 
-- Qubes 4.2.2 includes a fix for [#8332: File-copy qrexec service is overly restrictive](https://github.com/QubesOS/qubes-issues/issues/8332). As explained in the issue comments, a change was introduced 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. This was a backward-incompatible change that should not have been introduced in a minor release. The fix replaces the default file-copy qrexec service that exists in Qubes 4.2.0 and 4.2.1 (`qubes.Filecopy`) with a less restrictive file-copy qrexec service that restores the pre-4.2 behavior (`qubes.Filecopy+allow-all-bytes`). Users who wish to preserve the more restrictive 4.2.0 and 4.2.1 behavior can do so by modifying their RPC policy rules to use the more restrictive service. 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 a "deny" rule for `qubes.Filecopy+allow-all-bytes` before all other relevant rules. For more information, see [RPC policies](/doc/rpc-policy/) and [Qube configuration interface](/doc/vm-interface/#qubes-rpc).
+- Qubes 4.2.2 includes a fix for [#8332: File-copy qrexec service is overly restrictive](https://github.com/QubesOS/qubes-issues/issues/8332). 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 risk 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. This 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 replacing the file-copy qrexec service from Qubes 4.2.0 and 4.2.1 (`qubes.Filecopy`) with a less restrictive service (`qubes.Filecopy+allow-all-names`).
+
+Users who wish to use the more restrictive 4.2.0 and 4.2.1 behavior can do so by modifying their RPC policy rules to use the more restrictive service. 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 a "deny" rule for `qubes.Filecopy+allow-all-names` before all other relevant rules. For more information, see [RPC policies](/doc/rpc-policy/) and [Qube configuration interface](/doc/vm-interface/#qubes-rpc).
 
 ## Download
 

From beac6f7e831f2b85418c72f09decb9d0c096bc3e Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Wed, 26 Jun 2024 02:35:23 -0700
Subject: [PATCH 160/332] Explain how the fix works; clarify relationship
 between services

---
 developer/releases/4_2/release-notes.md | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/developer/releases/4_2/release-notes.md b/developer/releases/4_2/release-notes.md
index 3c459af2..13af20d9 100644
--- a/developer/releases/4_2/release-notes.md
+++ b/developer/releases/4_2/release-notes.md
@@ -54,11 +54,13 @@ We strongly recommend [updating Qubes OS](/doc/how-to-update/) immediately after
 
 - Qubes 4.2 does not support Debian 11 templates (see [supported template releases](/doc/supported-releases/#templates)). Please [upgrade your Debian templates](/doc/templates/debian/#upgrading) to Debian 12.
 
-- Qubes 4.2.2 includes a fix for [#8332: File-copy qrexec service is overly restrictive](https://github.com/QubesOS/qubes-issues/issues/8332). 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 risk 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. This 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 replacing the file-copy qrexec service from Qubes 4.2.0 and 4.2.1 (`qubes.Filecopy`) with a less restrictive service (`qubes.Filecopy+allow-all-names`).
-
-Users who wish to use the more restrictive 4.2.0 and 4.2.1 behavior can do so by modifying their RPC policy rules to use the more restrictive service. 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 a "deny" rule for `qubes.Filecopy+allow-all-names` before all other relevant rules. For more information, see [RPC policies](/doc/rpc-policy/) and [Qube configuration interface](/doc/vm-interface/#qubes-rpc).
+- Qubes 4.2.2 includes a fix for [#8332: File-copy qrexec service is overly restrictive](https://github.com/QubesOS/qubes-issues/issues/8332). 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 a "deny" rule for `qubes.Filecopy+allow-all-names` before all other relevant rules. For more information, see [RPC policies](/doc/rpc-policy/) and [Qube configuration interface](/doc/vm-interface/#qubes-rpc).
 
 ## Download
 

From 3cec58bf7d108e4104c30c8b5e3942149e9e94d0 Mon Sep 17 00:00:00 2001
From: Piotr Bartman <prbartman@invisiblethingslab.com>
Date: Wed, 20 Mar 2024 22:20:01 +0100
Subject: [PATCH 161/332] q-dev: update docs

---
 developer/services/admin-api.md | 233 ++++++++++++++++++++------------
 1 file changed, 144 insertions(+), 89 deletions(-)

diff --git a/developer/services/admin-api.md b/developer/services/admin-api.md
index 0087bcaf..74314ed7 100644
--- a/developer/services/admin-api.md
+++ b/developer/services/admin-api.md
@@ -62,95 +62,98 @@ yet documented.
 The API should be implemented as a set of qrexec calls. This is to make it easy
 to set the policy using current mechanism.
 
-| call                                  | dest      | argument  | inside                                    | return                                                    | note |
-| ------------------------------------- | --------- | --------- | ----------------------------------------- | --------------------------------------------------------- | ---- |
-| `admin.vmclass.List`                   | `dom0`    | -         | -                                         | `<class>\n`                                               |
-| `admin.vm.List`                        | `dom0|<vm>` | -         | -                                         | `<name> class=<class> state=<state>\n`                    |
-| `admin.vm.Create.<class>`              | `dom0`    | template  | `name=<name> label=<label>`               | -                                                         |
-| `admin.vm.CreateInPool.<class>`        | `dom0`    | template  | `name=<name> label=<label> `<br/>`pool=<pool> pool:<volume>=<pool>`   | -                                                         | either use `pool=` to put all volumes there, <br/>or `pool:<volume>=` for individual volumes - both forms are not allowed at the same time
-| `admin.vm.CreateDisposable`            | template  | -         | -                                         | name                                                      | Create new DisposableVM, `template` is any AppVM with `dispvm_allowed` set to True, or `dom0` to use default defined in `default_dispvm` property of calling VM; VM created with this call will be automatically removed after its shutdown; the main difference from `admin.vm.Create.DispVM` is automatic (random) name generation.
-| `admin.vm.Remove`                      | vm        | -         | -                                         | -                                                         |
-| `admin.label.List`                     | `dom0`    | -         | -                                         | `<property>\n`                                            |
-| `admin.label.Create`                   | `dom0`    | label     | `0xRRGGBB`                                | -                                                         |
-| `admin.label.Get`                      | `dom0`    | label     | -                                         | `0xRRGGBB`                                                |
-| `admin.label.Index`                    | `dom0`    | label     | -                                         | `<label-index>`                                           |
-| `admin.label.Remove`                   | `dom0`    | label     | -                                         | -                                                         |
-| `admin.property.List`                  | `dom0`    | -         | -                                         | `<property>\n`                                            |
-| `admin.property.Get`                   | `dom0`    | property  | -                                         | `default={True|False} `<br/>`type={str|int|bool|vm|label|list} <value>`   | Type `list` is added in R4.1. Values are of type `str` and each entry is suffixed with newline character.
-| `admin.property.GetAll`                | `dom0`    | -         | -                                         | `<property-name> <full-value-as-in-property.Get>\n`       | Get all the properties in one call. Each property is returned on a separate line and use the same value encoding as property.Get method, with an exception that newlines are encoded as literal `\n` and literal `\` are encoded as `\\`.
-| `admin.property.GetDefault`            | `dom0`    | property  | -                                         | `type={str|int|bool|vm|label|list} <value>`               | Type `list` is added in R4.1. Values are of type `str` and each entry is suffixed with newline character.
-| `admin.property.Help`                  | `dom0`    | property  | -                                         | `help`                                                    |
-| `admin.property.HelpRst`               | `dom0`    | property  | -                                         | `help.rst`                                                |
-| `admin.property.Reset`                 | `dom0`    | property  | -                                         | -                                                         |
-| `admin.property.Set`                   | `dom0`    | property  | value                                     | -                                                         |
-| `admin.vm.property.List`               | vm        | -         | -                                         | `<property>\n`                                            |
-| `admin.vm.property.Get`                | vm        | property  | -                                         | `default={True|False} `<br/>`type={str|int|bool|vm|label|list} <value>`   | Type `list` is added in R4.1. Each list entry is suffixed with a newline character.
-| `admin.vm.property.GetAll`             | vm        | -         | -                                         | `<property-name> <full-value-as-in-property.Get>\n`       | Get all the properties in one call. Each property is returned on a separate line and use the same value encoding as property.Get method, with an exception that newlines are encoded as literal `\n` and literal `\` are encoded as `\\`.
-| `admin.vm.property.GetDefault`         | vm        | property  | -                                         | `type={str|int|bool|vm|label|type} <value>`               | Type `list` is added in R4.1. Each list entry is suffixed with a newline character.
-| `admin.vm.property.Help`               | vm        | property  | -                                         | `help`                                                    |
-| `admin.vm.property.HelpRst`            | vm        | property  | -                                         | `help.rst`                                                |
-| `admin.vm.property.Reset`              | vm        | property  | -                                         | -                                                         |
-| `admin.vm.property.Set`                | vm        | property  | value                                     | -                                                         |
-| `admin.vm.feature.List`                | vm        | -         | -                                         | `<feature>\n`                                             |
-| `admin.vm.feature.Get`                 | vm        | feature   | -                                         | value                                                     |
-| `admin.vm.feature.CheckWithTemplate`   | vm        | feature   | -                                         | value                                                     |
-| `admin.vm.feature.CheckWithNetvm`      | vm        | feature   | -                                         | value                                                     |
-| `admin.vm.feature.CheckWithAdminVM`    | vm        | feature   | -                                         | value                                                     |
-| `admin.vm.feature.CheckWithTemplateAndAdminVM`| vm | feature   | -                                         | value                                                     |
-| `admin.vm.feature.Remove`              | vm        | feature   | -                                         | -                                                         |
-| `admin.vm.feature.Set`                 | vm        | feature   | value                                     | -                                                         |
-| `admin.vm.tag.List`                    | vm        | -         | -                                         | `<tag>\n`                                                 |
-| `admin.vm.tag.Get`                     | vm        | tag       | -                                         | `0` or `1`                                                | retcode? |
-| `admin.vm.tag.Remove`                  | vm        | tag       | -                                         | -                                                         |
-| `admin.vm.tag.Set`                     | vm        | tag       | -                                         | -                                                         |
-| `admin.vm.firewall.Get`                | vm        | -         | -                                         | `<rule>\n`                                                | rules syntax as in [firewall interface](/doc/vm-interface/#firewall-rules-in-4x) with addition of `expire=` and `comment=` options; `comment=` (if present) must be the last option
-| `admin.vm.firewall.Set`                | vm        | -         | `<rule>\n`                                | -                                                         | set firewall rules, see `admin.vm.firewall.Get` for syntax
-| `admin.vm.firewall.Reload`             | vm        | -         | -                                         | -                                                         | force reload firewall without changing any rule
-| `admin.vm.deviceclass.List`            | `dom0`    | -         | -                                         | `<class>\n`                                               |
-| `admin.vm.device.<class>.Attach`       | vm        | device    | options                                   | -                                                         | `device` is in form `<backend-name>+<device-ident>` <br/>optional options given in `key=value` format, separated with spaces; <br/>options can include `persistent=True` to "persistently" attach the device (default is temporary)
-| `admin.vm.device.<class>.Detach`       | vm        | device    | -                                         | -                                                         | `device` is in form `<backend-name>+<device-ident>`
-| `admin.vm.device.<class>.Set.persistent`| vm       | device    | `True`\|`False`                            | -                                                         | `device` is in form `<backend-name>+<device-ident>`
-| `admin.vm.device.<class>.List`         | vm        | -         | -                                         | `<device> <options>\n`                                    | options can include `persistent=True` for "persistently" attached devices (default is temporary)
-| `admin.vm.device.<class>.Available`    | vm        | device-ident | -                                         | `<device-ident> <properties> description=<desc>\n`        | optional service argument may be used to get info about a single device, <br/>optional (device class specific) properties are in `key=value` form, <br/>`description` must be the last one and is the only one allowed to contain spaces
-| `admin.pool.List`                      | `dom0`    | -         | -                                         | `<pool>\n`                                                |
-| `admin.pool.ListDrivers`               | `dom0`    | -         | -                                         | `<pool-driver> <property> ...\n`                          | Properties allowed in `admin.pool.Add`
-| `admin.pool.Info`                      | `dom0`    | pool      | -                                         | `<property>=<value>\n`                                    |
-| `admin.pool.Add`                       | `dom0`    | driver    | `<property>=<value>\n`                    | -                                                         |
-| `admin.pool.Set.revisions_to_keep`     | `dom0`    | pool      | `<value>`                                 | -                                                         |
-| `admin.pool.Remove`                    | `dom0`    | pool      | -                                         | -                                                         |
-| `admin.pool.volume.List`               | `dom0`    | pool      | -                                         | volume id                                                 |
-| `admin.pool.volume.Info`               | `dom0`    | pool      | vid                                       | `<property>=<value>\n`                                    |
-| `admin.pool.volume.Set.revisions_to_keep`| `dom0`  | pool      | `<vid> <value>`                           | -                                                         |
-| `admin.pool.volume.ListSnapshots`      | `dom0`    | pool      | vid                                       | `<snapshot>\n`                                            |
-| `admin.pool.volume.Snapshot`           | `dom0`    | pool      | vid                                       | snapshot                                                  |
-| `admin.pool.volume.Revert`             | `dom0`    | pool      | `<vid> <snapshot>`                        | -                                                         |
-| `admin.pool.volume.Resize`             | `dom0`    | pool      | `<vid> <size_in_bytes>`                   | -                                                         |
-| `admin.pool.volume.Import`             | `dom0`    | pool      | `<vid>\n<raw volume data>`                | -                                                         |
-| `admin.pool.volume.CloneFrom`          | `dom0`    | pool      | vid                                       | token, to be used in `admin.pool.volume.CloneTo`          | obtain a token to copy volume `vid` in `pool`;<br/>the token is one time use only, it's invalidated by `admin.pool.volume.CloneTo`, even if the operation fails |
-| `admin.pool.volume.CloneTo`            | `dom0`    | pool      | `<vid> <token>`                           | -                                                         | copy volume pointed by a token to volume `vid` in `pool` |
-| `admin.vm.volume.List`                 | vm        | -         | -                                         | `<volume>\n`                                              | `<volume>` is per-VM volume name (`root`, `private`, etc), `<vid>` is pool-unique volume id
-| `admin.vm.volume.Info`                 | vm        | volume    | -                                         | `<property>=<value>\n`                                    |
-| `admin.vm.volume.Set.revisions_to_keep`| vm        | volume    | value                                     | -                                                         |
-| `admin.vm.volume.ListSnapshots`        | vm        | volume    | -                                         | snapshot                                                  | duplicate of `admin.pool.volume.`, but with other call params |
-| `admin.vm.volume.Snapshot`             | vm        | volume    | -                                         | snapshot                                                  | id. |
-| `admin.vm.volume.Revert`               | vm        | volume    | snapshot                                  | -                                                         | id. |
-| `admin.vm.volume.Resize`               | vm        | volume    | size_in_bytes                             | -                                                         | id. |
-| `admin.vm.volume.Import`               | vm        | volume    | raw volume data                           | -                                                         | id. |
-| `admin.vm.volume.ImportWithSize`       | vm        | volume    | `<size_in_bytes>\n<raw volume data>`      | -                                                         | new version of `admin.vm.volume.Import`, allows new volume to be different size |
-| `admin.vm.volume.Clear`                | vm        | volume    | -                                         | -                                                         | clear contents of volume |
-| `admin.vm.volume.CloneFrom`            | vm        | volume    | -                                         | token, to be used in `admin.vm.volume.CloneTo`            | obtain a token to copy `volume` of `vm`;<br/>the token is one time use only, it's invalidated by `admin.vm.volume.CloneTo`, even if the operation fails |
-| `admin.vm.volume.CloneTo`              | vm        | volume    | token, obtained with `admin.vm.volume.CloneFrom` | -                                                         | copy volume pointed by a token to `volume` of `vm` |
-| `admin.vm.CurrentState`                | vm        | -         | -                                         | `<state-property>=<value>\n`                              | state properties: `power_state`, `mem`, `mem_static_max`, `cputime`
-| `admin.vm.Start`                       | vm        | -         | -                                         | -                                                         |
-| `admin.vm.Shutdown`                    | vm        | -         | -                                         | -                                                         |
-| `admin.vm.Pause`                       | vm        | -         | -                                         | -                                                         |
-| `admin.vm.Unpause`                     | vm        | -         | -                                         | -                                                         |
-| `admin.vm.Kill`                        | vm        | -         | -                                         | -                                                         |
-| `admin.backup.Execute`                 | `dom0`    | config id | -                                         | -                                                         | config in `/etc/qubes/backup/<id>.conf`, only one backup operation of given `config id` can be running at once |
-| `admin.backup.Info`                    | `dom0`    | config id | -                                         | backup info                                               | info what would be included in the backup
-| `admin.backup.Cancel`                  | `dom0`    | config id | -                                         | -                                                         | cancel running backup operation
-| `admin.Events`                         | `dom0|vm` | -         | -                                         | events                                                    |
-| `admin.vm.Stats`                       | `dom0|vm` | -         | -                                         | `vm-stats` events, see below                              | emit VM statistics (CPU, memory usage) in form of events
+| call                                           | dest       | argument     | inside                                                              | return                                              | note |
+|------------------------------------------------|------------|--------------|---------------------------------------------------------------------|-----------------------------------------------------| ---- |
+| `admin.vmclass.List`                           | `dom0`     | -            | -                                                                   | `<class>\n`                                         |
+| `admin.vm.List`                                | `dom0      | <vm>`        | -                                                                   | -                                                   | `<name> class=<class> state=<state>\n`                    |
+| `admin.vm.Create.<class>`                      | `dom0`     | template     | `name=<name> label=<label>`                                         | -                                                   |
+| `admin.vm.CreateInPool.<class>`                | `dom0`     | template     | `name=<name> label=<label> `<br/>`pool=<pool> pool:<volume>=<pool>` | -                                                   | either use `pool=` to put all volumes there, <br/>or `pool:<volume>=` for individual volumes - both forms are not allowed at the same time
+| `admin.vm.CreateDisposable`                    | template   | -            | -                                                                   | name                                                | Create new DisposableVM, `template` is any AppVM with `dispvm_allowed` set to True, or `dom0` to use default defined in `default_dispvm` property of calling VM; VM created with this call will be automatically removed after its shutdown; the main difference from `admin.vm.Create.DispVM` is automatic (random) name generation.
+| `admin.vm.Remove`                              | vm         | -            | -                                                                   | -                                                   |
+| `admin.label.List`                             | `dom0`     | -            | -                                                                   | `<property>\n`                                      |
+| `admin.label.Create`                           | `dom0`     | label        | `0xRRGGBB`                                                          | -                                                   |
+| `admin.label.Get`                              | `dom0`     | label        | -                                                                   | `0xRRGGBB`                                          |
+| `admin.label.Index`                            | `dom0`     | label        | -                                                                   | `<label-index>`                                     |
+| `admin.label.Remove`                           | `dom0`     | label        | -                                                                   | -                                                   |
+| `admin.property.List`                          | `dom0`     | -            | -                                                                   | `<property>\n`                                      |
+| `admin.property.Get`                           | `dom0`     | property     | -                                                                   | `default={True                                      |False} `<br/>`type={str|int|bool|vm|label|list} <value>`   | Type `list` is added in R4.1. Values are of type `str` and each entry is suffixed with newline character.
+| `admin.property.GetAll`                        | `dom0`     | -            | -                                                                   | `<property-name> <full-value-as-in-property.Get>\n` | Get all the properties in one call. Each property is returned on a separate line and use the same value encoding as property.Get method, with an exception that newlines are encoded as literal `\n` and literal `\` are encoded as `\\`.
+| `admin.property.GetDefault`                    | `dom0`     | property     | -                                                                   | `type={str                                          |int|bool|vm|label|list} <value>`               | Type `list` is added in R4.1. Values are of type `str` and each entry is suffixed with newline character.
+| `admin.property.Help`                          | `dom0`     | property     | -                                                                   | `help`                                              |
+| `admin.property.HelpRst`                       | `dom0`     | property     | -                                                                   | `help.rst`                                          |
+| `admin.property.Reset`                         | `dom0`     | property     | -                                                                   | -                                                   |
+| `admin.property.Set`                           | `dom0`     | property     | value                                                               | -                                                   |
+| `admin.vm.property.List`                       | vm         | -            | -                                                                   | `<property>\n`                                      |
+| `admin.vm.property.Get`                        | vm         | property     | -                                                                   | `default={True                                      |False} `<br/>`type={str|int|bool|vm|label|list} <value>`   | Type `list` is added in R4.1. Each list entry is suffixed with a newline character.
+| `admin.vm.property.GetAll`                     | vm         | -            | -                                                                   | `<property-name> <full-value-as-in-property.Get>\n` | Get all the properties in one call. Each property is returned on a separate line and use the same value encoding as property.Get method, with an exception that newlines are encoded as literal `\n` and literal `\` are encoded as `\\`.
+| `admin.vm.property.GetDefault`                 | vm         | property     | -                                                                   | `type={str                                          |int|bool|vm|label|type} <value>`               | Type `list` is added in R4.1. Each list entry is suffixed with a newline character.
+| `admin.vm.property.Help`                       | vm         | property     | -                                                                   | `help`                                              |
+| `admin.vm.property.HelpRst`                    | vm         | property     | -                                                                   | `help.rst`                                          |
+| `admin.vm.property.Reset`                      | vm         | property     | -                                                                   | -                                                   |
+| `admin.vm.property.Set`                        | vm         | property     | value                                                               | -                                                   |
+| `admin.vm.feature.List`                        | vm         | -            | -                                                                   | `<feature>\n`                                       |
+| `admin.vm.feature.Get`                         | vm         | feature      | -                                                                   | value                                               |
+| `admin.vm.feature.CheckWithTemplate`           | vm         | feature      | -                                                                   | value                                               |
+| `admin.vm.feature.CheckWithNetvm`              | vm         | feature      | -                                                                   | value                                               |
+| `admin.vm.feature.CheckWithAdminVM`            | vm         | feature      | -                                                                   | value                                               |
+| `admin.vm.feature.CheckWithTemplateAndAdminVM` | vm         | feature      | -                                                                   | value                                               |
+| `admin.vm.feature.Remove`                      | vm         | feature      | -                                                                   | -                                                   |
+| `admin.vm.feature.Set`                         | vm         | feature      | value                                                               | -                                                   |
+| `admin.vm.tag.List`                            | vm         | -            | -                                                                   | `<tag>\n`                                           |
+| `admin.vm.tag.Get`                             | vm         | tag          | -                                                                   | `0` or `1`                                          | retcode? |
+| `admin.vm.tag.Remove`                          | vm         | tag          | -                                                                   | -                                                   |
+| `admin.vm.tag.Set`                             | vm         | tag          | -                                                                   | -                                                   |
+| `admin.vm.firewall.Get`                        | vm         | -            | -                                                                   | `<rule>\n`                                          | rules syntax as in [firewall interface](/doc/vm-interface/#firewall-rules-in-4x) with addition of `expire=` and `comment=` options; `comment=` (if present) must be the last option
+| `admin.vm.firewall.Set`                        | vm         | -            | `<rule>\n`                                                          | -                                                   | set firewall rules, see `admin.vm.firewall.Get` for syntax
+| `admin.vm.firewall.Reload`                     | vm         | -            | -                                                                   | -                                                   | force reload firewall without changing any rule
+| `admin.vm.device.<class>.Attach`               | vm         | device       | assignment-serialization                                            | -                                                   | `device` is in form `<backend-name>+<device-ident>` <br/>optional options given in `key=value` format, separated with spaces; <br/>options can include `persistent=True` to "persistently" attach the device (default is temporary)
+| `admin.vm.device.<class>.Detach`               | vm         | device       | -                                                                   | -                                                   | `device` is in form `<backend-name>+<device-ident>`.
+| `admin.vm.device.<class>.Assign`               | vm         | device       | assignment-serialization                                            | -                                                   | `device` is in form `<backend-name>+<device-ident>` <br/> `assignment-serialization` is specified in the section Device Serialization.
+| `admin.vm.device.<class>.Unassign`             | vm         | device       | -                                                                   | -                                                   | `device` is in form `<backend-name>+<device-ident>`.
+| `admin.vm.device.<class>.Set.required`         | vm         | device       | `True`\|`False`                                                     | -                                                   | `device` is in form `<backend-name>+<device-ident>`
+| `admin.vm.deviceclass.List`                    | `dom0`     | -            | -                                                                   | `<deviceclass>\n`                                   |
+| `admin.vm.device.<class>.Available`            | vm         | device-ident | -                                                                   | `<device-ident> <device-serialization>\n`           | optional service argument may be used to get info about a single device, <br/> `device-serialization` is specified in the section Device Serialization.
+| `admin.vm.device.<class>.Assigned`             | vm         | device-ident | -                                                                   | `<device-ident> <assignment-serialization>\n`       | optional service argument may be used to get info about a single device, <br/> `assignment-serialization` is specified in the section Device Serialization.
+| `admin.vm.device.<class>.Attached`             | vm         | device-ident | -                                                                   | `<device-ident> <assignment-serialization>\n`       | optional service argument may be used to get info about a single device, <br/> `assignment-serialization` is specified in the section Device Serialization.
+| `admin.pool.List`                              | `dom0`     | -            | -                                                                   | `<pool>\n`                                          |
+| `admin.pool.ListDrivers`                       | `dom0`     | -            | -                                                                   | `<pool-driver> <property> ...\n`                    | Properties allowed in `admin.pool.Add`
+| `admin.pool.Info`                              | `dom0`     | pool         | -                                                                   | `<property>=<value>\n`                              |
+| `admin.pool.Add`                               | `dom0`     | driver       | `<property>=<value>\n`                                              | -                                                   |
+| `admin.pool.Set.revisions_to_keep`             | `dom0`     | pool         | `<value>`                                                           | -                                                   |
+| `admin.pool.Remove`                            | `dom0`     | pool         | -                                                                   | -                                                   |
+| `admin.pool.volume.List`                       | `dom0`     | pool         | -                                                                   | volume id                                           |
+| `admin.pool.volume.Info`                       | `dom0`     | pool         | vid                                                                 | `<property>=<value>\n`                              |
+| `admin.pool.volume.Set.revisions_to_keep`      | `dom0`     | pool         | `<vid> <value>`                                                     | -                                                   |
+| `admin.pool.volume.ListSnapshots`              | `dom0`     | pool         | vid                                                                 | `<snapshot>\n`                                      |
+| `admin.pool.volume.Snapshot`                   | `dom0`     | pool         | vid                                                                 | snapshot                                            |
+| `admin.pool.volume.Revert`                     | `dom0`     | pool         | `<vid> <snapshot>`                                                  | -                                                   |
+| `admin.pool.volume.Resize`                     | `dom0`     | pool         | `<vid> <size_in_bytes>`                                             | -                                                   |
+| `admin.pool.volume.Import`                     | `dom0`     | pool         | `<vid>\n<raw volume data>`                                          | -                                                   |
+| `admin.pool.volume.CloneFrom`                  | `dom0`     | pool         | vid                                                                 | token, to be used in `admin.pool.volume.CloneTo`    | obtain a token to copy volume `vid` in `pool`;<br/>the token is one time use only, it's invalidated by `admin.pool.volume.CloneTo`, even if the operation fails |
+| `admin.pool.volume.CloneTo`                    | `dom0`     | pool         | `<vid> <token>`                                                     | -                                                   | copy volume pointed by a token to volume `vid` in `pool` |
+| `admin.vm.volume.List`                         | vm         | -            | -                                                                   | `<volume>\n`                                        | `<volume>` is per-VM volume name (`root`, `private`, etc), `<vid>` is pool-unique volume id
+| `admin.vm.volume.Info`                         | vm         | volume       | -                                                                   | `<property>=<value>\n`                              |
+| `admin.vm.volume.Set.revisions_to_keep`        | vm         | volume       | value                                                               | -                                                   |
+| `admin.vm.volume.ListSnapshots`                | vm         | volume       | -                                                                   | snapshot                                            | duplicate of `admin.pool.volume.`, but with other call params |
+| `admin.vm.volume.Snapshot`                     | vm         | volume       | -                                                                   | snapshot                                            | id. |
+| `admin.vm.volume.Revert`                       | vm         | volume       | snapshot                                                            | -                                                   | id. |
+| `admin.vm.volume.Resize`                       | vm         | volume       | size_in_bytes                                                       | -                                                   | id. |
+| `admin.vm.volume.Import`                       | vm         | volume       | raw volume data                                                     | -                                                   | id. |
+| `admin.vm.volume.ImportWithSize`               | vm         | volume       | `<size_in_bytes>\n<raw volume data>`                                | -                                                   | new version of `admin.vm.volume.Import`, allows new volume to be different size |
+| `admin.vm.volume.Clear`                        | vm         | volume       | -                                                                   | -                                                   | clear contents of volume |
+| `admin.vm.volume.CloneFrom`                    | vm         | volume       | -                                                                   | token, to be used in `admin.vm.volume.CloneTo`      | obtain a token to copy `volume` of `vm`;<br/>the token is one time use only, it's invalidated by `admin.vm.volume.CloneTo`, even if the operation fails |
+| `admin.vm.volume.CloneTo`                      | vm         | volume       | token, obtained with `admin.vm.volume.CloneFrom`                    | -                                                   | copy volume pointed by a token to `volume` of `vm` |
+| `admin.vm.CurrentState`                        | vm         | -            | -                                                                   | `<state-property>=<value>\n`                        | state properties: `power_state`, `mem`, `mem_static_max`, `cputime`
+| `admin.vm.Start`                               | vm         | -            | -                                                                   | -                                                   |
+| `admin.vm.Shutdown`                            | vm         | -            | -                                                                   | -                                                   |
+| `admin.vm.Pause`                               | vm         | -            | -                                                                   | -                                                   |
+| `admin.vm.Unpause`                             | vm         | -            | -                                                                   | -                                                   |
+| `admin.vm.Kill`                                | vm         | -            | -                                                                   | -                                                   |
+| `admin.backup.Execute`                         | `dom0`     | config id    | -                                                                   | -                                                   | config in `/etc/qubes/backup/<id>.conf`, only one backup operation of given `config id` can be running at once |
+| `admin.backup.Info`                            | `dom0`     | config id    | -                                                                   | backup info                                         | info what would be included in the backup
+| `admin.backup.Cancel`                          | `dom0`     | config id    | -                                                                   | -                                                   | cancel running backup operation
+| `admin.Events`                                 | `dom0      | vm`          | -                                                                   | -                                                   | events                                                    |
+| `admin.vm.Stats`                               | `dom0      | vm`          | -                                                                   | -                                                   | `vm-stats` events, see below                              | emit VM statistics (CPU, memory usage) in form of events
 
 Volume properties:
 
@@ -302,6 +305,58 @@ destination_vm: sys-net
 destination_path: ncftpput -u my-ftp-username -p my-ftp-pass -c my-ftp-server /directory/for/backups
 ```
 
+## Device Serialization
+
+Both device and assignment serialization is ASCII-encoded and contains 
+space-separated key-value pairs. The format includes an `=` between the key 
+and value, and the value is always enclosed in single quotes (`'`). 
+Values may contain spaces or even single quotes, which are escaped with a backslash. 
+If a value is not set (`None`), it is represented as `'unknown'`. 
+For boolean values, `True` is represented as `'yes'`, and `False` as `'no'`. 
+The order of key-value pairs is irrelevant. Keys starting with `_` 
+are considered extra properties and are saved in `data` or `options` 
+for device or assignment respectively.
+
+Information about the serialization format of specific properties can be found below.
+
+Format:
+```
+<ident> <property_1>='<value_1>' <property_2>='<value_2>' <property_3>='<value_3>'...
+```
+
+Detailed serialization format for a device:
+
+- `ident='<ident>'`
+- `backend_domain='<backend_domain.name>'`
+- `devclass='<devclass>'`
+- `vendor='<vendor>'`
+- `product='<product>'`
+- `manufacturer='<manufacturer>'`
+- `name='<name>'`
+- `serial='<serial>'`
+- `self_identity='<self_identity>'`
+- `interfaces='<interface1><interface2>...'`
+    Each device interface is represented with a 7-character length. Each device has at least one interface. Since the length of the interface representation is known, they are serialized as a single string with each interface representation concatenated one after another. The order is irrelevant.
+- `parent_ident='<parent.ident>' parent_devclass='<parent.devclass>'`
+- `attachment='<attachment.name>'`
+- `_<key1>='<value1>' _<key2>='<value2>' ...` (extra parameters)
+
+Detailed serialization format for an assignment:
+
+- `ident='<ident>'`
+- `backend_domain='<backend_domain.name>'`
+- `devclass='<devclass>'`
+- `frontend_domain='<frontend_domain.name>'`
+- `required='<yes/no>'` (default 'no')
+- `attach_automatically='<yes/no>'` (default 'no')
+- `_<key1>='<str(value1)>' _<key2>='<str(value2)>' ...` (options)
+
+Example device serialization:
+
+```
+1-1.1.1 manufacturer='unknown' self_identity='0000:0000::?******' serial='unknown' ident='1-1.1.1' product='Qubes' vendor='ITL' name='Some untrusted garbage' devclass='bus' backend_domain='vm' interfaces=' ******u03**01' _additional_info='' _date='06.12.23' parent_ident='1-1.1' parent_devclass='None'
+```
+
 ## General notes
 
 - there is no provision for `qvm-run`, but there already exists `qubes.VMShell` call

From c78d5624d88cad3cb873df55950b80ccda253a12 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Tue, 2 Jul 2024 22:46:29 +0200
Subject: [PATCH 162/332] better formatting for rst conversion

---
 .../windows/qubes-windows-tools-4-1.md        | 30 +++++++++----------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/user/templates/windows/qubes-windows-tools-4-1.md b/user/templates/windows/qubes-windows-tools-4-1.md
index d02f2dbf..a79d237b 100644
--- a/user/templates/windows/qubes-windows-tools-4-1.md
+++ b/user/templates/windows/qubes-windows-tools-4-1.md
@@ -48,16 +48,16 @@ Below is a breakdown of the feature availability depending on the windows versio
 
 |             Feature                  |  Windows 7 x64 | Windows 8.1/10/11 x64 |
 | ------------------------------------ | :------------: | :-------------------: |
-| Qubes Video Driver                   |        +       |           -           |
-| Qubes Network Setup                  |        +       |           +           |
-| Private Volume Setup (move profiles) |        +       |           +           |
-| File sender/receiver                 |        +       |           +           |
-| Clipboard Copy/Paste                 |        +       |           +           |
-| Application shortcuts                |        +       |           +           |
-| Copy/Edit in Disposable VM           |        +       |           +           |
-| Block device                         |        +       |           +           |
-| USB device                           |        +       |           +           |
-| Audio                                |        +       |           +           |
+| Qubes Video Driver                   |        y       |           n           |
+| Qubes Network Setup                  |        y       |           y           |
+| Private Volume Setup (move profiles) |        y       |           y           |
+| File sender/receiver                 |        y       |           y           |
+| Clipboard Copy/Paste                 |        y       |           y           |
+| Application shortcuts                |        y       |           y           |
+| Copy/Edit in Disposable VM           |        y       |           y           |
+| Block device                         |        y       |           y           |
+| USB device                           |        y       |           y           |
+| Audio                                |        y       |           y           |
 
 Qubes Windows Tools are open source and are distributed under a GPL license.
 
@@ -79,7 +79,7 @@ In the future this step will not be necessary anymore, because we will sign our
 
 The Xen PV Drivers bundled with QWT are signed by a Linux Foundation certificate. Thus Windows 10 and 11 do not require this security mitigation.
 
-**Warning:** it is recommended to increase the default value of Windows VM's `qrexec_timeout` property from 60 (seconds) to, for example, 300. During one of the first reboots after Windows Tools installation Windows user profiles are moved onto the private VM's virtual disk (private.img) and this operation can take some time. Moving profiles and, later on, updating a Windows installation, is performed in an early boot phase when `qrexec` is not yet running, so timeout may occur with the default value. To change the property use this command in `dom0`: *(where `<VMname>` is the name of your Windows VM)*
+**Warning:** it is recommended to increase the default value of Windows VM's `qrexec_timeout` property from 60 (seconds) to, for example, 300. During one of the first reboots after Windows Tools installation Windows user profiles are moved onto the private VM's virtual disk (private.img) and this operation can take some time. Moving profiles and, later on, updating a Windows installation, is performed in an early boot phase when `qrexec` is not yet running, so timeout may occur with the default value. To change the property use this command in `dom0`: *(where <VMname> is the name of your Windows VM)*
 
 		[user@dom0 ~] $ qvm-prefs <VMname> qrexec_timeout 7200
 
@@ -137,7 +137,7 @@ Installing the Qubes Windows Tools on Windows 7, 8.1, 10 and 11 both as a Standa
 
  5. After successful installation, the Windows VM must be shut down and started again, possibly a couple of times. On each shutdown, wait until the VM is really stopped, i.e. Qubes shows no more activity.
 
- 6. Qubes will automatically detect that the tools have been installed in the VM and will set appropriate properties for the VM, such as `qrexec_installed`, `guiagent_installed`, and `default_user`. This can be verified (but is not required) using the `qvm-prefs` command  *(where `<VMname>` is the name of your Windows VM)*:
+ 6. Qubes will automatically detect that the tools have been installed in the VM and will set appropriate properties for the VM, such as `qrexec_installed`, `guiagent_installed`, and `default_user`. This can be verified (but is not required) using the `qvm-prefs` command  *(where <VMname> is the name of your Windows VM)*:
 
 	        [user@dom0 ~] $ qvm-prefs <VMname>
 
@@ -173,7 +173,7 @@ Installing the Qubes Windows Tools on Windows 7, 8.1, 10 and 11 both as a Standa
 	
 	 If Windows is used in a TemplateVM / AppVM combination, this registry fix has to be applied to the TemplateVM, as the `HKLM` registry key belongs to the template-based part of the registry.
 	
- 10. Lastly to enable file copy operations to a Windows VM, the `default_user` property of this VM should be set to the `<username>` that you use to login to the Windows VM. This can be done via the following command on a `dom0` terminal: *(where `<VMname>` is the name of your Windows VM)*
+ 10. Lastly to enable file copy operations to a Windows VM, the `default_user` property of this VM should be set to the `<username>` that you use to login to the Windows VM. This can be done via the following command on a `dom0` terminal: *(where <VMname> is the name of your Windows VM)*
 	
 		`[user@dom0 ~] $ qvm-prefs <VMname> default_user <username>`
   
@@ -267,7 +267,7 @@ Windows qubes can be used as disposables, like any other Linux-based qubes. On c
 	- Name the link, e.g. as `Command Prompt`.
 	- Close the Window with `OK`.
 	- Shut down this AppVM.
-- In the Qube Manager, refresh the applications of the newly created AppVM and select those applications that you want to make available from the disposable. Alternatively, in dom0 execute the command `qvm-sync-appmenus <VMname>`, *where `<VMname>` is the name of your windows qube*.
+- In the Qube Manager, refresh the applications of the newly created AppVM and select those applications that you want to make available from the disposable. Alternatively, in dom0 execute the command `qvm-sync-appmenus <VMname>`, *where <VMname> is the name of your windows qube*.
 - In the Qube Manager, go to the "Advanced" tab and enable the option `Disposable template` for your Windows qube.  Alternatively, in dom0 execute the commands `qvm-prefs <VMname> template_for_dispvms True` and `qvm-features <VMname> appmenus-dispvm 1`.
 - Click `Apply`.
 - Still in the Advanced tab, select your Windows qube as its own `Default disposable template`. Alternatively, in dom0 execute the command `qvm-prefs <VMname> default_dispvm <VMname>`.
@@ -277,7 +277,7 @@ Now you should have a menu `Disposable: <VMname>` containing the applications th
 
 For further information on usage of disposables, see [How to use disposables](/doc/how-to-use-disposables/).
 
-**Caution:** *If a Windows-based disposable is used from another qube via the `Open/Edit in DisposableVM` command, this disposable may not close automatically, due to the command prompt window still running in this dispvm. In this case, the disposable has to be shut down  manually.*
+**Caution:** *If a Windows-based disposable is used from another qube via the Open/Edit in DisposableVM command, this disposable may not close automatically, due to the command prompt window still running in this dispvm. In this case, the disposable has to be shut down  manually.*
 
 ## Installation logs
 

From 2346dac166a9122b665ae946689d0840fa59c6fc Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Tue, 2 Jul 2024 22:47:44 +0200
Subject: [PATCH 163/332] formatting for better rst conversion

---
 user/templates/windows/migrate-to-4-1.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/user/templates/windows/migrate-to-4-1.md b/user/templates/windows/migrate-to-4-1.md
index d80f65d5..f9f60711 100644
--- a/user/templates/windows/migrate-to-4-1.md
+++ b/user/templates/windows/migrate-to-4-1.md
@@ -33,6 +33,7 @@ While this is somewhat straightforward, things get difficult if QWT 4.0.1.3 was
 ## Preparation for Windows 10 and 11
 
 If there is a drive `D:` from this earlier installation of Qubes Windows Tools, it will probably contain incomplete private data; especially the folder `AppData` containing program configuration data will be missing. In this situation, it may be better to perform a new Windows installation, because repair may be difficult and trouble-prone.
+
 - First, be sure that the automatic repair function is disabled. In a command window, execute `bcdedit /set recoveryenabled NO`, and check that this worked by issuing the command `bcdedit`, without parameters, again.
 - Now, uninstall QWT 4.0.1.3, using the Apps and Features function of Windows. This will most likely result in a crash.
 - Restart Windows again, possibly two or three times, until repair options are offered. By hitting the F8 key, select the restart menu, and there select a start in safe mode (in German, it's option number 4).

From 326adab3c0866a1c1d53639419d964847b2c0383 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Tue, 2 Jul 2024 23:09:39 +0200
Subject: [PATCH 164/332] better formatting for rst conv

---
 .../installation-troubleshooting.md                | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/user/troubleshooting/installation-troubleshooting.md b/user/troubleshooting/installation-troubleshooting.md
index 2a0c1936..c745acb4 100644
--- a/user/troubleshooting/installation-troubleshooting.md
+++ b/user/troubleshooting/installation-troubleshooting.md
@@ -65,15 +65,15 @@ These errors may also occur due to an incompatible Nvidia graphics card. If you
 2. Enter GRUB, move the selection to the first choice, and then press the Tab key. 
 3. Now, you are in edit mode. Move the text cursor with your arrow key and after ``kernel=`` line, add:
 
-    ```
-    nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off
-    ```
+```
+nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off
+```
 
-    If the above code doesn't fix the problem, replace it with:
+If the above code doesn't fix the problem, replace it with:
 
-    ```   
-    noexitboot=1 modprobe.blacklist=nouveau rd.driver.blacklist=nouveau --- intitrd.img
-    ```
+```   
+noexitboot=1 modprobe.blacklist=nouveau rd.driver.blacklist=nouveau --- intitrd.img
+```
 
 For more information, look at the [Nvidia Troubleshooting guide](https://forum.qubes-os.org/t/19021#disabling-nouveau).
 

From a1e5c64c4925a7fe2a6d524f0f2bf9d7bbe3577e Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sat, 6 Jul 2024 02:37:44 +0200
Subject: [PATCH 165/332] better conv for rst

---
 user/security-in-qubes/data-leaks.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/user/security-in-qubes/data-leaks.md b/user/security-in-qubes/data-leaks.md
index 51c81201..82b736e7 100644
--- a/user/security-in-qubes/data-leaks.md
+++ b/user/security-in-qubes/data-leaks.md
@@ -48,6 +48,7 @@ Such attacks have been described in the academic literature, but it is doubtful
 3. **Unintentional leaks.** Non-malicious software which is either buggy or doesn't maintain the privacy of user data, whether by design or accident.
    For example, software which automatically sends error reports to a remote server, where these reports contain details about the system which the user did not want to share.
 
+
    Both Qubes firewall and an empty NetVM (i.e., setting the NetVM of an app qube to "none") can fully protect against leaks of type 3.
    However, neither Qubes firewall nor an empty NetVM are guaranteed to protect against leaks of types 1 and 2.
    There are few effective, practical policy measures available to end-users today to stop the leaks of type 1.

From 90ed11a52ab6400f8b0c68e8e2d1b49bbbfe6199 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sat, 6 Jul 2024 18:49:41 +0200
Subject: [PATCH 166/332] better conv for rst

---
 user/security-in-qubes/split-gpg.md | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/user/security-in-qubes/split-gpg.md b/user/security-in-qubes/split-gpg.md
index 58f2c1aa..01e0df34 100644
--- a/user/security-in-qubes/split-gpg.md
+++ b/user/security-in-qubes/split-gpg.md
@@ -152,7 +152,7 @@ Note that, because this makes it easier to accept Split GPG's qrexec authorizati
 
 ### Thunderbird 78 and higher
 
-Starting with version 78, Thunderbird has a built-in PGP feature and no longer requires the Enigmail extension. For users coming from the Enigmail extension, the built-in functionality is more limited currently, including that **public keys must live in your `work-email` qube with Thunderbird rather than your offline `work-gpg` qube**.
+Starting with version 78, Thunderbird has a built-in PGP feature and no longer requires the Enigmail extension. For users coming from the Enigmail extension, the built-in functionality is more limited currently, including that **public keys must live in your work-email qube with Thunderbird rather than your offline work-gpg qube**.
 
 In `work-email`, use the Thunderbird config editor (found at the bottom of preferences/options), and search for `mail.openpgp.allow_external_gnupg`. Switch the value to true. Still in config editor, search for `mail.openpgp.alternative_gpg_path`. Set its value to `/usr/bin/qubes-gpg-client-wrapper`. Restart Thunderbird after this change.
 
@@ -297,6 +297,7 @@ In this example, the following keys are stored in the following locations (see b
 
 * `sec` (master secret key)
 
+
    Depending on your needs, you may wish to create this as a **certify-only (C)** key, i.e., a key which is capable only of signing (a.k.a., "certifying") other keys.
    This key may be created *without* an expiration date.
    This is for two reasons.
@@ -314,6 +315,7 @@ In this example, the following keys are stored in the following locations (see b
 
 * `ssb` (secret subkey)
 
+
    Depending on your needs, you may wish to create two different subkeys: one for **signing (S)** and one for **encryption (E)**.
    You may also wish to give these subkeys reasonable expiration dates (e.g., one year).
    Once these keys expire, it is up to you whether to *renew* these keys by extending the expiration dates or to create *new* subkeys when the existing set expires.
@@ -328,11 +330,13 @@ In this example, the following keys are stored in the following locations (see b
 
 * `pub` (public key)
 
+
    This is the complement of the master secret key.
    It can be uploaded to keyservers (or otherwise publicly distributed) and may be signed by others.
 
 * `vault`
 
+
    This is a network-isolated VM.
    The initial master keypair and subkeys are generated in this VM.
    The master secret key *never* leaves this VM under *any* circumstances.
@@ -340,6 +344,7 @@ In this example, the following keys are stored in the following locations (see b
 
 * `work-gpg`
 
+
    This is a network-isolated VM.
    This VM is used *only* as the GPG backend for `work-email`.
    The secret subkeys (but *not* the master secret key) are [copied](/doc/how-to-copy-and-move-files/#security) from the `vault` VM to this VM.
@@ -347,6 +352,7 @@ In this example, the following keys are stored in the following locations (see b
 
 * `work-email`
 
+
    This VM has access to the mail server.
    It accesses the `work-gpg` VM via the Split GPG protocol.
    The public key may be stored in this VM so that it can be attached to emails and for other such purposes.

From 93f851d813fdc7ca7c439b7add425a9aa4e22395 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sat, 6 Jul 2024 19:25:12 +0200
Subject: [PATCH 167/332] for better conv to rst

---
 user/security-in-qubes/mfa.md | 39 +++++++++++++++++++++++++----------
 1 file changed, 28 insertions(+), 11 deletions(-)

diff --git a/user/security-in-qubes/mfa.md b/user/security-in-qubes/mfa.md
index 62a72e17..a4103e33 100644
--- a/user/security-in-qubes/mfa.md
+++ b/user/security-in-qubes/mfa.md
@@ -157,8 +157,10 @@ Note that setting up both a YubiKey and a NitroKey3 is not supported.
 1. Install YubiKey / NitroKey3 software in the template on which your USB VM is based.
    Without this software the challenge-response / HOTP mechanism won't work.
 
+
    **YubiKey**
 
+
    For Fedora.
 
     ```
@@ -173,8 +175,10 @@ Note that setting up both a YubiKey and a NitroKey3 is not supported.
    
    **NitroKey3**
 
+
    Follow the installation instructions on the official [NitroKey 
 website](https://docs.nitrokey.com/software/nitropy/all-platforms/installation).
+
    
    **WARNING**: *as of April 2024 the official instructions involve using pipx to
             install the pynitrokey package and its dependencies without any GPG
@@ -184,29 +188,34 @@ website](https://docs.nitrokey.com/software/nitropy/all-platforms/installation).
             Proper packaging and distribution for Debian and perhaps Fedora is
             also planned for the mid-long term.*
             **Installing packages using pip or pipx is not recommended!**
-   
+
+
    **both**
 
+
    Shut down your template. Then, either reboot your USB VM (so changes inside
    the template take effect in your USB app qube) or install the packages inside
    your USB VM as well if you would like to avoid rebooting it.
 
-2. Install [qubes-app-yubikey](https://github.com/QubesOS/qubes-app-yubikey) in
+1. Install [qubes-app-yubikey](https://github.com/QubesOS/qubes-app-yubikey) in
    dom0. This provides the program to authenticate with password and YubiKey / NitroKey3.
 
     ```
     sudo qubes-dom0-update qubes-yubikey-dom0
     ```
 
-3. Configure your YubiKey / NitroKey3:
+2. Configure your YubiKey / NitroKey3:
+
    
    **YubiKey**
+
    
    Configure your YubiKey for challenge-response `HMAC-SHA1` mode. This can be
    done on any qube, e.g. a disposable (you need to [attach the
 YubiKey](https://www.qubes-os.org/doc/how-to-use-usb-devices/) to this app qube
 though) or directly on the sys-usb vm.
 
+
    You need to (temporarily) install the package "yubikey-personalization-gui" and
    run it by typing `yubikey-personalization-gui` in the command line.
 
@@ -221,6 +230,7 @@ though) or directly on the sys-usb vm.
 
    **NitroKey3**
 
+
    Set up a new NK3 Secrets App HOTP secret by attaching the NitroKey to your
    USB qube and running the following commands in it:
    ```
@@ -231,8 +241,10 @@ though) or directly on the sys-usb vm.
    e.g. letters, numbers, punctuation marks. The actual `Secret Key (base 32)`
    is the base32 encoded form of that sequence.
 
+
    **both**
 
+
    We will call the `Secret Key (20 bytes hex)` (YubiKey) or `Secret Key (base 32)` `AESKEY`.
 
    - It is recommended to keep a backup of your `AESKEY` in an offline VM used as a vault.
@@ -248,25 +260,30 @@ of this method. If you want to switch to a different NitroKey later, delete the
 Do the same if for some reason your counters get desynchronized (it stops working), e.g. due
 to connectivity issues (NitroKey3A Minis are known to wear out quickly).
 
-4. **YubiKey**
+3. **YubiKey**
+
 
    Paste your `AESKEY` into `/etc/qubes/yk-keys/yk-secret-key.hex` in dom0.
    Note that if you had previously used a NitroKey3 with this package, you *must* delete
    the file `/etc/qubes/yk-keys/nk-hotp-secret` or its content!
 
+
    **NitroKey3**
 
+
    Create the file `/etc/qubes/yk-keys/nk-hotp-secret` in dom0 and paste your `AESKEY` 
    (in base 32 format) into it.
 
-5. As mentioned before, you need to define a new password that is only used in
+4. As mentioned before, you need to define a new password that is only used in
    combination with the YubiKey / NitroKey3. You can write this password in plain text into
 `/etc/qubes/yk-keys/login-pass` in dom0. This is considered safe as dom0 is
 ultimately trusted anyway.
 
+
     However, if you prefer you can paste a hashed password instead into
 `/etc/qubes/yk-keys/login-pass-hashed.hex` in dom0.
 
+
     You can calculate your hashed password using the following two commands.
     First run the following command to store your password in a temporary variable `password`.
     (This way your password will not leak to the terminal command history file.)
@@ -281,7 +298,7 @@ ultimately trusted anyway.
     echo -n "$password" | openssl dgst -sha1 | cut -f2 -d ' '
     ```
 
-6. To enable multi-factor authentication for a service, you need to add
+5. To enable multi-factor authentication for a service, you need to add
 
     ```
     auth include yubikey
@@ -297,7 +314,7 @@ display manager and so on.
     It is important, that `auth include yubikey` is added at the beginning of
 these files, otherwise it will most likely not work.
 
-7. Adjust the USB VM name in case you are using something other than the default
+6. Adjust the USB VM name in case you are using something other than the default
    `sys-usb` by editing `/etc/qubes/yk-keys/vm` in dom0.
 
 #### Usage
@@ -353,7 +370,7 @@ In dom0:
 
 In your USB VM:
 
-3. Create udev hook.
+1. Create udev hook.
    Store it in `/rw/config` to have it persist across VM restarts.
    For example name the file `/rw/config/yubikey.rules`.
    Add the following line:
@@ -362,7 +379,7 @@ In your USB VM:
    ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SECURITY_TOKEN}=="1", RUN+="/usr/bin/qrexec-client-vm dom0 custom.LockScreen"
    ```
 
-4. Ensure that the udev hook is placed in the right place after VM restart.
+2. Ensure that the udev hook is placed in the right place after VM restart.
    Append to `/rw/config/rc.local`:
 
    ```
@@ -370,13 +387,13 @@ In your USB VM:
    udevadm control --reload
    ```
 
-5. Then make `/rw/config/rc.local` executable.
+3. Then make `/rw/config/rc.local` executable.
 
    ```
    sudo chmod +x /rw/config/rc.local
    ```
 
-6. For changes to take effect, you need to call this script manually for the first time.
+4. For changes to take effect, you need to call this script manually for the first time.
 
    ```
    sudo /rw/config/rc.local

From 13b46e5c0c891c37370871f159d6ca3cdaa153c4 Mon Sep 17 00:00:00 2001
From: ooops <kennethrrosen@proton.me>
Date: Mon, 8 Jul 2024 15:11:44 -0400
Subject: [PATCH 168/332] Update split-gpg.md

---
 user/security-in-qubes/split-gpg.md | 37 ++++++++---------------------
 1 file changed, 10 insertions(+), 27 deletions(-)

diff --git a/user/security-in-qubes/split-gpg.md b/user/security-in-qubes/split-gpg.md
index 637b068f..b1c93963 100644
--- a/user/security-in-qubes/split-gpg.md
+++ b/user/security-in-qubes/split-gpg.md
@@ -42,24 +42,24 @@ This way it would be easy to spot unexpected requests to decrypt documents.
 
 ## Configuring Split GPG
 
-In dom0, make sure the `qubes-gpg-split-dom0` package is installed.
+In dom0, make sure the `split-gpg2-dom0` package is installed.
 
 ```
-[user@dom0 ~]$ sudo qubes-dom0-update qubes-gpg-split-dom0
+[user@dom0 ~]$ sudo qubes-dom0-update split-gpg2-dom0
 ```
 
-Make sure you have the `qubes-gpg-split` package installed in the template you will use for the GPG domain.
+Make sure you have the `split-gpg2` package installed in the template you will use for the GPG domain.
 
 For Debian or Whonix:
 
 ```
-[user@debian-10 ~]$ sudo apt install qubes-gpg-split
+[user@debian ~]$ sudo apt install split-gpg2
 ```
 
 For Fedora:
 
 ```
-[user@fedora-32 ~]$ sudo dnf install qubes-gpg-split
+[user@fedora ~]$ sudo dnf install split-gpg2
 ```
 
 ### Setting up the GPG backend domain
@@ -91,9 +91,7 @@ You can override it e.g. in `~/.profile`:
 [user@work-gpg ~]$ echo "export QUBES_GPG_AUTOACCEPT=86400" >> ~/.profile
 ```
 
-Please note that previously, this parameter was set in ~/.bash_profile.
-This will no longer work.
-If you have the parameter set in ~/.bash_profile you *must* update your configuration.
+Please note that previously, this parameter was set in ~/.bash_profile. This will no longer work. If you have the parameter set in ~/.bash_profile you *must* update your configuration.
 
 Please be aware of the caveat regarding passphrase-protected keys in the [Current limitations](#current-limitations) section.
 
@@ -118,11 +116,6 @@ ssb   4096R/30498E2A 2012-11-15
 
 Note that running normal `gpg -K` in the demo above shows no private keys stored in this app qube.
 
-A note on `gpg` and `gpg2`:
-
-Throughout this guide, we refer to `gpg`, but note that Split GPG uses `gpg2` under the hood for compatibility with programs like Enigmail (which now supports only `gpg2`).
-If you encounter trouble while trying to set up Split GPG, make sure you're using `gpg2` for your configuration and testing, since keyring data may differ between the two installations.
-
 ### Advanced Configuration
 
 The `qubes-gpg-client-wrapper` script sets the `QUBES_GPG_DOMAIN` variable automatically based on the content of the file `/rw/config/gpg-split-domain`, which should be set to the name of the GPG backend VM. This file survives the app qube reboot, of course.
@@ -132,21 +125,15 @@ The `qubes-gpg-client-wrapper` script sets the `QUBES_GPG_DOMAIN` variable autom
 [root@work-email ~]$ echo "work-gpg" > /rw/config/gpg-split-domain
 ```
 
-Split GPG's default qrexec policy requires the user to enter the name of the app qube containing GPG keys on each invocation. To improve usability for applications like Thunderbird with Enigmail, in `dom0` place the following line at the top of the file `/etc/qubes-rpc/policy/qubes.Gpg`:
+Split GPG's default qrexec policy requires the user to enter the name of the app qube containing GPG keys on each invocation. To improve usability for applications like Thunderbird with Enigmail, in `dom0` you can make additional changes to `/etc/qubes-rpc/policy.d/50-config-splitgpg.policy` or by using the CLI or GUI:
 
 ```
-work-email  work-gpg  allow
+sudo qubes-policy-editor
+sudo qubes-policy-editor-gui
 ```
 
-where `work-email` is the Thunderbird + Enigmail app qube and `work-gpg` contains your GPG keys.
+Documentation for syntax examples is included within the GUI. Note that, because this makes it easier to accept Split GPG's qrexec authorization prompts, it may decrease security if the user is not careful in reviewing presented prompts. This may also be inadvisable if there are multiple app qubes with Split GPG set up. 
 
-You may also edit the qrexec policy file for Split GPG in order to tell Qubes your default gpg vm (qrexec prompts will appear with the gpg vm preselected as the target, instead of the user needing to type a name in manually). To do this, append `default_target=<vmname>` to `ask` in `/etc/qubes-rpc/policy/qubes.Gpg`. For the examples given on this page:
-
-```
-@anyvm  @anyvm  ask default_target=work-gpg
-```
-
-Note that, because this makes it easier to accept Split GPG's qrexec authorization prompts, it may decrease security if the user is not careful in reviewing presented prompts. This may also be inadvisable if there are multiple app qubes with Split GPG set up.
 
 ## Using Thunderbird
 
@@ -378,10 +365,6 @@ As always, exercise caution and use your good judgment.)
 
 ## Current limitations
 
-* Current implementation requires importing of public keys to the vault domain.
-  This opens up an avenue to attack the gpg running in the backend domain via a hypothetical bug in public key importing code.
-  See ticket [#474](https://github.com/QubesOS/qubes-issues/issues/474) for more details and plans how to get around this problem, as well as the section on [using Split GPG with subkeys](#advanced-using-split-gpg-with-subkeys).
-
 * It doesn't solve the problem of allowing the user to know what is to be signed before the operation gets approved.
   Perhaps the GPG backend domain could start a disposable and have the to-be-signed document displayed there? To Be Determined.
 

From 2d5c636c05b1a8fd78eaaab59ea76307bc919b47 Mon Sep 17 00:00:00 2001
From: ooops <kennethrrosen@proton.me>
Date: Mon, 8 Jul 2024 15:33:48 -0400
Subject: [PATCH 169/332] Includes updated documentation from split-gpg2

Fixes QubesOS/qubes-issues/issues/9138
---
 user/security-in-qubes/split-gpg.md | 365 ++++++----------------------
 1 file changed, 73 insertions(+), 292 deletions(-)

diff --git a/user/security-in-qubes/split-gpg.md b/user/security-in-qubes/split-gpg.md
index b1c93963..f31d1552 100644
--- a/user/security-in-qubes/split-gpg.md
+++ b/user/security-in-qubes/split-gpg.md
@@ -37,342 +37,123 @@ Unfortunately this problem of signing reliability is not solvable by Split GPG.)
 With Qubes Split GPG this problem is drastically minimized, because each time the key is to be used the user is asked for consent (with a definable time out, 5 minutes by default), plus is always notified each time the key is used via a tray notification from the domain where GPG backend is running.
 This way it would be easy to spot unexpected requests to decrypt documents.
 
-[![r2-split-gpg-1.png](/attachment/doc/r2-split-gpg-1.png)](/attachment/doc/r2-split-gpg-1.png)
-[![r2-split-gpg-3.png](/attachment/doc/r2-split-gpg-3.png)](/attachment/doc/r2-split-gpg-3.png)
+## Configuration
 
-## Configuring Split GPG
-
-In dom0, make sure the `split-gpg2-dom0` package is installed.
+Create/Edit `/etc/qubes/policy.d/30-user-gpg2.policy` in dom0, and add a line like this:
 
 ```
-[user@dom0 ~]$ sudo qubes-dom0-update split-gpg2-dom0
+qubes.Gpg2 + gpg-client-vm @default allow target=gpg-server-vm
 ```
 
-Make sure you have the `split-gpg2` package installed in the template you will use for the GPG domain.
-
-For Debian or Whonix:
+Import/Generate your secret keys in the server domain.
+For example:
 
 ```
-[user@debian ~]$ sudo apt install split-gpg2
+gpg-server-vm$ gpg --import /path/to/my/secret-keys-export
+gpg-server-vm$ gpg --import-ownertrust /path/to/my/ownertrust-export
 ```
-
-For Fedora:
+or
 
 ```
-[user@fedora ~]$ sudo dnf install split-gpg2
+gpg-server-vm$ gpg --gen-key
 ```
 
-### Setting up the GPG backend domain
+In dom0 enable the `split-gpg2-client` service in the client domain, for example via the command-line:
 
-First, create a dedicated app qube for storing your keys (we will be calling it the GPG backend domain).
-It is recommended that this domain be network disconnected (set its netvm to `none`) and only used for this one purpose.
-In later examples this app qube is named `work-gpg`, but of course it might have any other name.
-
-Make sure that gpg is installed there.
-At this stage you can add the private keys you want to store there, or you can now set up Split GPG and add the keys later.
-To check which private keys are in your GPG keyring, use:
-
-```shell_session
-[user@work-gpg ~]$ gpg -K
-/home/user/.gnupg/secring.gpg
------------------------------
-sec   4096R/3F48CB21 2012-11-15
-uid                  Qubes OS Security Team <security@qubes-os.org>
-ssb   4096R/30498E2A 2012-11-15
-(...)
+```shell
+dom0$ qvm-service <SPLIT_GPG2_CLIENT_DOMAIN_NAME> split-gpg2-client on
 ```
 
-This is pretty much all that is required.
-However, you might want to modify the default timeout: this tells the backend for how long the user's approval for key access should be valid.
-(The default is 5 minutes.) You can change this via the `QUBES_GPG_AUTOACCEPT` environment variable.
-You can override it e.g. in `~/.profile`:
+To verify if this was done correctly:
 
-```shell_session
-[user@work-gpg ~]$ echo "export QUBES_GPG_AUTOACCEPT=86400" >> ~/.profile
+```shell
+dom0$ qvm-service <SPLIT_GPG2_CLIENT_DOMAIN_NAME>
 ```
 
-Please note that previously, this parameter was set in ~/.bash_profile. This will no longer work. If you have the parameter set in ~/.bash_profile you *must* update your configuration.
+Output should be:
 
-Please be aware of the caveat regarding passphrase-protected keys in the [Current limitations](#current-limitations) section.
-
-### Configuring the client apps to use Split GPG backend
-
-Normally it should be enough to set the `QUBES_GPG_DOMAIN` to the GPG backend domain name and use `qubes-gpg-client` in place of `gpg`, e.g.:
-
-```shell_session
-[user@work-email ~]$ export QUBES_GPG_DOMAIN=work-gpg
-[user@work-email ~]$ gpg -K
-[user@work-email ~]$ qubes-gpg-client -K
-/home/user/.gnupg/secring.gpg
------------------------------
-sec   4096R/3F48CB21 2012-11-15
-uid                  Qubes OS Security Team <security@qubes-os.org>
-ssb   4096R/30498E2A 2012-11-15
-(...)
-
-[user@work-email ~]$ qubes-gpg-client secret_message.txt.asc
-(...)
+```shell
+split-gpg2-client on
 ```
 
-Note that running normal `gpg -K` in the demo above shows no private keys stored in this app qube.
+Restart the client domain.
 
-### Advanced Configuration
-
-The `qubes-gpg-client-wrapper` script sets the `QUBES_GPG_DOMAIN` variable automatically based on the content of the file `/rw/config/gpg-split-domain`, which should be set to the name of the GPG backend VM. This file survives the app qube reboot, of course.
-
-```shell_session
-[user@work-email ~]$ sudo bash
-[root@work-email ~]$ echo "work-gpg" > /rw/config/gpg-split-domain
-```
-
-Split GPG's default qrexec policy requires the user to enter the name of the app qube containing GPG keys on each invocation. To improve usability for applications like Thunderbird with Enigmail, in `dom0` you can make additional changes to `/etc/qubes-rpc/policy.d/50-config-splitgpg.policy` or by using the CLI or GUI:
+Export the **public** part of your keys and import them in the client domain.
+Also import/set proper "ownertrust" values.
+For example:
 
 ```
-sudo qubes-policy-editor
-sudo qubes-policy-editor-gui
+gpg-server-vm$ gpg --export > public-keys-export
+gpg-server-vm$ gpg --export-ownertrust > ownertrust-export
+gpg-server-vm$ qvm-copy public-keys-export ownertrust-export
+
+gpg-client-vm$ gpg --import ~/QubesIncoming/gpg-server-vm/public-keys-export
+gpg-client-vm$ gpg --import-ownertrust ~/QubesIncoming/gpg-server-vm/ownertrust-export
 ```
 
-Documentation for syntax examples is included within the GUI. Note that, because this makes it easier to accept Split GPG's qrexec authorization prompts, it may decrease security if the user is not careful in reviewing presented prompts. This may also be inadvisable if there are multiple app qubes with Split GPG set up. 
-
-
-## Using Thunderbird
-
-### Thunderbird 78 and higher
-
-Starting with version 78, Thunderbird has a built-in PGP feature and no longer requires the Enigmail extension. For users coming from the Enigmail extension, the built-in functionality is more limited currently, including that **public keys must live in your `work-email` qube with Thunderbird rather than your offline `work-gpg` qube**.
-
-In `work-email`, use the Thunderbird config editor (found at the bottom of preferences/options), and search for `mail.openpgp.allow_external_gnupg`. Switch the value to true. Still in config editor, search for `mail.openpgp.alternative_gpg_path`. Set its value to `/usr/bin/qubes-gpg-client-wrapper`. Restart Thunderbird after this change.
-
-[![tb78-1.png](/attachment/doc/tb78-1.png)](/attachment/doc/tb78-1.png)
-[![tb78-2.png](/attachment/doc/tb78-2.png)](/attachment/doc/tb78-2.png)
-[![tb78-3.png](/attachment/doc/tb78-3.png)](/attachment/doc/tb78-3.png)
-
-You need to obtain your key ID which should be **exactly 16 characters**. Enter the command `qubes-gpg-client-wrapper -K --keyid-format long`:
-
+This should be enough to have it running:
 ```
-[user@work-email ~]$ qubes-gpg-client-wrapper -K --keyid-format long
+gpg-client-vm$ gpg -K
 /home/user/.gnupg/pubring.kbx
 -----------------------------
-sec   rsa2048/777402E6D301615C 2020-09-05 [SC] [expires: 2022-09-05]
-      F7D2D4E922DFB7B2589AF3E9777402E6D301615C
-uid                 [ultimate] Qubes test <user@localhost>
-ssb   rsa2048/370CE932085BA13B 2020-09-05 [E] [expires: 2022-09-05]
+sec#  rsa2048 2019-12-18 [SC] [expires: 2021-12-17]
+      50C2035AF57B98CD6E4010F1B808E4BB07BA9EFB
+uid           [ultimate] test
+ssb#  rsa2048 2019-12-18 [E]
 ```
 
-```
-[user@work-email ~]$ qubes-gpg-client-wrapper --armor --export 777402E6D301615C > 777402E6D301615C.asc
-```
+If you want change some server option copy `/usr/share/doc/split-gpg2/examples/qubes-split-gpg2.conf.example` to `~/.config/qubes-split-gpg2/qubes-split-gpg2.conf` and change it as desired, it will take precedence over other loaded files, such as the drop-in configuration files with the suffix `.conf` in `~/.config/qubes-split-gpg2/conf.d/`.
 
-Open the Account Settings and open the *End-to-End Encryption* tab of the respective email account. Click the *Add Key* button. You'll be offered the choice *Use your external key through GnuPG*. Select it and click Continue.
+If you have a passphrase on your keys and `gpg-agent` only shows the "keygrip" (something like the fingerprint of the private key) when asking for the passphrase, then make sure that you have imported the public key part in the server domain.
 
-[![tb78-4.png](/attachment/doc/tb78-4.png)](/attachment/doc/tb78-4.png)
-[![tb78-5.png](/attachment/doc/tb78-5.png)](/attachment/doc/tb78-5.png)
+## Subkeys vs primary keys
 
-The key ID reference you would need here is `777402E6D301615C`. Now paste or type the ID of the secret key that you would like to use. Be careful to enter it correctly, because your input isn't verified. Confirm to save this key ID. Now you can select the key ID to use.
+split-gpg2 only knows a hash of the data being signed.
+Therefore, it cannot differentiate between e.g. signatures of a piece of data or signatures of another key.
+This means that a client can use split-gpg2 to sign other keys, which split-gpg1 did not allow.
 
-[![tb78-6.png](/attachment/doc/tb78-6.png)](/attachment/doc/tb78-6.png)
-[![tb78-7.png](/attachment/doc/tb78-7.png)](/attachment/doc/tb78-7.png)
+To prevent this, split-gpg2 creates a new GnuPG home directory and imports the secret subkeys (**not** the primary key!) to it.
+Clients will be able to use the secret parts of the subkeys, but not of the primary key.
+If your primary key is able to sign data and certify other keys, and your only subkey can only perform encryption, this means that all signing will fail.
+To make signing work again, generate a subkey that is capable of signing but **not** certification.
+split-gpg2 does not generate this key for you, so you need to generate it yourself.
+If you want to generate a key in software, use the `addkey` command of `gpg2 --edit-key`.
+If you want to generate a key on a smartcard or other hardware token, use `addcardkey` instead.
 
-This key ID will be used to digitally sign or send an encrypted message with your account. For this to work, Thunderbird needs a copy of your public key. At this time, Thunderbird doesn't fetch the public key from `/usr/bin/qubes-gpg-client-wrapper`, you must manually import it. Export the key as follow (assuming the key ID would be `777402E6D301615C`):
+## Advanced usage
 
-[![tb78-8.png](/attachment/doc/tb78-8.png)](/attachment/doc/tb78-8.png)
-[![tb78-9.png](/attachment/doc/tb78-9.png)](/attachment/doc/tb78-9.png)
+There are a few option not described in this README.
+See the comments in the example (config and the source code)[https://github.com/QubesOS/qubes-app-linux-split-gpg2/blob/main/qubes-split-gpg2.conf.example].
 
-Use Thunderbird's Tools menu to open *OpenPGP Key Management*. In that window, use the File menu to access the *Import Public Key(s) From File* command. Open the file with your public key. After the import was successful, right click on the imported key in the list and select *Key Properties*. You must mark your own key as *Yes, I've verified in person this key has the correct fingerprint*.
+Similar to a smartcard, split-gpg2 only tries to protect the private key.
+For advanced usages, consider if a specialized RPC service would be better.
+It could do things like checking what data is singed, detailed logging, exposing the encrypted content only to a VM without network, etc.
 
-Once this is done, you should be able to send an encrypted and signed email by selecting *Require Encryption* or *Digitally Sign This Message* in the compose menu *Options* or *Security* toolbar button. You can try it by sending an email to yourself.
+Using split-gpg2 as the "backend" for split-gpg1 is known to work.
 
-[![tb78-10.png](/attachment/doc/tb78-10.png)](/attachment/doc/tb78-10.png)
+## Allow key generation
 
-For more details about using smart cards/Split GPG with Thunderbird PGP feature, please see [Thunderbird:OpenPGP:Smartcards](https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards) from which the above documentation is inspired.
+By setting `allow_keygen = yes` in `qubes-split-gpg2.conf` you can allow the client to generate new keys.
+Normal usage should not need this.
 
-### Older Thunderbird versions
+**Warning**: This feature is new and not much tested.
+Therefore it's not security supported!
 
-For Thunderbird versions below 78, the traditional Enigmail + Split GPG setup is required.
-It is recommended to set up and use `/usr/bin/qubes-gpg-client-wrapper`, as discussed above, in Thunderbird through the Enigmail addon.
+## Copyright
 
-**Warning:** Before adding any account, configuring Enigmail with `/usr/bin/qubes-gpg-client-wrapper` is **required**. By default, Enigmail will generate a default GPG key in `work-email` associated with the newly created Thunderbird account. Generally, it corresponds to the email used in `work-gpg` associated to your private key. In consequence, a new, separate private key will be stored in `work-email` but it _does not_ correspond to your private key in `work-gpg`. Comparing the `fingerprint` or `expiration date` will show that they are not the same private key. In order to prevent Enigmail using this default generated local key in `work-email`, you can safely remove it.
+Copyright (C) 2014 HW42 <hw42@ipsumj.de>\
+Copyright (C) 2019 Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
 
-On a fresh Enigmail install, your need to change the default `Enigmail Junior Mode`. Go to Thunderbird preferences and then privacy tab. Select `Force using S/MIME and Enigmail`. Then, in the preferences of Enigmail, make it point to `/usr/bin/qubes-gpg-client-wrapper` instead of the standard GnuPG binary:
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
 
-[![tb-enigmail-split-gpg-settings-2.png](/attachment/doc/tb-enigmail-split-gpg-settings-2.png)](/attachment/doc/tb-enigmail-split-gpg-settings-2.png)
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
 
-## Using Keybase with Split GPG
-
-Keybase, a security focused messaging and file-sharing app with GPG integration, can be configured to use Split GPG.
-
-The Keybase service does not preserve/pass the `QUBES_GPG_DOMAIN` environment variable through to underlying GPG processes, so it **must** be configured to use `/usr/bin/qubes-gpg-client-wrapper` (as discussed above) rather than `/usr/bin/qubes-gpg-client`.
-
-The following command will configure Keybase to use `/usr/bin/qubes-gpg-client-wrapper` instead of its built-in GPG client:
-
-```
-$ keybase config set gpg.command /usr/bin/qubes-gpg-client-wrapper
-```
-
-Now that Keybase is configured to use `qubes-gpg-client-wrapper`, you will be able to use `keybase pgp select` to choose a GPG key from your backend GPG app qube and link that key to your Keybase identity.
-
-## Using Git with Split GPG
-
-Git can be configured to utilize Split GPG, something useful if you would like to contribute to the Qubes OS Project as every commit is required to be signed.
-The most basic `~/.gitconfig` file enabling Split GPG looks something like this.
-
-```
-[user]
-	name = <YOUR_NAME>
-	email = <YOUR_EMAIL_ADDRESS>
-	signingKey = <YOUR_KEY_ID>
-
-[gpg]
-	program = qubes-gpg-client-wrapper
-```
-
-Your key id is the public id of your signing key, which can be found by running `qubes-gpg-client --list-keys`.
-In this instance, the key id is E142F75A6B1B610E0E8F874FB45589245791CACB.
-
-```shell_session
-[user@work-email ~]$ qubes-gpg-client --list-keys
-/home/user/.gnupg/pubring.kbx
------------------------------
-pub   ed25519 2022-08-16 [C]
-      E142F75A6B1B610E0E8F874FB45589245791CACB
-uid           [ultimate] Qubes User <user@example.com>
-sub   ed25519 2022-08-16 [S]
-sub   cv25519 2022-08-16 [E]
-sub   ed25519 2022-08-16 [A]
-```
-
-To sign commits, you now add the "-S" flag to your commit command, which should prompt for Split GPG usage.
-If you would like to automatically sign all commits, you can add the following snippet to `~/.gitconfig`.
-
-```
-[commit]
-	gpgSign = true
-```
-
-Lastly, if you would like to add aliases to sign and verify tags using the conventions the Qubes OS Project recommends, refer to the [code signing documentation](/doc/code-signing/#using-pgp-with-git).
-
-## Importing public keys
-
-Use `qubes-gpg-import-key` in the client app qube to import the key into the GPG backend VM.
-
-```shell_session
-[user@work-email ~]$ export QUBES_GPG_DOMAIN=work-gpg
-[user@work-email ~]$ qubes-gpg-import-key ~/Downloads/marmarek.asc
-```
-
-A safe, unspoofable user consent dialog box is displayed.
-
-[![r2-split-gpg-5.png](/attachment/doc/r2-split-gpg-5.png)](/attachment/doc/r2-split-gpg-5.png)
-
-Selecting "Yes to All" will add a line in the corresponding [RPC Policy](/doc/rpc-policy/) file.
-
-## Advanced: Using Split GPG with Subkeys
-
-Users with particularly high security requirements may wish to use Split GPG with [subkeys](https://wiki.debian.org/Subkeys).
-However, this setup comes at a significant cost: It will be impossible to sign other people's keys with the master secret key without breaking this security model.
-Nonetheless, if signing others' keys is not required, then Split GPG with subkeys offers unparalleled security for one's master secret key.
-
-### Setup Description
-
-In this example, the following keys are stored in the following locations (see below for definitions of these terms):
-
-| PGP Key(s) | VM Name      |
-| ---------- | ------------ |
-| `sec`      | `vault`      |
-| `ssb`      | `work-gpg`   |
-| `pub`      | `work-email` |
-
-* `sec` (master secret key)
-
-   Depending on your needs, you may wish to create this as a **certify-only (C)** key, i.e., a key which is capable only of signing (a.k.a., "certifying") other keys.
-   This key may be created *without* an expiration date.
-   This is for two reasons.
-   First, the master secret key is never to leave the `vault` VM, so it is extremely unlikely ever to be obtained by an adversary (see below).
-   Second, an adversary who *does* manage to obtain the master secret key either possesses the passphrase to unlock the key (if one is used) or does not.
-   An adversary who *does* possess the passphrase can simply use it to legally extend the expiration date of the key (or remove it entirely).
-   An adversary who does *not* possess the passphrase cannot use the key at all.
-   In either case, an expiration date provides no additional benefit.
-
-   By the same token, however, having a passphrase on the key is of little value.
-   An adversary who is capable of stealing the key from your `vault` would almost certainly also be capable of stealing the passphrase as you enter it.
-   An adversary who obtains the passphrase can then use it in order to change or remove the passphrase from the key.
-   Therefore, using a passphrase at all should be considered optional.
-   It is, however, recommended that a **revocation certificate** be created and safely stored in multiple locations so that the master keypair can be revoked in the (exceedingly unlikely) event that it is ever compromised.
-
-* `ssb` (secret subkey)
-
-   Depending on your needs, you may wish to create two different subkeys: one for **signing (S)** and one for **encryption (E)**.
-   You may also wish to give these subkeys reasonable expiration dates (e.g., one year).
-   Once these keys expire, it is up to you whether to *renew* these keys by extending the expiration dates or to create *new* subkeys when the existing set expires.
-
-   On the one hand, an adversary who obtains any existing encryption subkey (for example) will be able to use it in order to decrypt all emails (for example) which were encrypted to that subkey.
-   If the same subkey were to continue to be used--and its expiration date continually extended--only that one key would need to be stolen (e.g., as a result of the `work-gpg` VM being compromised; see below) in order to decrypt *all* of the user's emails.
-   If, on the other hand, each encryption subkey is used for at most approximately one year, then an adversary who obtains the secret subkey will be capable of decrypting at most approximately one year's worth of emails.
-
-   On the other hand, creating a new signing subkey each year without renewing (i.e., extending the expiration dates of) existing signing subkeys would mean that all of your old signatures would eventually read as "EXPIRED" whenever someone attempts to verify them.
-   This can be problematic, since there is no consensus on how expired signatures should be handled.
-   Generally, digital signatures are intended to last forever, so this is a strong reason against regularly retiring one's signing subkeys.
-
-* `pub` (public key)
-
-   This is the complement of the master secret key.
-   It can be uploaded to keyservers (or otherwise publicly distributed) and may be signed by others.
-
-* `vault`
-
-   This is a network-isolated VM.
-   The initial master keypair and subkeys are generated in this VM.
-   The master secret key *never* leaves this VM under *any* circumstances.
-   No files or text is *ever* [copied](/doc/how-to-copy-and-move-files/#security) or [pasted](/doc/how-to-copy-and-paste-text/#security) into this VM under *any* circumstances.
-
-* `work-gpg`
-
-   This is a network-isolated VM.
-   This VM is used *only* as the GPG backend for `work-email`.
-   The secret subkeys (but *not* the master secret key) are [copied](/doc/how-to-copy-and-move-files/#security) from the `vault` VM to this VM.
-   Files from less trusted VMs are *never* [copied](/doc/how-to-copy-and-move-files/#security) into this VM under *any* circumstances.
-
-* `work-email`
-
-   This VM has access to the mail server.
-   It accesses the `work-gpg` VM via the Split GPG protocol.
-   The public key may be stored in this VM so that it can be attached to emails and for other such purposes.
-
-### Security Benefits
-
-In the standard Split GPG setup, there are at least two ways in which the `work-gpg` VM might be compromised.
-First, an attacker who is capable of exploiting a hypothetical bug in `work-email`'s [MUA](https://en.wikipedia.org/wiki/Mail_user_agent) could gain control of the `work-email` VM and send a malformed request which exploits a hypothetical bug in the GPG backend (running in the `work-gpg` VM), giving the attacker control of the `work-gpg` VM.
-Second, a malicious public key file which is imported into the `work-gpg` VM might exploit a hypothetical bug in the GPG backend which is running there, again giving the attacker control of the `work-gpg` VM.
-In either case, such an attacker might then be able to leak both the master secret key and its passphrase (if any is used, it would regularly be input in the work-gpg VM and therefore easily obtained by an attacker who controls this VM) back to the `work-email` VM or to another VM (e.g., the `netvm`, which is always untrusted by default) via the Split GPG protocol or other [covert channels](/doc/data-leaks/).
-Once the master secret key is in the `work-email` VM, the attacker could simply email it to himself (or to the world).
-
-In the alternative setup described in this section (i.e., the subkey setup), even an attacker who manages to gain access to the `work-gpg` VM will not be able to obtain the user's master secret key since it is simply not there.
-Rather, the master secret key remains in the `vault` VM, which is extremely unlikely to be compromised, since nothing is ever copied or transferred into it.
-[^a-note] The attacker might nonetheless be able to leak the secret subkeys from the `work-gpg` VM in the manner described above, but even if this is successful, the secure master secret key can simply be used to revoke the compromised subkeys and to issue new subkeys in their place.
-(This is significantly less devastating than having to create a new *master* keypair.)
-
-[^a-note]: In order to gain access to the `vault` VM, the attacker would require the use of, e.g., a general Xen VM escape exploit or a [signed, compromised package which is already installed in the template](/doc/templates/#trusting-your-templates) upon which the `vault` VM is based.
-
-### Subkey Tutorials and Discussions
-
-(Note: Although the tutorials below were not written with Qubes Split GPG in mind, they can be adapted with a few commonsense adjustments.
-As always, exercise caution and use your good judgment.)
-
-* ["OpenPGP in Qubes OS" on the qubes-users mailing list](https://groups.google.com/d/topic/qubes-users/Kwfuern-R2U/discussion)
-* ["Creating the Perfect GPG Keypair" by Alex Cabal](https://alexcabal.com/creating-the-perfect-gpg-keypair/)
-* ["GPG Offline Master Key w/ smartcard" maintained by Abel Luck](https://gist.github.com/abeluck/3383449)
-* ["Using GnuPG with QubesOS" by Alex](https://apapadop.wordpress.com/2013/08/21/using-gnupg-with-qubesos/)
-
-## Current limitations
-
-* It doesn't solve the problem of allowing the user to know what is to be signed before the operation gets approved.
-  Perhaps the GPG backend domain could start a disposable and have the to-be-signed document displayed there? To Be Determined.
-
-* The Split GPG client will fail to sign or encrypt if the private key in the GnuPG backend is protected by a passphrase.
-  It will give an `Inappropriate ioctl for device` error.
-  Do not set passphrases for the private keys in the GPG backend domain.
-  Doing so won't provide any extra security anyway, as explained in the introduction and in [using Split GPG with subkeys](#advanced-using-split-gpg-with-subkeys).
-  If you are generating a new key pair, or if you have a private key that already has a passphrase, you can use `gpg2 --edit-key <key_id>` then `passwd` to set an empty passphrase.
-  Note that `pinentry` might show an error when you try to set an empty passphrase, but it will still make the change.
-  (See [this StackExchange answer](https://unix.stackexchange.com/a/379373) for more information.)
-  Note: The error shows only if you **do not** have graphical pinentry installed.
+You should have received a copy of the GNU General Public License along
+with this program; if not, write to the Free Software Foundation, Inc.,
+51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
\ No newline at end of file

From f7008ae73dc5b70246fa91073a3ce1e3b511b5a9 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Wed, 10 Jul 2024 13:40:07 +0000
Subject: [PATCH 170/332] qubes-builderv1 still support 4.2 builds - make clear
 in another notification

---
 developer/building/qubes-iso-building.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/developer/building/qubes-iso-building.md b/developer/building/qubes-iso-building.md
index a8d6cd57..7b131bed 100644
--- a/developer/building/qubes-iso-building.md
+++ b/developer/building/qubes-iso-building.md
@@ -15,7 +15,7 @@ title: Qubes ISO building
 <div class="alert alert-warning" role="alert">
   <i class="fa fa-exclamation-circle"></i>
   <b>Note:</b> These instructions concern the older Qubes builder (v1). It supports
-  only building Qubes 4.1 or earlier.<br>The build process has been completely rewritten in <a href="https://github.com/QubesOS/qubes-builderv2/">qubes-builder v2</a>. This can be used for building Qubes R4.1 and later, and all related components.
+  only building Qubes 4.2 or earlier.<br>The build process has been completely rewritten in <a href="https://github.com/QubesOS/qubes-builderv2/">qubes-builder v2</a>. This can be used for building Qubes R4.2 and later versions, and all related components.
 </div>
 
 Build Environment

From ec1f501c538d5775edb0d082581d58cc19f08d3b Mon Sep 17 00:00:00 2001
From: apparatius <151992958+apparatius@users.noreply.github.com>
Date: Fri, 12 Jul 2024 09:31:11 +0000
Subject: [PATCH 171/332] Update firewall.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The disappearance of the eth0 interface when you restart the net qube of the sys-firewall or set it’s net qube to none is causing `iif == "eth0"` to become `iif 2` and the rules won't work anymore.
It’s better to use `iifgroup 1` instead of `iif == "eth0"`.
Related discussion:
https://forum.qubes-os.org/t/iptables-not-available-in-sys-net-in-qubes-os-4-2-1/26706/26
---
 user/security-in-qubes/firewall.md | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index 95b28673..0fc9a2f8 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -297,13 +297,13 @@ nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority fi
 Second step, code a natting firewall rule to route traffic on the outside interface for the service to the sys-firewall VM
 
 ```
-nft add rule qubes custom-dnat-qubeDEST iif == "ens6" ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
+nft add rule qubes custom-dnat-qubeDEST iifgroup 1 ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
 ```
 
 Third step, code the appropriate new filtering firewall rule to allow new connections for the service
 
 ```
-nft add rule qubes custom-forward iif == "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
+nft add rule qubes custom-forward iifgroup 1 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
 ```
 
 > Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
@@ -320,12 +320,12 @@ In this example, we can see 7 packets in the forward rule, and 3 packets in the
 
 ```
 chain custom-forward {
-  iif "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter packets 7 bytes 448 accept
+  iifgroup 1 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter packets 7 bytes 448 accept
 }
 
 chain custom-dnat-qubeDEST {
   type nat hook prerouting priority filter + 1; policy accept;
-  iif "ens6" ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter packets 3 bytes 192 dnat to 10.138.33.59
+  iifgroup 1 ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter packets 3 bytes 192 dnat to 10.138.33.59
 }
 ```
 
@@ -351,10 +351,10 @@ Content of `/rw/config/qubes-firewall-user-script` in `sys-net`:
 if nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
 then
   # create the dnat rule
-  nft add rule qubes custom-dnat-qubeDEST iif == "ens6" saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
+  nft add rule qubes custom-dnat-qubeDEST iifgroup 1 saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
 
   # allow forwarded traffic
-  nft add rule qubes custom-forward iif == "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
+  nft add rule qubes custom-forward iifgroup 1 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
 fi
 ~~~
 
@@ -371,13 +371,13 @@ nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority fi
 Second step, code a natting firewall rule to route traffic on the outside interface for the service to the destination qube
 
 ```
-nft add rule qubes custom-dnat-qubeDEST iif == "eth0" ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.0.xx
+nft add rule qubes custom-dnat-qubeDEST iifgroup 1 ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.0.xx
 ```
 
 Third step, code the appropriate new filtering firewall rule to allow new connections for the service
 
 ```
-nft add rule qubes custom-forward iif == "eth0" ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
+nft add rule qubes custom-forward iifgroup 1 ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
 ```
 
 > Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
@@ -398,10 +398,10 @@ Content of `/rw/config/qubes-firewall-user-script` in `sys-firewall`:
 if nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
 then
   # create the dnat rule
-  nft add rule qubes custom-dnat-qubeDEST iif == "eth0" tcp dport 443 ct state new,established,related counter dnat 10.137.0.xx
+  nft add rule qubes custom-dnat-qubeDEST iifgroup 1 tcp dport 443 ct state new,established,related counter dnat 10.137.0.xx
 
   # allow forwarded traffic
-  nft add rule qubes custom-forward iif == "eth0" ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
+  nft add rule qubes custom-forward iifgroup 1 ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
 fi
 ~~~
 

From 44739f7a076cf8339362a7b59108ef0ce4e71b72 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Fri, 12 Jul 2024 15:14:17 +0000
Subject: [PATCH 172/332] Remove note on unsupported Debian version 10. Add
 note for Debian 12 to hold salt packages

---
 user/templates/debian/debian.md | 16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/user/templates/debian/debian.md b/user/templates/debian/debian.md
index 32ef26fb..9fa94cdf 100644
--- a/user/templates/debian/debian.md
+++ b/user/templates/debian/debian.md
@@ -58,19 +58,17 @@ There are two ways to upgrade your template to a new Debian release:
 
 This section contains notes about specific Debian releases.
 
-### Debian 10
+### Debian 12
 
-Debian 10 (buster) - minimal:
+If you want to use a Debian 12 template for salting Qubes, you **must** stop the salt-common and salt-ssh packages from being upgraded.
+Do this by marking these packages on hold *before* updating the template.
 
 ```
-[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-itl qubes-template-debian-10-minimal
-```
-
-Debian 10 (buster) - stable:
-
-```
-[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-itl qubes-template-debian-10
+sudo apt-mark hold salt-common salt-ssh
+sudo apt update
+sudo apt upgrade
 ```
+This is a [known bug](https://github.com/QubesOS/qubes-issues/issues/9129) in Salt which affects version 3006-5.
 
 ### Starting services
 

From 38ad896befe8ed40888c8fb8ba70bd55d1bc1d02 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Fri, 12 Jul 2024 15:42:08 -0700
Subject: [PATCH 173/332] Fix and clarify description

---
 developer/releases/4_2/release-notes.md | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/developer/releases/4_2/release-notes.md b/developer/releases/4_2/release-notes.md
index 13af20d9..0a191b8b 100644
--- a/developer/releases/4_2/release-notes.md
+++ b/developer/releases/4_2/release-notes.md
@@ -58,9 +58,15 @@ We strongly recommend [updating Qubes OS](/doc/how-to-update/) immediately after
   
   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.
+  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 a "deny" rule for `qubes.Filecopy+allow-all-names` before all other relevant rules. For more information, see [RPC policies](/doc/rpc-policy/) and [Qube configuration interface](/doc/vm-interface/#qubes-rpc).
+  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](/doc/rpc-policy/) and [Qube configuration interface](/doc/vm-interface/#qubes-rpc).
 
 ## Download
 

From 427acfb8a55374b38ecdd024c1d53d19b0ca771e Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Fri, 12 Jul 2024 15:58:17 -0700
Subject: [PATCH 174/332] Fix spacing

---
 developer/releases/4_2/release-notes.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/developer/releases/4_2/release-notes.md b/developer/releases/4_2/release-notes.md
index 0a191b8b..2590f55b 100644
--- a/developer/releases/4_2/release-notes.md
+++ b/developer/releases/4_2/release-notes.md
@@ -58,7 +58,7 @@ We strongly recommend [updating Qubes OS](/doc/how-to-update/) immediately after
   
   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.
+  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:
   

From 0527252737661d8cc20f6416fedead413db9e111 Mon Sep 17 00:00:00 2001
From: Piotr Bartman-Szwarc <prbartman@invisiblethingslab.com>
Date: Sun, 30 Jun 2024 11:08:07 +0200
Subject: [PATCH 175/332] updater: update docs

---
 user/how-to-guides/how-to-update.md | 23 ++++++++++-------------
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/user/how-to-guides/how-to-update.md b/user/how-to-guides/how-to-update.md
index 2462bafb..54c9bc2e 100644
--- a/user/how-to-guides/how-to-update.md
+++ b/user/how-to-guides/how-to-update.md
@@ -26,24 +26,26 @@ Security updates are an extremely important part of keeping your Qubes installat
 
 By default, the **Qubes Update** tool will appear as an icon in the Notification Area when updates are available.
 
-[![Qube Updates Available](/attachment/doc/r4.0-qube-updates-available.png)](/attachment/doc/r4.0-qube-updates-available.png)
+[![Qube Updates Available](/attachment/doc/r4.2-qube-updates-available.png)](/attachment/doc/r4.2-qube-updates-available.png)
 
-However, you can also start the tool manually by selecting it in the Applications Menu under "Qubes Tools." Even if no updates have been detected, you can use this tool to check for updates manually at any time by selecting "Enable updates for qubes without known available updates," then selecting all desired items from the list and clicking "Next."
+However, you can also start the tool manually by selecting it in the Applications Menu under "Qubes Tools." Even if no updates have been detected, you can use this tool to check for updates manually at any time by selecting all desired items from the list and clicking "Update".
 
 <div class="alert alert-info" role="alert">
   <i class="fa fa-question-circle"></i>
   For information about how templates download updates, please see <a href="/doc/how-to-install-software/#why-dont-templates-have-network-access">Why don't templates have network access?</a> and the <a href="/doc/how-to-install-software/#updates-proxy">Updates proxy</a>.
 </div>
 
-By default, most qubes that are connected to the internet will periodically check for updates for their parent templates. If updates are available, you will receive a notification as described above. However, if you have any templates that do *not* have any online child qubes, you will *not* receive update notifications for them. Therefore, you should regularly update such templates manually instead.
+By default, most qubes that are connected to the internet will periodically check for updates for their parent templates. You can check the date of the last update check in the "last checked" column. If updates are available for any qube, you will receive a notification as described above, and in the "Updates available" column you will see "YES" for that qube(s). If the update check did not find any new updates, "NO" will appear in the column. Respectively, for qubes that are no longer supported, "OBSOLETE" will be displayed. However, if you have any templates that do *not* have any online child qubes, you will *not* receive update notifications for them. By default, after a week, if updates for a given qube have not been checked, the value in the "Updates available" column will be set to "MAYBE". 
 
 ## Installing updates
 
 The standard way to install updates is with the **Qubes Update** tool. (However, you can also perform the same action via the [command-line interface](#command-line-interface).)
 
-[![Qubes Update](/attachment/doc/r4.0-software-update.png)](/attachment/doc/r4.0-software-update.png)
+[![Qubes Update](/attachment/doc/r4.2-software-update.png)](/attachment/doc/r4.2-software-update.png)
 
-Simply follow the on-screen instructions, and the tool will download and install all available updates for you. Note that if you are downloading updates over Tor (`sys-whonix`), this can take a very long time, especially if there are a lot of updates available.
+You can easily decide which qubes to update by clicking on the checkbox in the column header. At startup, only the qubes for which updates are known are selected for updating, but clicking on the mentioned checkbox will also select all qubes with the "MAYBE" status. It is recommended to update all qubes with the statuses "YES" and "MAYBE".
+
+Then simply follow the on-screen instructions, and the tool will download and install all available updates for you. Note that if you are downloading updates over Tor (`sys-whonix`), this can take a very long time, especially if there are a lot of updates available.
 
 ## Restarting after updating
 
@@ -53,7 +55,7 @@ Certain updates require certain components to be restarted in order for the upda
 - Dom0 should be restarted after all **Xen** and **kernel** updates.
 - On Intel systems, dom0 should be restarted after all `microcode_ctl` updates.
 - On AMD systems, dom0 should be restarted after all `linux-firmware` updates.
-- After updating a template, first shut down the template, then restart all running qubes based on that template.
+- After updating a template, first shut down the template, then restart all running qubes based on that template. The updater will try to do this for you automatically in the last step of updating. Remember to save all your data before restarting!
 
 ## AEM resealing after updating
 
@@ -63,15 +65,10 @@ If you use [Anti Evil Maid (AEM)](/doc/anti-evil-maid/), you'll have to "reseal"
 
 <div class="alert alert-danger" role="alert">
   <i class="fa fa-exclamation-triangle"></i>
-  <b>Warning:</b> Updating with direct commands such as <code>qubes-dom0-update</code>, <code>dnf update</code>, and <code>apt update</code> is <b>not</b> recommended, since these bypass built-in Qubes OS update security measures. Instead, we strongly recommend using the <b>Qubes Update</b> tool or its command-line equivalents, as described below. (By contrast, <a href="/doc/how-to-install-software/">installing</a> packages using direct package manager commands is fine.)
+  <b>Warning:</b> Updating with direct commands such as <code>dnf update</code>, and <code>apt update</code> is <b>not</b> recommended, since these bypass built-in Qubes OS update security measures. Instead, we strongly recommend using the <b>Qubes Update</b> tool or its command-line equivalents, as described below. (By contrast, <a href="/doc/how-to-install-software/">installing</a> packages using direct package manager commands is fine.)
 </div>
 
-Advanced users may wish to perform updates via the command-line interface. The recommended way to do this is by applying the following two Salt states. **Applying these two Salt states is the same as updating via the Qubes Update tool.**
-
- - [update.qubes-dom0](/doc/salt/#updatequbes-dom0)
- - [update.qubes-vm](/doc/salt/#updatequbes-vm)
-
-In your update qube, a terminal window opens that displays the progress of operations and output as it is logged. At the end of the process, logs are sent back to dom0. You answer any yes/no prompts in your dom0 terminal window.
+Advanced users may wish to perform updates via the command-line interface. To update templates and standalones non-interactively, use the command `qubes-vm-update`, and to update dom0, use `qubes-dom0-update`. If you want to perform a more complex update, see: [update.qubes-dom0](/doc/salt/#updatequbes-dom0) and [update.qubes-vm](/doc/salt/#updatequbes-vm).
 
 Advanced users may also be interested in learning [how to enable the testing repos](/doc/testing/).
 

From c37468fa11d6d8facc21c345015c37c55b887c83 Mon Sep 17 00:00:00 2001
From: Ali Mirjamali <ali@mirjamali.com>
Date: Tue, 23 Jul 2024 16:16:44 +0330
Subject: [PATCH 176/332] qvm-template should be used to remove templates

fixes: https://github.com/QubesOS/qubes-issues/issues/7525
---
 user/templates/templates.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/templates/templates.md b/user/templates/templates.md
index 2f7ac64a..d12e5585 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -170,7 +170,7 @@ installing a template package in dom0, per the instructions
 dom0 in order to uninstall it:
 
 ```
-$ sudo dnf remove qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>
+$ qvm-template remove qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>
 ```
 
 `qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>` is the name of the desired

From 71f066c3cbbd4a73ed9b3ae5d6196ac6e15fedd1 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Thu, 25 Jul 2024 13:47:27 +0000
Subject: [PATCH 177/332] Clarify that grub2-xen-pvh is required for in qube
 kernel booting under PVH (credit moonscape in Forum)

---
 user/advanced-topics/managing-vm-kernels.md | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/user/advanced-topics/managing-vm-kernels.md b/user/advanced-topics/managing-vm-kernels.md
index 7303a158..1dab8a44 100644
--- a/user/advanced-topics/managing-vm-kernels.md
+++ b/user/advanced-topics/managing-vm-kernels.md
@@ -279,7 +279,9 @@ Then shutdown the VM.
 
 * You may also use `PV` mode instead of `HVM` but this is not recommended for security purposes.
 * If you require `PV` mode, install `grub2-xen-pvh` in dom0 and change the template's kernel to `pvgrub2-pvh`.
-* Booting to a kernel inside the template is not supported under `PVH`.
+* If you require `PVH` mode, install `grub2-xen-pvh` in dom0 and change the kernel to `pvgrub2-pvh`.
+* To install `grub2-xen-pvh` run the command `sudo qubes-dom0-update pvgrub2-pvh` in dom0.
+
 
 ### Installing kernel in Debian VM
 
@@ -314,7 +316,7 @@ Depends on `Virtualization` mode setting:
 
 * `Virtualization` mode `PV`: Possible, however use of `Virtualization` mode `PV` mode is discouraged for security purposes.
   * If you require `Virtualization` mode `PV` mode, install `grub2-xen-pvh` in dom0. This can be done by running command `sudo qubes-dom0-update pvgrub2-pvh` in dom0.
-* `Virtualization` mode `PVH`: Possible.
+* `Virtualization` mode `PVH`: Possible. Install `grub2-xen-pvh` in dom0.
 * `Virtualization` mode `HVM`: Possible.
 
 The `Kernel` setting of the `Virtualization` mode setting:

From 4a14fb0f67a7b79a2ba7bf8b899daeff237d005f Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Thu, 25 Jul 2024 22:29:35 -0700
Subject: [PATCH 178/332] Add qubes-vm-update and new CLI update recommendation

QubesOS/qubes-issues#7443
---
 developer/releases/4_2/release-notes.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/developer/releases/4_2/release-notes.md b/developer/releases/4_2/release-notes.md
index 2590f55b..6377844b 100644
--- a/developer/releases/4_2/release-notes.md
+++ b/developer/releases/4_2/release-notes.md
@@ -16,6 +16,7 @@ permalink: /doc/releases/4.2/release-notes/
   - Qubes Global Settings ([#6898](https://github.com/QubesOS/qubes-issues/issues/6898))
   - Create New Qube
   - Qubes Update ([#7443](https://github.com/QubesOS/qubes-issues/issues/7443))
+- New `qubes-vm-update` tool ([#7443](https://github.com/QubesOS/qubes-issues/issues/7443))
 - Unified `grub.cfg` location for both UEFI and legacy boot ([#7985](https://github.com/QubesOS/qubes-issues/issues/7985))
 - PipeWire support ([#6358](https://github.com/QubesOS/qubes-issues/issues/6358))
 - fwupd integration for firmware updates ([#4855](https://github.com/QubesOS/qubes-issues/issues/4855))
@@ -68,6 +69,8 @@ We strongly recommend [updating Qubes OS](/doc/how-to-update/) immediately after
   
   For more information, see [RPC policies](/doc/rpc-policy/) and [Qube configuration interface](/doc/vm-interface/#qubes-rpc).
 
+- Beginning with Qubes 4.2, the recommended way to update Qubes OS via the command line has changed. Salt is no longer the preferred method, though it is still supported. Instead, `qubes-dom0-update` is recommended for updating dom0, and `qubes-vm-update` is recommended for updating templates and standalones. (The recommended way to update via the GUI has not changed. The Qubes Update tool is still the preferred method.) For more information, see [How to update](/doc/how-to-update/).
+
 ## Download
 
 All Qubes ISOs and associated [verification files](/security/verifying-signatures/) are available on the [downloads](/downloads/) page.

From d918c03853fb2a6422f11b2ec6206a03fd669d9d Mon Sep 17 00:00:00 2001
From: Piotr Bartman-Szwarc <prbartman@invisiblethingslab.com>
Date: Sat, 27 Jul 2024 09:42:30 +0200
Subject: [PATCH 179/332] @andrewdavidwong comment

---
 user/how-to-guides/how-to-update.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/how-to-guides/how-to-update.md b/user/how-to-guides/how-to-update.md
index 54c9bc2e..8e865234 100644
--- a/user/how-to-guides/how-to-update.md
+++ b/user/how-to-guides/how-to-update.md
@@ -68,7 +68,7 @@ If you use [Anti Evil Maid (AEM)](/doc/anti-evil-maid/), you'll have to "reseal"
   <b>Warning:</b> Updating with direct commands such as <code>dnf update</code>, and <code>apt update</code> is <b>not</b> recommended, since these bypass built-in Qubes OS update security measures. Instead, we strongly recommend using the <b>Qubes Update</b> tool or its command-line equivalents, as described below. (By contrast, <a href="/doc/how-to-install-software/">installing</a> packages using direct package manager commands is fine.)
 </div>
 
-Advanced users may wish to perform updates via the command-line interface. To update templates and standalones non-interactively, use the command `qubes-vm-update`, and to update dom0, use `qubes-dom0-update`. If you want to perform a more complex update, see: [update.qubes-dom0](/doc/salt/#updatequbes-dom0) and [update.qubes-vm](/doc/salt/#updatequbes-vm).
+Advanced users may wish to perform updates via the command-line interface. To update templates and standalones non-interactively, use the command `qubes-vm-update`, and to update dom0, use `qubes-dom0-update`. If you want to perform an update with more advanced user-configurable options (e.g., custom pre- or post-update scripts, custom workarounds), see: [update.qubes-dom0](/doc/salt/#updatequbes-dom0) and [update.qubes-vm](/doc/salt/#updatequbes-vm).
 
 Advanced users may also be interested in learning [how to enable the testing repos](/doc/testing/).
 

From 32c32e66592e39de198eb5677001e837f3f5d753 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sun, 28 Jul 2024 11:59:50 -0400
Subject: [PATCH 180/332] preparation rst conversion

---
 developer/code/code-signing.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/developer/code/code-signing.md b/developer/code/code-signing.md
index c94b9e1b..bb62453a 100644
--- a/developer/code/code-signing.md
+++ b/developer/code/code-signing.md
@@ -144,9 +144,11 @@ Although GitHub adds a little green `Verified` button next to the commit, the [s
 
 1. Is the commit signed?
    If the commit is not signed, you can see the message
+   
    > policy/qubesos/code-signing — No signature found
-2. If the commit is signed, the key is downloaded from a GPG key server.
+3. If the commit is signed, the key is downloaded from a GPG key server.
    If you can see the following error message, please check if you have uploaded the key to a key server.
+   
    > policy/qubesos/code-signing — Unable to verify (no valid key found)
 
 ### No Signature Found

From 0a94a1f35ec0866e4cc3e57b66c1834accc8e0f1 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sun, 28 Jul 2024 12:00:29 -0400
Subject: [PATCH 181/332] preparation rst conversion

---
 developer/code/source-code.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/developer/code/source-code.md b/developer/code/source-code.md
index 85e5cf13..83173e6c 100644
--- a/developer/code/source-code.md
+++ b/developer/code/source-code.md
@@ -60,6 +60,7 @@ method you choose, you must [sign your code](/doc/code-signing/) before it can b
 
 * **Preferred**: Use GitHub's [fork & pull requests](https://guides.github.com/activities/forking/).
 
+
    Opening a pull request on GitHub greatly eases the code review and tracking
    process. In addition, especially for bigger changes, it's a good idea to send
    a message to the [qubes-devel mailing list](/support/#qubes-devel) in order to notify people who

From 38cfff0ca29f4e5b237a4655a9cdabb14a86d423 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sun, 28 Jul 2024 12:03:07 -0400
Subject: [PATCH 182/332] preparation rst conversion

---
 developer/general/gsoc.md | 102 ++------------------------------------
 1 file changed, 5 insertions(+), 97 deletions(-)

diff --git a/developer/general/gsoc.md b/developer/general/gsoc.md
index e49d66d9..05ad3728 100644
--- a/developer/general/gsoc.md
+++ b/developer/general/gsoc.md
@@ -174,45 +174,6 @@ If applicable, links to more information or discussions
 
 **Mentor**: [Frédéric Pierret](/team/)
 
-<!--
-
-REMOVED as of February 2022: work is being done on this
-
-### Wayland support in GUI agent and/or GUI daemon
-
-**Project**: Wayland support in GUI agent and/or GUI daemon
-
-**Brief explanation**: Currently both GUI agent (VM side of the GUI virtualization) and GUI daemon (dom0 side of GUI virtualization) support X11 protocol only. It may be useful to add support for Wayland there. Note that those are in fact two independent projects:
-
-1. GUI agent - make it work as Wayland compositor, instead of extracting window's composition buffers using custom X11 driver
-2. GUI daemon - act as Wayland application, showing windows retrieved from VMs, keeping zero-copy display path (window content is directly mapped from application running in VM, not copied)
-
-**Expected results**:
-
-Choose either of GUI agent, GUI daemon. Both are of similar complexity and each separately looks like a good task for GSoC time period.
-
-- design relevant GUI agent/daemon changes, the GUI protocol should not be affected
-- consider window decoration handling - VM should have no way of spoofing those, so it must be enforced by GUI daemon (either client-side - by GUI daemon itself, or server-side, based on hints given by GUI daemon)
-- implement relevant GUI agent/daemon changes
-- implement tests for new GUI handling, similar to existing tests for X11 based GUI
-
-Relevant links:
-
-- [Low level GUI documentation](/doc/gui/)
-- [qubes-gui-agent-linux](https://github.com/qubesos/qubes-gui-agent-linux)
-- [qubes-gui-daemon](https://github.com/qubesos/qubes-gui-daemon)
-- [Use Wayland instead of X11 to increase performance](https://github.com/qubesos/qubes-issues/issues/3366)
-
-**Knowledge prerequisite**:
-
-- Wayland architecture
-- basics of X11 (for understanding existing code)
-- C language
-- using shared memory (synchronization methods etc)
-
-**Mentor**: [Marek Marczykowski-Górecki](/team/).
-
--->
 
 ### Qubes Live USB
 
@@ -252,26 +213,6 @@ details: [#1552](https://github.com/QubesOS/qubes-issues/issues/1552),
 
 **Mentor**: [Frédéric Pierret](/team/)
 
-<!--
-### Unikernel-based firewallvm with Qubes firewall settings support
-
-REMOVED as of January 2020: work is being done on this
-
-**Project**: Unikernel based firewallvm with Qubes firewall settings support
-
-**Brief explanation**: [blog post](https://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/), [repo](https://github.com/talex5/qubes-mirage-firewall)
-
-**Expected results**: A firewall implemented as a unikernel which supports all the networking-related functionality as the default sys-firewall VM, including configuration via Qubes Manager. Other duties currently assigned to sys-firewall such as the update proxy may need to be appropriately migrated first.
-
-**Knowledge prerequisite**:
-
-- [OCaml](https://ocaml.org/) + [MirageOS](https://mirage.io/) or other unikernel framework,
-- Xen network stack,
-- Qubes networking model & firewall semantics.
-
-**Mentor**: [Thomas Leonard](mailto:talex5@gmail.com), [Marek Marczykowski-Górecki](/team/)
--->
-
 ### LogVM(s)
 
 **Project**: LogVM(s)
@@ -461,44 +402,6 @@ Some related discussion:
 **Mentor**: [Marek Marczykowski-Górecki](/team/)
 
 
-<!--
-
-REMOVED as of February 2021: work is being done on this
-
-### Porting Qubes to POWER9/PPC64
-
-**Project**: Porting Qubes to POWER9/ppc64
-
-**Brief explanation**:
-
-Qubes currently supports the x86_64 CPU architecture. PowerPC is desirable for security purposes as it is the only architecture where one can get performant hardware with entirely open source firmware. Xen has **deprecated** support for Power9/PPC64 processors. Here are two directions to tackle this project from:
-
-- Port Qubes to KVM then work on ppc64 specifics
-  - Implement some missing functionality in KVM then implement KVM support in the Qubes Hypervisor Abstraction Layer and build process. Improving the HAL will also be beneficial for simplifying the process of porting to further architectures and hypervisors.
-
-- Port Xen to ppc64 then work on Qubes specifics
-  - For more information on porting Xen see [this thread](https://markmail.org/message/vuk7atnyqfq52epp).
-
-More information and further links can be found in the related issue:
-[#4318](https://github.com/QubesOS/qubes-issues/issues/4318).
-
-**Expected results**:
-
-- Add cross-compilation support to qubes-builder and related components.
-- Make ppc64 specific adjustments to Qubes toolstacks/manager (including passthrough of devices from device tree to guest domains).
-- ppc64 specific integration and unit tests.
-- Production of generic u-boot or uefi capable image/iso for target hardware.
-
-**Knowledge prerequisite**:
-
-- Libvirt and Qubes toolstacks (C and python languages).
-- KVM or XEN internals
-- General ppc64 architecture knowledge.
-
-**Mentor**: [Marek Marczykowski-Górecki](/team/)
-
--->
-
 ### Android development in Qubes
 
 **Project**: Research running Android in Qubes VM (probably HVM) and connecting it to Android Studio
@@ -538,12 +441,14 @@ Since the Admin API is continuously growing and changing, continuous security as
 A [Fuzzer](https://en.wikipedia.org/wiki/Fuzzing) would help to automate part of these assessments.
 
 **Expected results**:
+
   - fully automated & extensible Fuzzer for parts of the Admin API
   - user & developer documentation
 
 **Difficulty**: medium
 
 **Prerequisites**:
+
   - basic Python understanding
   - some knowledge about fuzzing & existing fuzzing frameworks (e.g. [oss-fuzz](https://github.com/google/oss-fuzz/tree/master/projects/qubes-os))
   - a hacker's curiosity
@@ -560,6 +465,7 @@ A [Fuzzer](https://en.wikipedia.org/wiki/Fuzzing) would help to automate part of
 **Brief explanation**: Since recently, Xen supports "unified EFI boot" which allows to sign not only Xen binary itself, but also dom0 kernel and their parameters. While the base technology is there, enabling it is a painful and complex process. The goal of this project is to integrate configuration of this feature into Qubes, automating as much as possible. See discussion in [issue #4371](https://github.com/QubesOS/qubes-issues/issues/4371)
 
 **Expected results**:
+
  - a tool to prepare relevant boot files for unified Xen EFI boot - this includes collecting Xen, dom0 kernel, initramfs, config file, and possibly few more (ucode update?); the tool should then sign the file with user provided key (preferably propose to generate it too)
  - integrate it with updates mechanism, so new Xen or dom0 kernel will be picked up automatically
  - include a fallback configuration that can be used for troubleshooting (main unified Xen EFI intentionally does not allow to manipulate parameters at boot time)
@@ -567,6 +473,7 @@ A [Fuzzer](https://en.wikipedia.org/wiki/Fuzzing) would help to automate part of
 **Difficulty**: hard
 
 **Knowledge prerequisite**:
+
  - basic understanding of Secure Boot
  - Bash and Python scripting
 
@@ -586,6 +493,7 @@ A [Fuzzer](https://en.wikipedia.org/wiki/Fuzzing) would help to automate part of
 **Difficulty**: medium
 
 **Knowledge prerequisite**:
+
  - Python scripting
  - Basic knowledge of Linux system services management (systemd, syslog etc)
 

From b7c6ff3cc9a2c8cdb375bb9adcea840796df4081 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sun, 28 Jul 2024 12:04:31 -0400
Subject: [PATCH 183/332] preparation rst conversion

---
 developer/services/qrexec2.md | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/developer/services/qrexec2.md b/developer/services/qrexec2.md
index 33d0f219..8bbffb34 100644
--- a/developer/services/qrexec2.md
+++ b/developer/services/qrexec2.md
@@ -17,7 +17,7 @@ Qubes **qrexec** is a framework for implementing inter-VM (incl. Dom0-VM)
 services. It offers a mechanism to start programs in VMs, redirect their
 stdin/stdout, and a policy framework to control this all.
 
-## Qrexec basics ##
+## Qrexec basics
 
 During each domain creation a process named `qrexec-daemon` is started in
 dom0, and a process named `qrexec-agent` is started in the VM. They are
@@ -56,7 +56,7 @@ There is a similar command line utility available inside Linux AppVMs (note
 the `-vm` suffix): `qrexec-client-vm` that will be described in subsequent
 sections.
 
-## Qubes RPC services ##
+## Qubes RPC services
 
 Apart from simple Dom0-\>VM command executions, as discussed above, it is
 also useful to have more advanced infrastructure for controlled inter-VM
@@ -90,7 +90,7 @@ themselves. Qrexec framework is careful about connecting the stdin/stdout
 of the server process with the corresponding stdin/stdout of the requesting
 process in the requesting VM (see example Hello World service described below).
 
-## Qubes RPC administration ##
+## Qubes RPC administration
 
 Besides each VM needing to provide explicit programs to serve each supported
 service, the inter-VM service RPC is also governed by a central policy in Dom0.
@@ -135,7 +135,7 @@ if still there is no policy file after prompting, the action is denied.
 On the target VM, the `/etc/qubes-rpc/XYZ` must exist, containing the file
 name of the program that will be invoked.
 
-### Requesting VM-VM (and VM-Dom0) services execution ###
+### Requesting VM-VM (and VM-Dom0) services execution
 
 In a src VM, one should invoke the qrexec client via the following command:
 
@@ -161,7 +161,7 @@ If requesting VM-VM (and VM-Dom0) services execution *without cmdline helper*,
 connect directly to `/var/run/qubes/qrexec-agent-fdpass` socket as described
 [below](#all-the-pieces-together-at-work).
 
-### Revoking "Yes to All" authorization ###
+### Revoking "Yes to All" authorization
 
 Qubes RPC policy supports an "ask" action, that will prompt the user whether
 a given RPC call should be allowed. It is set as default for services such
@@ -184,7 +184,7 @@ A user might also want to set their own policies in this section. This may
 mostly serve to prevent the user from mistakenly copying files or text from
 a trusted to untrusted domain, or vice-versa.
 
-### Qubes RPC "Hello World" service ###
+### Qubes RPC "Hello World" service
 
 We will show the necessary files to create a simple RPC call that adds two
 integers on the target VM and returns back the result to the invoking VM.
@@ -232,7 +232,7 @@ be allowed.
 **Note:** For a real world example of writing a qrexec service, see this
 [blog post](https://blog.invisiblethings.org/2013/02/21/converting-untrusted-pdfs-into-trusted.html).
 
-### More high-level RPCs? ###
+### More high-level RPCs?
 
 As previously noted, Qubes aims to provide mechanisms that are very simple
 and thus with very small attack surface. This is the reason why the inter-VM
@@ -242,14 +242,14 @@ users/app developers are always free to run more high-level RPC protocols on
 top of qrexec. Care should be taken, however, to consider potential attack
 surfaces that are exposed to untrusted or less trusted VMs in that case.
 
-# Qubes RPC internals #
+## Qubes RPC internals
 
 (*This is about the implementation of qrexec v2. For the implementation of
 qrexec v3, see [here](/doc/qrexec-internals/). Note that the user
 API in v3 is backward compatible: qrexec apps written for Qubes R2 should
 run without modification on Qubes R3.*)
 
-## Dom0 tools implementation ##
+## Dom0 tools implementation
 
 Players:
 
@@ -262,7 +262,7 @@ Players:
 
 **Note:** None of the above tools are designed to be used by users.
 
-## Linux VMs implementation ##
+## Linux VMs implementation
 
 Players:
 
@@ -275,7 +275,7 @@ Players:
 **Note:** None of the above tools are designed to be used by
 users. `qrexec-client-vm` is designed to be wrapped up by Qubes apps.
 
-## Windows VMs implementation ##
+## Windows VMs implementation
 
 `%QUBES_DIR%` is the installation path (`c:\Program Files\Invisible Things
 Lab\Qubes OS Windows Tools` by default).
@@ -291,7 +291,7 @@ Lab\Qubes OS Windows Tools` by default).
 **Note:** None of the above tools are designed to be used by
 users. `qrexec-client-vm` is designed to be wrapped up by Qubes apps.
 
-## All the pieces together at work ##
+## All the pieces together at work
 
 **Note:** This section is not needed to use qrexec for writing Qubes
 apps. Also note the [qrexec framework implemention in Qubes R3](/doc/qrexec3/)

From 8fd6045d79bcfaf0ee4eeee571a33d6533c8be7e Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sun, 28 Jul 2024 12:06:39 -0400
Subject: [PATCH 184/332] preparation rst ocnversion

---
 user/advanced-topics/bind-dirs.md | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/user/advanced-topics/bind-dirs.md b/user/advanced-topics/bind-dirs.md
index acdc515d..210eb383 100644
--- a/user/advanced-topics/bind-dirs.md
+++ b/user/advanced-topics/bind-dirs.md
@@ -8,21 +8,20 @@ ref: 186
 title: How to make any file persistent (bind-dirs)
 ---
 
-## What are bind-dirs? ##
+## What are bind-dirs?
 
 With [bind-dirs](https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-systemd/bind-dirs.sh)
 any arbitrary files or folders can be made persistent in app qubes.
 
-## What is it useful for? ##
+## What is it useful for?
 
 In an app qube all of the file system comes from the template except `/home`, `/usr/local`, and `/rw`.
 This means that changes in the rest of the filesystem are lost when the app qube is shutdown.
 bind-dirs provides a mechanism whereby files usually taken from the template can be persisted across reboots.
 
-For example, in Whonix, [Tor's data dir `/var/lib/tor` has been made persistent in the TemplateBased ProxyVM sys-whonix](https://github.com/Whonix/qubes-whonix/blob/8438d13d75822e9ea800b9eb6024063f476636ff/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf#L5)
-In this way sys-whonix can benefit from the Tor anonymity feature 'persistent Tor entry guards' but does not have to be a standalone.
+For example, in Whonix, Tor's data dir `/var/lib/tor` [has been made persistent](https://github.com/Whonix/qubes-whonix/blob/8438d13d75822e9ea800b9eb6024063f476636ff/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf#L5) in the TemplateBased ProxyVM sys-whonix. In this way sys-whonix can benefit from the Tor anonymity feature 'persistent Tor entry guards' but does not have to be a standalone.
 
-## How to use bind-dirs.sh? ##
+## How to use bind-dirs.sh?
 
 In this example, we want to make `/var/lib/tor` persistent. Enter all of the following commands in your app qube.
 
@@ -68,13 +67,13 @@ binds+=( '/var/lib/tor' )
 binds+=( '/etc/tor/torrc' )
 ```
 
-## Other Configuration Folders ##
+## Other Configuration Folders
 
 * `/usr/lib/qubes-bind-dirs.d` (lowest priority, for packages)
 * `/etc/qubes-bind-dirs.d`  (intermediate priority, for template wide configuration)
 * `/rw/config/qubes-bind-dirs.d` (highest priority, for per VM configuration)
 
-## How does it work? ##
+## How does it work?
 
 bind-dirs.sh is called at startup of an app qube, and configuration files in the above configuration folders are parsed to build a bash array.
 Files or folders identified in the array are copied to `/rw/bind-dirs` if they do not already exist there, and are then bind mounted over the original files/folders.
@@ -84,7 +83,7 @@ Creation of the files and folders in `/rw/bind-dirs` should be automatic the fir
 If you want to circumvent this process, you can create the relevant file structure under `/rw/bind-dirs` and make any changes at the same time that you perform the configuration, before reboot.
 Note that you must create the full folder structure under `/rw/bind-dirs` - e.g you would have to create `/rw/bind-dirs/var/lib/tor`
 
-## Limitations ##
+## Limitations
 
 * Files that exist in the template root image cannot be deleted in the app qubes root image using bind-dirs.sh.
 * Re-running `sudo /usr/lib/qubes/init/bind-dirs.sh` without a previous `sudo /usr/lib/qubes/init/bind-dirs.sh umount` does not work.
@@ -95,7 +94,7 @@ Any changes you make will not survive a reboot. If you think it likely you will
 If you try to use bind-dirs on such files you may break your qube in unpredictable ways.
 You can add persistent rules to `/etc/hosts` using [`/rw/config/rc.local`](/doc/config-files)
 
-## How to remove binds from bind-dirs.sh? ##
+## How to remove binds from bind-dirs.sh?
 
 `binds` is actually just a bash variable (an array) and the bind-dirs.sh configuration folders are sourced as bash snippets in lexical order.
 Therefore if you wanted to remove an existing entry from the `binds` array, you could do that by using a lexically higher configuration file.

From da97d63f53e3946200af71dd9e06790713691acb Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sun, 28 Jul 2024 12:07:12 -0400
Subject: [PATCH 185/332] preparation rst ocnversion

---
 user/advanced-topics/mount-from-other-os.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/user/advanced-topics/mount-from-other-os.md b/user/advanced-topics/mount-from-other-os.md
index 86441666..e930cf8e 100644
--- a/user/advanced-topics/mount-from-other-os.md
+++ b/user/advanced-topics/mount-from-other-os.md
@@ -13,6 +13,7 @@ title: How to mount a Qubes partition from another OS
 When a Qubes OS install is unbootable or booting it is otherwise undesirable, this process allows for the recovery of files stored within the system.
 
 These functions are manual and do not require any Qubes specific tools. All steps assume the default Qubes install with the following components:
+
 - LUKS encrypted disk
 - LVM based VM storage
 

From 7c2b1a498a86b5d9367949ed4fa0ebe92b026dbf Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sun, 28 Jul 2024 12:07:45 -0400
Subject: [PATCH 186/332] preparation rst ocnversion

---
 user/advanced-topics/salt.md | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/user/advanced-topics/salt.md b/user/advanced-topics/salt.md
index 8ea97e9c..848d6b8f 100644
--- a/user/advanced-topics/salt.md
+++ b/user/advanced-topics/salt.md
@@ -577,6 +577,7 @@ qube which provides network to the given qube
 The output for each qube is logged in `/var/log/qubes/mgmt-VM_NAME.log`.
 
 If the log does not contain useful information:
+
 1. Run `sudo qubesctl --skip-dom0 --target=VM_NAME state.apply`
 2. When your qube is being started (yellow) press Ctrl-z on qubesctl.
 3. Open terminal in disp-mgmt-qube_NAME.
@@ -584,10 +585,10 @@ If the log does not contain useful information:
    executed in the management qube.
 5. Get the last two lines:
 
-    ```shell_session
-    $ export PATH="/usr/lib/qubes-vm-connector/ssh-wrapper:$PATH"
-    $ salt-ssh "$target_vm" $salt_command
-    ```
+```shell_session
+$ export PATH="/usr/lib/qubes-vm-connector/ssh-wrapper:$PATH"
+$ salt-ssh "$target_vm" $salt_command
+```
 
   Adjust $target_vm (VM_NAME) and $salt_command (state.apply).
 6. Execute them, fix problems, repeat.

From ae1446925f45c9849d8012ef349d05cf8d36b3c1 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sun, 28 Jul 2024 12:08:31 -0400
Subject: [PATCH 187/332] preparation rst ocnversion

---
 user/advanced-topics/standalones-and-hvms.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/user/advanced-topics/standalones-and-hvms.md b/user/advanced-topics/standalones-and-hvms.md
index 198dab42..35c4f9cf 100644
--- a/user/advanced-topics/standalones-and-hvms.md
+++ b/user/advanced-topics/standalones-and-hvms.md
@@ -68,6 +68,7 @@ qvm-create --class StandaloneVM --label <YOUR_COLOR> --property virt_mode=hvm --
 ```
 
 Notes:
+
 - Technically, `virt_mode=hvm` is not necessary for every standalone.
 However, it is needed if you want to use a kernel from within the qube.
 - If you want to make software installed in a template available in your standalone, pass in the name of the template using the `--template` option.

From a60dc3ad87b27c9efdda7a6889ed1226950321d0 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sun, 28 Jul 2024 18:06:54 -0400
Subject: [PATCH 188/332] prepare conversion to rst

---
 developer/debugging/automated-tests.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/developer/debugging/automated-tests.md b/developer/debugging/automated-tests.md
index 38e4aca2..8082ac35 100644
--- a/developer/debugging/automated-tests.md
+++ b/developer/debugging/automated-tests.md
@@ -267,11 +267,13 @@ It feeds off of the openQA test data to make graph plots. Here is an example:
 ![openqa-investigator-splitgpg-example.png](/attachment/doc/openqa-investigator-splitgpg-example.png)
 
 Some outputs:
+
   - plot by tests
   - plot by errors
   - markdown
 
 Some filters:
+
   - filter by error
   - filter by test name
 

From af2d3c08566db397b736a3af6a9e4b084571cb00 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Thu, 1 Aug 2024 02:52:27 -0700
Subject: [PATCH 189/332] Update to reflect end of 4.1 extended security
 support

---
 .../downloading-installing-upgrading/supported-releases.md | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/user/downloading-installing-upgrading/supported-releases.md b/user/downloading-installing-upgrading/supported-releases.md
index 0e319bab..e694dff4 100644
--- a/user/downloading-installing-upgrading/supported-releases.md
+++ b/user/downloading-installing-upgrading/supported-releases.md
@@ -22,9 +22,9 @@ Qubes OS releases are supported for **six months** after each subsequent major o
 | Release 3.1 | 2016-03-09 | 2017-03-29 | Unsupported    |
 | Release 3.2 | 2016-09-29 | 2019-03-28 | Unsupported    |
 | Release 4.0 | 2018-03-28 | 2022-08-04 | Unsupported    |
-| Release 4.1 | 2022-02-04 | 2024-06-18 | [Extended security support](/news/2024/06/18/qubes-os-4-1-has-reached-end-of-life-extended-security-support-continues-until-2024-07-31/)|
-| Release 4.2 | 2023-12-18 | TBA        | Supported      |
-| Release 4.3 | TBA        | TBA        | In development |
+| Release 4.1 | 2022-02-04 | 2024-06-18 | Unsupported    |
+| Release 4.2 | 2023-12-18 | TBD        | Supported      |
+| Release 4.3 | TBD        | TBD        | In development |
 
 ### Note on patch releases
 
@@ -57,7 +57,6 @@ It is the responsibility of each distribution to clearly notify its users in adv
 
 | Qubes OS    | Fedora | Debian |
 | ----------- | ------ | ------ |
-| Release 4.1 | 39     | 11, 12 |
 | Release 4.2 | 39, 40 | 12     |
 
 ### Note on Debian support

From 9783171ce716dd754c6aa0f06d252c50226aa43b Mon Sep 17 00:00:00 2001
From: apparatius <151992958+apparatius@users.noreply.github.com>
Date: Sat, 10 Aug 2024 07:27:24 +0000
Subject: [PATCH 190/332] Fix a dom0 package downgrade/reinstall commands

---
 .../how-to-install-software-in-dom0.md        | 37 ++-----------------
 1 file changed, 4 insertions(+), 33 deletions(-)

diff --git a/user/advanced-topics/how-to-install-software-in-dom0.md b/user/advanced-topics/how-to-install-software-in-dom0.md
index ddd7f869..1aacb840 100644
--- a/user/advanced-topics/how-to-install-software-in-dom0.md
+++ b/user/advanced-topics/how-to-install-software-in-dom0.md
@@ -65,44 +65,15 @@ commands to `dnf` using `--action=...`.
 **WARNING:** Downgrading a package can expose your system to security
 vulnerabilities.
 
-1. Download an older version of the package:
+To downgrade a specific package in dom0:
 
-    ~~~
-    sudo qubes-dom0-update package-version
-    ~~~
-
-    Dnf will say that there is no update, but the package will nonetheless be
-    downloaded to dom0.
-
-2. Downgrade the package:
-
-    ~~~
-    sudo dnf downgrade package-version
-    ~~~
+    sudo qubes-dom0-update --action=downgrade package-version
 
 ## How to re-install a package
 
-You can re-install in a similar fashion to downgrading.
+To re-install a package in dom0:
 
-1. Download the package:
-
-    ~~~
-    sudo qubes-dom0-update package
-    ~~~
-
-    Dnf will say that there is no update, but the package will nonetheless be
-    downloaded to dom0.
-
-2. Re-install the package:
-
-    ~~~
-    sudo dnf reinstall package
-    ~~~
-
-    Note that `dnf` will only re-install if the installed and downloaded
-    versions match. You can ensure they match by either updating the package to
-    the latest version, or specifying the package version in the first step
-    using the form `package-version`.
+    sudo qubes-dom0-update --action=reinstall package
 
 ## How to uninstall a package
 

From f9c371542aa53c5af94555d3b7f6ceb0457ff40a Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sat, 10 Aug 2024 10:47:07 -0400
Subject: [PATCH 191/332] preparation rst conversion

---
 user/templates/windows/windows-qubes-4-0.md | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/user/templates/windows/windows-qubes-4-0.md b/user/templates/windows/windows-qubes-4-0.md
index e1844e18..919655ff 100644
--- a/user/templates/windows/windows-qubes-4-0.md
+++ b/user/templates/windows/windows-qubes-4-0.md
@@ -16,11 +16,13 @@ title: How to install Windows qubes in Qubes OS 4.0
 If you just want something simple and you can live without some features.
 
 Works:
+
 - display (1440x900 or 1280x1024 are a nice fit onto FHD hw display)
 - keyboard (incl. correct mapping), pointing device
 - network (emulated Realtek NIC)
 
 Does not work:
+
 - copy & paste (the qubes way)
 - copying files into / out of the VM (the qubes way)
 - assigning USB devices (the qubes way via the tray applet)
@@ -29,6 +31,7 @@ Does not work:
 - all other features/hardware needing special tool/driver support
 
 Installation procedure:
+
 - Have the Windows 10 ISO image (I used the 64-bit version) downloaded in some qube.
 - Create a new Qube:
   - Name: Win10, Color: red
@@ -219,6 +222,7 @@ At that point you should have a functional and stable Windows VM, although witho
 ## Windows as a template
 
 Windows 7 and 10 can be installed as TemplateVM by selecting
+
 ~~~
 qvm-create --class TemplateVM --property virt_mode=HVM --property kernel='' --label black Windows-template
 ~~~
@@ -231,6 +235,7 @@ when creating the VM. To have the user data stored in AppVMs depending on this t
 For Windows 10, configuration data like those stored in directories like `AppData` still remain in the TemplateVM, such that their changes are lost each time the AppVM shuts down. In order to make permanent changes to these configuration data, they have to be changed in the TemplateVM, meaning that applications have to be started there, which violates and perhaps even endangers the security of the TemplateVM. Such changes should be done only if absolutely necessary and with great care. It is a good idea to test them first in a cloned TemplateVM before applying them in the production VM.
 
 AppVMs based on these templates can be created the normal way by using the Qube Manager or by specifying
+
 ~~~
 qvm-create --class=AppVM --template=<VMname> 
 ~~~

From 3e93bd58b83f05dfc718d1227b6b6f17f63acc95 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sat, 10 Aug 2024 10:48:13 -0400
Subject: [PATCH 192/332] preparation conversion rst

---
 developer/services/qrexec-socket-services.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/developer/services/qrexec-socket-services.md b/developer/services/qrexec-socket-services.md
index 1dfd9d2d..677cd2c9 100644
--- a/developer/services/qrexec-socket-services.md
+++ b/developer/services/qrexec-socket-services.md
@@ -62,6 +62,7 @@ See the below example.
 
 `qrexec-policy-agent` is the program that handles "ask" prompts for Qubes RPC calls.
 It is a good example of an application that:
+
 * Uses Python and asyncio.
 * Runs as a daemon, to save some overhead on starting process.
 * Runs as a normal user.

From 5926d887b3cfc0d6e5735ecb61fcc87daa490f59 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sun, 11 Aug 2024 09:29:41 -0400
Subject: [PATCH 193/332] preparation rst conversion

---
 user/templates/templates.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/user/templates/templates.md b/user/templates/templates.md
index d12e5585..74d73b9a 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -107,6 +107,7 @@ when you wish to install a fresh template from the Qubes repositories, e.g.:
 You can use a command line tool - `qvm-template` - or a GUI - `qvm-template-gui`.
 
 At the command line in dom0, `qvm-template list --available` will show available templates. To install a template, use:
+
 ```
 $ qvm-template install  <template_name>
 ```
@@ -116,9 +117,11 @@ You can also use `qvm-template` to upgrade or reinstall templates.
 Repo definitions are stored in `/etc/qubes/repo-templates` and associated keys in `/etc/qubes/repo-templates/keys`.  
 There are additional repos for testing releases and community templates.
 To temporarily enable any of these repos, use the `--enablerepo=<repo-name>` option. E.g. :
+
 ```
 $ qvm-template  --enablerepo qubes-templates-community install <template_name>
 ```
+
 To permanently enable a repo, set the line `enabled = 1` in the repo definition in `/etc/qubes/repo-templates`.  
 To permanently disable, set the line to `enabled = 0`.
 

From b98221abc5fb68405db02a67bf144243bf3294d6 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sun, 11 Aug 2024 09:31:34 -0400
Subject: [PATCH 194/332] preparations rst conversion

---
 user/templates/windows/migrate-to-4-1.md | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/user/templates/windows/migrate-to-4-1.md b/user/templates/windows/migrate-to-4-1.md
index f9f60711..bfa9a3f5 100644
--- a/user/templates/windows/migrate-to-4-1.md
+++ b/user/templates/windows/migrate-to-4-1.md
@@ -52,4 +52,7 @@ The PV disk drivers used for migration can be removed after successful installat
 
 After successful uninstallation of the PV disk drivers, the disks will appear as QEMU ATA disks.
 
-:warning: **Caution:** This change may lead Windows to declare that the hardware has changed and that in consequence, the activation is no longer valid, possibly complaining that the use of the software is no longer lawful. It should be possible to reactivate the software if a valid product key is provided.
+<div class="alert alert-warning" role="alert">
+  <i class="fa fa-exclamation-triangle"></i>
+  **Caution:** This change may lead Windows to declare that the hardware has changed and that in consequence, the activation is no longer valid, possibly complaining that the use of the software is no longer lawful. It should be possible to reactivate the software if a valid product key is provided.
+</div>

From abbe9b19477d7e12da239f8b33646a0d02369f3e Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sun, 11 Aug 2024 09:33:47 -0400
Subject: [PATCH 195/332] preparation rst conversion

---
 .../windows/qubes-windows-tools-4-0.md        | 27 ++++++++++---------
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/user/templates/windows/qubes-windows-tools-4-0.md b/user/templates/windows/qubes-windows-tools-4-0.md
index 830020c7..df4879fb 100644
--- a/user/templates/windows/qubes-windows-tools-4-0.md
+++ b/user/templates/windows/qubes-windows-tools-4-0.md
@@ -32,16 +32,16 @@ Below is a breakdown of the feature availability depending on the windows versio
 
 |             Feature                  |  Windows 7 x64 | Windows 10 x64 |
 | ------------------------------------ | :------------: | :------------: |
-| Qubes Video Driver                   |        +       |       -        |
-| Qubes Network Setup                  |        +       |       +        |
-| Private Volume Setup (move profiles) |        +       |       +        |
-| File sender/receiver                 |        +       |       +        |
-| Clipboard Copy/Paste                 |        +       |       +        |
-| Application shortcuts                |        +       |       +        |
-| Copy/Edit in Disposable VM           |        +       |       +        |
-| Block device                         |        +       |       +        |
-| USB device                           |        +       |       +        |
-| Audio                                |        -       |       -        |
+| Qubes Video Driver                   |        y       |       n        |
+| Qubes Network Setup                  |        y       |       y        |
+| Private Volume Setup (move profiles)  |        y       |       y        |
+| File sender/receiver                 |        y       |       y        |
+| Clipboard Copy/Paste                 |        y       |       y        |
+| Application shortcuts                |        y       |       y        |
+| Copy/Edit in Disposable VM           |        y       |       y        |
+| Block device                         |        y       |       y        |
+| USB device                           |        y       |       y        |
+| Audio                                |        n       |       n        |
 
 Qubes Windows Tools are open source and are distributed under a GPL license.
 
@@ -317,8 +317,8 @@ To override global settings for a specific component, create a new key under the
 
 Component-specific settings currently available:
 
-|**Component**|**Setting**|**Type**|**Description**|**Default value**|
-|:------------|:----------|:-------|:--------------|:----------------|
+|   Component   |   Setting   |   Type     |   Description                                   |   Default value   |
+|:--------------|:------------|:-----------|:------------------------------------------------|:------------------|
 |qga|DisableCursor|DWORD|Disable cursor in the VM. Useful for integration with Qubes desktop so you don't see two cursors. Can be disabled if you plan to use the VM through a remote desktop connection of some sort. Needs gui agent restart to apply change (locking OS/logoff should be enough since qga is restarted on desktop change).|1|
 
 Troubleshooting
@@ -336,7 +336,8 @@ Xen logs (/var/log/xen/console/guest-*) are also useful as they contain pvdriver
 
 If a specific component is malfunctioning, you can increase its log verbosity as explained above to get more troubleshooting information. Below is a list of components:
 
-||
+| Component  |  Description                                                                                                           |
+|:-----------|:-----------------------------------------------------------------------------------------------------------------------|
 |qrexec-agent|Responsible for most communication with Qubes (dom0 and other domains), secure clipboard, file copying, qrexec services.|
 |qrexec-wrapper|Helper executable that's responsible for launching qrexec services, handling their I/O and vchan communication.|
 |qrexec-client-vm|Used for communications by the qrexec protocol.|

From d8eea9fb6702d95de42cfda4abab9d315cef9323 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sun, 11 Aug 2024 09:35:03 -0400
Subject: [PATCH 196/332] rst preparation conversion

---
 user/templates/windows/qubes-windows-tools-4-1.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/user/templates/windows/qubes-windows-tools-4-1.md b/user/templates/windows/qubes-windows-tools-4-1.md
index a79d237b..566b7d35 100644
--- a/user/templates/windows/qubes-windows-tools-4-1.md
+++ b/user/templates/windows/qubes-windows-tools-4-1.md
@@ -50,7 +50,7 @@ Below is a breakdown of the feature availability depending on the windows versio
 | ------------------------------------ | :------------: | :-------------------: |
 | Qubes Video Driver                   |        y       |           n           |
 | Qubes Network Setup                  |        y       |           y           |
-| Private Volume Setup (move profiles) |        y       |           y           |
+| Private Volume Setup (move profiles)  |        y       |           y           |
 | File sender/receiver                 |        y       |           y           |
 | Clipboard Copy/Paste                 |        y       |           y           |
 | Application shortcuts                |        y       |           y           |
@@ -311,8 +311,8 @@ To override global settings for a specific component, create a new key under the
 	
 Component-specific settings currently available:
 
-|**Component**|**Setting**|**Type**|**Description**|**Default value**|
-|:------------|:----------|:-------|:--------------|:----------------|
+|   Component   |   Setting   |   Type     |   Description                                   |   Default value   |
+|:--------------|:------------|:-----------|:------------------------------------------------|:------------------|
 |qga|DisableCursor|DWORD|Disable cursor in the VM. Useful for integration with Qubes desktop so you don't see two cursors. Can be disabled if you plan to use the VM through a remote desktop connection of some sort. Needs gui agent restart to apply change (locking OS/logoff should be enough since qga is restarted on desktop change).|1|
 
 ## Troubleshooting

From 5c4c4833cc4c870ab129d1b5b36edf38ffaab060 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Sun, 11 Aug 2024 09:36:35 -0400
Subject: [PATCH 197/332] preparation rst conversion

---
 user/templates/windows/windows-qubes-4-1.md | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/user/templates/windows/windows-qubes-4-1.md b/user/templates/windows/windows-qubes-4-1.md
index 7b998681..d20f5a62 100644
--- a/user/templates/windows/windows-qubes-4-1.md
+++ b/user/templates/windows/windows-qubes-4-1.md
@@ -164,8 +164,12 @@ These parameters are set for the following reasons:
     -  Position to this key and create 3 DWORD values called `BypassTPMCheck`, `BypassSecureBootCheck` and `BypassRAMCheck` and set each value to `1`.
     -  Close the registry editor and console windows.
     -  In the setup window, hit the left arrow in the left upper corner. You will then return into the setup, which will continue normally and install Windows 11 without TPM 2.0.
-   
-    :warning: **Caution:** This temporary patch may cease to work if it so pleases Microsoft some time.
+
+<div class="alert alert-warning" role="alert">
+  <i class="fa fa-exclamation-triangle"></i>
+  **Caution:** This temporary patch may cease to work if it so pleases Microsoft some time.
+</div>
+
     
     The installation of Windows 11 may require an internet connection to grab a Microsoft ID. This is currently true only for the home addition, but will probably extend to the Pro edition, too. A workaround to bypass the internet connection requirements of the Windows 11 setup has been published that currently works for version 21H2 but may be blocked some time in the future by Microsoft:
     

From bdda0ae8dc021c8f4dd6d63ab5e957e1c7ad88c1 Mon Sep 17 00:00:00 2001
From: qm <3440586+qm@users.noreply.github.com>
Date: Sun, 11 Aug 2024 19:18:55 -0400
Subject: [PATCH 198/332] preparation rst conversion

---
 user/troubleshooting/installation-troubleshooting.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/user/troubleshooting/installation-troubleshooting.md b/user/troubleshooting/installation-troubleshooting.md
index c745acb4..c32b80c2 100644
--- a/user/troubleshooting/installation-troubleshooting.md
+++ b/user/troubleshooting/installation-troubleshooting.md
@@ -61,6 +61,7 @@ If that doesn't help, then disable one and try the other.
 Visit the [UEFI Troubleshooting guide](/doc/uefi-troubleshooting/) if other errors arise during UEFI booting. 
 
 These errors may also occur due to an incompatible Nvidia graphics card. If you have one, follow the following instructions:
+
 1. Disable secure/fast boot and use legacy mode
 2. Enter GRUB, move the selection to the first choice, and then press the Tab key. 
 3. Now, you are in edit mode. Move the text cursor with your arrow key and after ``kernel=`` line, add:

From d7d03089f86e8126c0caae5c6fdc385de00fd010 Mon Sep 17 00:00:00 2001
From: qm <3440586+qm@users.noreply.github.com>
Date: Sun, 11 Aug 2024 19:39:45 -0400
Subject: [PATCH 199/332] preparation rst conversion

---
 developer/code/code-signing.md                     |  2 +-
 user/how-to-guides/backup-emergency-restore-v3.md  | 14 +++++++-------
 user/security-in-qubes/mfa.md                      | 12 ++++++------
 user/security-in-qubes/split-gpg.md                |  2 +-
 user/templates/windows/qubes-windows-tools-4-1.md  | 10 +++++-----
 .../installation-troubleshooting.md                | 14 +++++++-------
 6 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/developer/code/code-signing.md b/developer/code/code-signing.md
index bb62453a..8074840d 100644
--- a/developer/code/code-signing.md
+++ b/developer/code/code-signing.md
@@ -146,7 +146,7 @@ Although GitHub adds a little green `Verified` button next to the commit, the [s
    If the commit is not signed, you can see the message
    
    > policy/qubesos/code-signing — No signature found
-3. If the commit is signed, the key is downloaded from a GPG key server.
+2. If the commit is signed, the key is downloaded from a GPG key server.
    If you can see the following error message, please check if you have uploaded the key to a key server.
    
    > policy/qubesos/code-signing — Unable to verify (no valid key found)
diff --git a/user/how-to-guides/backup-emergency-restore-v3.md b/user/how-to-guides/backup-emergency-restore-v3.md
index 7a460d4e..3d3fc392 100644
--- a/user/how-to-guides/backup-emergency-restore-v3.md
+++ b/user/how-to-guides/backup-emergency-restore-v3.md
@@ -66,7 +66,7 @@ any GNU/Linux system with the following procedure.
     supported message digest algorithms can be found with `openssl
     list-message-digest-algorithms`.
 
- 5. Read the `backup-header`. You'll need some of this information later. The
+ 4. Read the `backup-header`. You'll need some of this information later. The
     file will look similar to this:
 
         [user@restore ~]$ cat backup-header
@@ -80,7 +80,7 @@ any GNU/Linux system with the following procedure.
     **Note:** If you see `version=2` here, go to [Emergency Backup Recovery -
     format version 2](/doc/backup-emergency-restore-v2/) instead.
 
- 6. Verify the integrity of the `private.img` file which houses your data.
+ 5. Verify the integrity of the `private.img` file which houses your data.
 
         [user@restore ~]$ cd vm1/
         [user@restore vm1]$ openssl dgst -sha512 -hmac "$backup_pass" private.img.000
@@ -100,7 +100,7 @@ any GNU/Linux system with the following procedure.
     complete list of supported message digest algorithms can be found with
     `openssl list-message-digest-algorithms`.
 
- 7. Decrypt the `private.img` file.
+ 6. Decrypt the `private.img` file.
 
         [user@restore vm1]$ find -name 'private.img.*[0-9]' | sort -V | xargs cat | openssl enc -d -md MD5 -pass pass:"$backup_pass" -aes-256-cbc -out private.img.dec
 
@@ -110,7 +110,7 @@ any GNU/Linux system with the following procedure.
     complete list of supported cipher algorithms can be found with `openssl
     list-cipher-algorithms`.
 
- 8. Decompress the decrypted `private.img` file.
+ 7. Decompress the decrypted `private.img` file.
 
         [user@restore vm1]$ zforce private.img.dec
         private.img.dec -- replaced with private.img.dec.gz
@@ -124,19 +124,19 @@ any GNU/Linux system with the following procedure.
         [user@restore vm1]$ mv private.img.dec private.img.dec.bz2
         [user@restore vm1]$ bunzip2 private.img.dec.bz2
 
- 9. Untar the decrypted and decompressed `private.img` file.
+ 8. Untar the decrypted and decompressed `private.img` file.
 
         [user@restore vm1]$ tar -xvf private.img.dec
         vm1/private.img
 
- 10. Mount the private.img file and access your data.
+ 9. Mount the private.img file and access your data.
 
         [user@restore vm1]$ sudo mkdir /mnt/img
         [user@restore vm1]$ sudo mount -o loop vm1/private.img /mnt/img/
         [user@restore vm1]$ cat /mnt/img/home/user/your_data.txt
         This data has been successfully recovered!
 
-11. Success! If you wish to recover data from more than one VM in your backup,
+10. Success! If you wish to recover data from more than one VM in your backup,
     simply repeat steps 5--9 for each additional VM.
 
 
diff --git a/user/security-in-qubes/mfa.md b/user/security-in-qubes/mfa.md
index a4103e33..6009926d 100644
--- a/user/security-in-qubes/mfa.md
+++ b/user/security-in-qubes/mfa.md
@@ -197,14 +197,14 @@ website](https://docs.nitrokey.com/software/nitropy/all-platforms/installation).
    the template take effect in your USB app qube) or install the packages inside
    your USB VM as well if you would like to avoid rebooting it.
 
-1. Install [qubes-app-yubikey](https://github.com/QubesOS/qubes-app-yubikey) in
+2. Install [qubes-app-yubikey](https://github.com/QubesOS/qubes-app-yubikey) in
    dom0. This provides the program to authenticate with password and YubiKey / NitroKey3.
 
     ```
     sudo qubes-dom0-update qubes-yubikey-dom0
     ```
 
-2. Configure your YubiKey / NitroKey3:
+3. Configure your YubiKey / NitroKey3:
 
    
    **YubiKey**
@@ -260,7 +260,7 @@ of this method. If you want to switch to a different NitroKey later, delete the
 Do the same if for some reason your counters get desynchronized (it stops working), e.g. due
 to connectivity issues (NitroKey3A Minis are known to wear out quickly).
 
-3. **YubiKey**
+4. **YubiKey**
 
 
    Paste your `AESKEY` into `/etc/qubes/yk-keys/yk-secret-key.hex` in dom0.
@@ -274,7 +274,7 @@ to connectivity issues (NitroKey3A Minis are known to wear out quickly).
    Create the file `/etc/qubes/yk-keys/nk-hotp-secret` in dom0 and paste your `AESKEY` 
    (in base 32 format) into it.
 
-4. As mentioned before, you need to define a new password that is only used in
+5. As mentioned before, you need to define a new password that is only used in
    combination with the YubiKey / NitroKey3. You can write this password in plain text into
 `/etc/qubes/yk-keys/login-pass` in dom0. This is considered safe as dom0 is
 ultimately trusted anyway.
@@ -298,7 +298,7 @@ ultimately trusted anyway.
     echo -n "$password" | openssl dgst -sha1 | cut -f2 -d ' '
     ```
 
-5. To enable multi-factor authentication for a service, you need to add
+6. To enable multi-factor authentication for a service, you need to add
 
     ```
     auth include yubikey
@@ -314,7 +314,7 @@ display manager and so on.
     It is important, that `auth include yubikey` is added at the beginning of
 these files, otherwise it will most likely not work.
 
-6. Adjust the USB VM name in case you are using something other than the default
+7. Adjust the USB VM name in case you are using something other than the default
    `sys-usb` by editing `/etc/qubes/yk-keys/vm` in dom0.
 
 #### Usage
diff --git a/user/security-in-qubes/split-gpg.md b/user/security-in-qubes/split-gpg.md
index 7fc35b1c..f13b5ff5 100644
--- a/user/security-in-qubes/split-gpg.md
+++ b/user/security-in-qubes/split-gpg.md
@@ -152,7 +152,7 @@ Note that, because this makes it easier to accept Split GPG's qrexec authorizati
 
 ### Thunderbird 78 and higher
 
-Starting with version 78, Thunderbird has a built-in PGP feature and no longer requires the Enigmail extension. For users coming from the Enigmail extension, the built-in functionality is more limited currently, including that **public keys must live in your work-email qube with Thunderbird rather than your offline work-gpg qube**.
+Starting with version 78, Thunderbird has a built-in PGP feature and no longer requires the Enigmail extension. For users coming from the Enigmail extension, the built-in functionality is more limited currently, including that **public keys must live in your** `work-email` **qube with Thunderbird rather than your offline** `work-gpg` **qube**.
 
 In `work-email`, use the Thunderbird config editor (found at the bottom of preferences/options), and search for `mail.openpgp.allow_external_gnupg`. Switch the value to true. Still in config editor, search for `mail.openpgp.alternative_gpg_path`. Set its value to `/usr/bin/qubes-gpg-client-wrapper`. Restart Thunderbird after this change.
 
diff --git a/user/templates/windows/qubes-windows-tools-4-1.md b/user/templates/windows/qubes-windows-tools-4-1.md
index 566b7d35..0f8be48e 100644
--- a/user/templates/windows/qubes-windows-tools-4-1.md
+++ b/user/templates/windows/qubes-windows-tools-4-1.md
@@ -79,7 +79,7 @@ In the future this step will not be necessary anymore, because we will sign our
 
 The Xen PV Drivers bundled with QWT are signed by a Linux Foundation certificate. Thus Windows 10 and 11 do not require this security mitigation.
 
-**Warning:** it is recommended to increase the default value of Windows VM's `qrexec_timeout` property from 60 (seconds) to, for example, 300. During one of the first reboots after Windows Tools installation Windows user profiles are moved onto the private VM's virtual disk (private.img) and this operation can take some time. Moving profiles and, later on, updating a Windows installation, is performed in an early boot phase when `qrexec` is not yet running, so timeout may occur with the default value. To change the property use this command in `dom0`: *(where <VMname> is the name of your Windows VM)*
+**Warning:** it is recommended to increase the default value of Windows VM's `qrexec_timeout` property from 60 (seconds) to, for example, 300. During one of the first reboots after Windows Tools installation Windows user profiles are moved onto the private VM's virtual disk (private.img) and this operation can take some time. Moving profiles and, later on, updating a Windows installation, is performed in an early boot phase when `qrexec` is not yet running, so timeout may occur with the default value. To change the property use this command in `dom0`: *(where* `<VMname>` *is the name of your Windows VM)*
 
 		[user@dom0 ~] $ qvm-prefs <VMname> qrexec_timeout 7200
 
@@ -137,7 +137,7 @@ Installing the Qubes Windows Tools on Windows 7, 8.1, 10 and 11 both as a Standa
 
  5. After successful installation, the Windows VM must be shut down and started again, possibly a couple of times. On each shutdown, wait until the VM is really stopped, i.e. Qubes shows no more activity.
 
- 6. Qubes will automatically detect that the tools have been installed in the VM and will set appropriate properties for the VM, such as `qrexec_installed`, `guiagent_installed`, and `default_user`. This can be verified (but is not required) using the `qvm-prefs` command  *(where <VMname> is the name of your Windows VM)*:
+ 6. Qubes will automatically detect that the tools have been installed in the VM and will set appropriate properties for the VM, such as `qrexec_installed`, `guiagent_installed`, and `default_user`. This can be verified (but is not required) using the `qvm-prefs` command  *(where* `<VMname>` *is the name of your Windows VM)*:
 
 	        [user@dom0 ~] $ qvm-prefs <VMname>
 
@@ -173,7 +173,7 @@ Installing the Qubes Windows Tools on Windows 7, 8.1, 10 and 11 both as a Standa
 	
 	 If Windows is used in a TemplateVM / AppVM combination, this registry fix has to be applied to the TemplateVM, as the `HKLM` registry key belongs to the template-based part of the registry.
 	
- 10. Lastly to enable file copy operations to a Windows VM, the `default_user` property of this VM should be set to the `<username>` that you use to login to the Windows VM. This can be done via the following command on a `dom0` terminal: *(where <VMname> is the name of your Windows VM)*
+ 10. Lastly to enable file copy operations to a Windows VM, the `default_user` property of this VM should be set to the `<username>` that you use to login to the Windows VM. This can be done via the following command on a `dom0` terminal: *(where* `<VMname>` *is the name of your Windows VM)*
 	
 		`[user@dom0 ~] $ qvm-prefs <VMname> default_user <username>`
   
@@ -267,7 +267,7 @@ Windows qubes can be used as disposables, like any other Linux-based qubes. On c
 	- Name the link, e.g. as `Command Prompt`.
 	- Close the Window with `OK`.
 	- Shut down this AppVM.
-- In the Qube Manager, refresh the applications of the newly created AppVM and select those applications that you want to make available from the disposable. Alternatively, in dom0 execute the command `qvm-sync-appmenus <VMname>`, *where <VMname> is the name of your windows qube*.
+- In the Qube Manager, refresh the applications of the newly created AppVM and select those applications that you want to make available from the disposable. Alternatively, in dom0 execute the command `qvm-sync-appmenus <VMname>`, *where* `<VMname>` *is the name of your windows qube*.
 - In the Qube Manager, go to the "Advanced" tab and enable the option `Disposable template` for your Windows qube.  Alternatively, in dom0 execute the commands `qvm-prefs <VMname> template_for_dispvms True` and `qvm-features <VMname> appmenus-dispvm 1`.
 - Click `Apply`.
 - Still in the Advanced tab, select your Windows qube as its own `Default disposable template`. Alternatively, in dom0 execute the command `qvm-prefs <VMname> default_dispvm <VMname>`.
@@ -277,7 +277,7 @@ Now you should have a menu `Disposable: <VMname>` containing the applications th
 
 For further information on usage of disposables, see [How to use disposables](/doc/how-to-use-disposables/).
 
-**Caution:** *If a Windows-based disposable is used from another qube via the Open/Edit in DisposableVM command, this disposable may not close automatically, due to the command prompt window still running in this dispvm. In this case, the disposable has to be shut down  manually.*
+**Caution:** *If a Windows-based disposable is used from another qube via the* `Open/Edit in DisposableVM` *command, this disposable may not close automatically, due to the command prompt window still running in this dispvm. In this case, the disposable has to be shut down  manually.*
 
 ## Installation logs
 
diff --git a/user/troubleshooting/installation-troubleshooting.md b/user/troubleshooting/installation-troubleshooting.md
index c32b80c2..6e2eae8b 100644
--- a/user/troubleshooting/installation-troubleshooting.md
+++ b/user/troubleshooting/installation-troubleshooting.md
@@ -66,15 +66,15 @@ These errors may also occur due to an incompatible Nvidia graphics card. If you
 2. Enter GRUB, move the selection to the first choice, and then press the Tab key. 
 3. Now, you are in edit mode. Move the text cursor with your arrow key and after ``kernel=`` line, add:
 
-```
-nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off
-```
+  ```bash
+  nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off
+  ```
 
-If the above code doesn't fix the problem, replace it with:
+  If the above code doesn't fix the problem, replace it with:
 
-```   
-noexitboot=1 modprobe.blacklist=nouveau rd.driver.blacklist=nouveau --- intitrd.img
-```
+  ```bash   
+  noexitboot=1 modprobe.blacklist=nouveau rd.driver.blacklist=nouveau --- intitrd.img
+  ```
 
 For more information, look at the [Nvidia Troubleshooting guide](https://forum.qubes-os.org/t/19021#disabling-nouveau).
 

From df88acabc3c1aa6a4ead30c8af03e5aac1351d9b Mon Sep 17 00:00:00 2001
From: qm <3440586+qm@users.noreply.github.com>
Date: Sun, 11 Aug 2024 20:15:08 -0400
Subject: [PATCH 200/332] preparation rst conversion

---
 user/advanced-topics/gui-configuration.md         | 1 +
 user/templates/windows/qubes-windows-tools-4-0.md | 1 +
 user/templates/windows/qubes-windows-tools-4-1.md | 2 ++
 3 files changed, 4 insertions(+)

diff --git a/user/advanced-topics/gui-configuration.md b/user/advanced-topics/gui-configuration.md
index 2f02bbe8..b622ac99 100644
--- a/user/advanced-topics/gui-configuration.md
+++ b/user/advanced-topics/gui-configuration.md
@@ -31,6 +31,7 @@ qvm-features dom0 gui-videoram-min $(xrandr --verbose | grep "Screen 0" | sed -e
 ```
 
 The amount of memory allocated per qube is the maximum of:
+
 - `gui-videoram-min`
 - current display + `gui-videoram-overhead`
 
diff --git a/user/templates/windows/qubes-windows-tools-4-0.md b/user/templates/windows/qubes-windows-tools-4-0.md
index df4879fb..f1bd0a91 100644
--- a/user/templates/windows/qubes-windows-tools-4-0.md
+++ b/user/templates/windows/qubes-windows-tools-4-0.md
@@ -165,6 +165,7 @@ Installing Xen's PV drivers in the VM will lower its resources usage when using
 2. installing Qubes Windows Tools (QWT), which bundles Xen's PV drivers.
 
 Notes about using Xen's VBD (storage) PV driver:
+
 - **Windows 7:** installing the driver requires a fully updated VM or else you'll likely get a BSOD and a VM in a difficult to fix state. Updating Windows takes *hours* and for casual usage there isn't much of a performance between the disk PV driver and the default one; so there is likely no need to go through the lengthy Windows Update process if your VM doesn't have access to untrusted networks and if you don't use I/O intensive apps. If you plan to update your newly installed Windows VM it is recommended that you do so *before* installing Qubes Windows Tools (QWT). If QWT are installed, you should temporarily re-enable the standard VGA adapter in Windows and disable Qubes' (see the section above).
 - the option to install the storage PV driver is disabled by default in Qubes Windows Tools 
 - in case you already had QWT installed without the storage PV driver and you then updated the VM, you may then install the driver from Xen's site (xenvbd.tar).
diff --git a/user/templates/windows/qubes-windows-tools-4-1.md b/user/templates/windows/qubes-windows-tools-4-1.md
index 0f8be48e..8bf82841 100644
--- a/user/templates/windows/qubes-windows-tools-4-1.md
+++ b/user/templates/windows/qubes-windows-tools-4-1.md
@@ -62,6 +62,7 @@ Below is a breakdown of the feature availability depending on the windows versio
 Qubes Windows Tools are open source and are distributed under a GPL license.
 
 **Notes:**
+
 - Currently only 64-bit versions of Windows 7, 8.1, 10 and 11 are supported by Qubes Windows Tools. Only emulated SVGA GPU is supported (although [there has been reports](https://groups.google.com/forum/#!topic/qubes-users/cmPRMOkxkdA) on working GPU passthrough).
 - This page documents the process of installing Qubes Windows Tools in version **R4.1**.
 - *In testing VMs only* it's probably a good idea to install a VNC server before installing QWT. If something goes very wrong with the Qubes gui agent, a VNC server should still allow access to the OS.
@@ -188,6 +189,7 @@ Installing the Qubes Windows Tools on Windows 7, 8.1, 10 and 11 both as a Standa
 Installing Xen's PV drivers in the VM will lower its resources usage when using network and/or I/O intensive applications, but *may* come at the price of system stability (although Xen's PV drivers on a Windows VM are usually very stable). They can be installed as an optional part of Qubes Windows Tools (QWT), which bundles Xen's PV drivers.
 
 **Notes** about using Xen's VBD (storage) PV driver:
+
 - **Windows 7:** Installing the driver requires a fully updated VM or else you'll likely get a BSOD ("Blue Screen Of Death") and a VM in a difficult to fix state. Updating Windows takes *hours* and for casual usage there isn't much of a performance between the disk PV driver and the default one; so there is likely no need to go through the lengthy Windows Update process if your VM doesn't have access to untrusted networks and if you don't use I/O intensive apps or attach block devices. If you plan to update your newly installed Windows VM it is recommended that you do so *before* installing Qubes Windows Tools.  Installing the driver will probably cause Windows 7 activation to become invalid, but the activation can be restored using the Microsoft telephone activation method. 
 - The option to install the storage PV driver is disabled by default in Qubes Windows Tools 
 - In case you already had QWT installed without the storage PV driver and you then updated the VM, you may then install the driver by again starting the QWT installer and selecting the change option.

From 02508977273fa716ea8b0b55337a0aebd255c302 Mon Sep 17 00:00:00 2001
From: Demi Marie Obenour <demi@invisiblethingslab.com>
Date: Sun, 21 Jul 2024 15:01:31 -0400
Subject: [PATCH 201/332] Document how to update system firmware

This is a very important task, but it is often not done due to bad
tools.  Also correct some outdated information on the "how to update
software" page.
---
 user/how-to-guides/how-to-update.md | 69 +++++++++++++++++++++++++++--
 user/reference/glossary.md          |  7 +++
 2 files changed, 73 insertions(+), 3 deletions(-)

diff --git a/user/how-to-guides/how-to-update.md b/user/how-to-guides/how-to-update.md
index 2462bafb..f21cc385 100644
--- a/user/how-to-guides/how-to-update.md
+++ b/user/how-to-guides/how-to-update.md
@@ -17,6 +17,7 @@ Fully updating your Qubes OS system means updating:
 - [dom0](/doc/glossary/#dom0)
 - [templates](/doc/glossary/#template)
 - [standalones](/doc/glossary/#standalone) (if you have any)
+- [firmware](/doc/glossary/#firmware)
 
 ## Security updates
 
@@ -63,15 +64,19 @@ If you use [Anti Evil Maid (AEM)](/doc/anti-evil-maid/), you'll have to "reseal"
 
 <div class="alert alert-danger" role="alert">
   <i class="fa fa-exclamation-triangle"></i>
-  <b>Warning:</b> Updating with direct commands such as <code>qubes-dom0-update</code>, <code>dnf update</code>, and <code>apt update</code> is <b>not</b> recommended, since these bypass built-in Qubes OS update security measures. Instead, we strongly recommend using the <b>Qubes Update</b> tool or its command-line equivalents, as described below. (By contrast, <a href="/doc/how-to-install-software/">installing</a> packages using direct package manager commands is fine.)
+  <b>Warning:</b> Updating with direct commands such as <code>dnf update</code> and <code>apt update</code> is <b>not</b> recommended, since these bypass built-in Qubes OS update security measures. Instead, we strongly recommend using the <b>Qubes Update</b> tool or its command-line equivalents, as described below. (By contrast, <a href="/doc/how-to-install-software/">installing</a> packages using direct package manager commands is fine.)
 </div>
 
-Advanced users may wish to perform updates via the command-line interface. The recommended way to do this is by applying the following two Salt states. **Applying these two Salt states is the same as updating via the Qubes Update tool.**
+Advanced users may wish to perform updates via the command-line interface. There are two ways to do this:
+
+- If you are using Salt, one can use the following two Salt states.
 
  - [update.qubes-dom0](/doc/salt/#updatequbes-dom0)
  - [update.qubes-vm](/doc/salt/#updatequbes-vm)
 
-In your update qube, a terminal window opens that displays the progress of operations and output as it is logged. At the end of the process, logs are sent back to dom0. You answer any yes/no prompts in your dom0 terminal window.
+- Alternatively, use `qubes-dom0-update` to update dom0, and use `qubes-vm-update` to update domUs.
+
+Using either of these methods has the same effect as updating via the Qubes Update tool.
 
 Advanced users may also be interested in learning [how to enable the testing repos](/doc/testing/).
 
@@ -86,3 +91,61 @@ In the case of Qubes OS itself, we will make an [announcement](/news/categories/
 Periodic upgrades are also important for templates. For example, you might be using a [Fedora template](/doc/templates/fedora/). The [Fedora Project](https://getfedora.org/) is independent of the Qubes OS Project. They set their own [schedule](https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule) for when each Fedora release reaches EOL. You can always find out when an OS reaches EOL from the upstream project that maintains it. We also pass along any EOL notices we receive for official template OSes as a convenience to Qubes users (see the [supported template releases](/doc/supported-releases/#templates)).
 
 The one exception to all this is the specific release used for dom0 (not to be confused with Qubes OS as a whole), which [doesn't have to be upgraded](/doc/supported-releases/#note-on-dom0-and-eol).
+
+## Microcode Updates
+
+x86\_64 CPUs contain special low-level software called **microcode**, which
+is used to implement certain instructions and runs on various processors that
+are outside of Qubes OS's control.  Most microcode is in an on-CPU ROM, but
+CPU vendors provide patches that modify small parts of this microcode.  These
+patches can be loaded from the BIOS or by the OS.
+
+The fixes for some QSBs require a microcode update to work. Furthermore,
+microcode updates will sometimes fix vulnerabilities "silently". This means
+that the vulnerability impacts the security of Qubes OS, but the Qubes OS
+Security Team is not informed that a vulnerability exists, so no QSB is ever
+issued. Therefore, it is critical to update microcode.
+
+Intel provides microcode updates for all of their CPUs in a public Git
+repository, and allows OS vendors (such as Qubes OS) to distribute the updates
+free of charge.  AMD, however, only provides microcode for server CPUs.
+AMD client CPUs can only receive microcode updates via a system firmware
+update.  Worse, there is often a significant delay between when a vulnerability
+becomes public and when firmware that includes updated microcode is available
+to Qubes OS users.  This is why Qubes OS recommends Intel CPUs instead of
+AMD CPUs.
+
+## Firmware updates
+
+Modern computers have many processors other than those that run Qubes OS.
+Furthermore, the main processor cores also run firmware, which is used to
+boot the system and often provides some services at runtime.  Both kinds
+of firmware can have bugs and vulnerabilities, so it is critical to keep
+them updated.
+
+Some firmware is loaded by the OS at runtime.
+Such firmware is provided by the `linux-firmware` package and can be updated the usual way.
+Other devices have persistent firmware that must be updated manually.
+
+Qubes OS supports updating system firmware in three different ways.
+Which one to use depends on the device whose firmware is being updated.
+
+- If a device is attached to a domU, it should be updated using **fwupd**.
+  fwupd is included in both Debian and Fedora repositories.
+  It requires Internet access to use, but you can use the updates proxy if you
+  need to update firmware from an offline VM.  You can use either the
+  command-line `fwupdmgr` tool or any of the graphical interfaces to fwupd.
+
+- If a device is attached to dom0, use the `qubes-fwupdmgr` command-line tool.
+  This tool uses fwupd internally, but it fetches firmware and metadata over
+  qrexec from the dom0 UpdateVM, rather than fetching them from the Internet.
+  Unfortunately, their is no graphical interface for this tool yet.
+
+- System76 systems use a special update tool which is simpler than fwupd.
+  Support for this tool is currently in progress.  Once it is finished,
+  users will be able to use the **system76-firmware-cli** command-line
+  tool to update the firmware.
+
+Firmware updates are important on all systems, but they are especially
+important on AMD client systems.  These doesn't support loading microcode from
+the OS, so firmware updates are the **only** way to obtain microcode updates.
diff --git a/user/reference/glossary.md b/user/reference/glossary.md
index 98649dd4..df3009b6 100644
--- a/user/reference/glossary.md
+++ b/user/reference/glossary.md
@@ -88,6 +88,13 @@ domUs lack direct hardware access.
 * Sometimes the term [VM](#vm) is used as a synonym for domU. This is
   technically inaccurate, as [dom0](#dom0) is also a VM in Xen.
 
+## firmware
+
+Software that runs outside the control of the operating system.
+Some firmware executes on the same CPU cores as Qubes OS does, but
+all computers have many additional processors that the operating system
+does not run on, and these computers also run firmware.
+
 ## HVM
 
 Hardware-assisted Virtual Machine. Any fully virtualized, or hardware-assisted,

From 496a3a5ded9cbadbc9f8170cc438e9fe82af8bda Mon Sep 17 00:00:00 2001
From: Ali Mirjamali <ali@mirjamali.com>
Date: Fri, 23 Aug 2024 17:43:44 +0330
Subject: [PATCH 202/332] Remove reference to `qvm-revert-template-changes`

Resolves: https://github.com/QubesOS/qubes-issues/issues/6384
---
 developer/system/template-implementation.md | 14 ++------------
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/developer/system/template-implementation.md b/developer/system/template-implementation.md
index 4feb91fb..1bd4dd2b 100644
--- a/developer/system/template-implementation.md
+++ b/developer/system/template-implementation.md
@@ -73,19 +73,9 @@ When TemplateVM is stopped, the xen script moves root-cow.img to root-cow.img.ol
 
 #### Rollback template changes
 
-There is possibility to rollback last template changes. Saved root-cow.img.old contains all changes made during last TemplateVM run. Rolling back changes is done by reverting this "binary patch".
+There is possibility to rollback last template changes. Using the automatic snapshot that is normally saved every time the template is shutdown.
 
-This is done using snapshot-merge device-mapper target (available from 2.6.34 kernel). It requires that no other snapshot device uses underlying block devices (root.img, root-cow.img via loop device). Because of this all AppVMs based on this template must be halted during this operation.
-
-Steps performed by **qvm-revert-template-changes**:
-
-1. Ensure that no other VMs uses this template.
-2. Prepare snapshot device with ***root-cow.img.old*** instead of *root-cow.img* (*/etc/xen/scripts/block-snapshot prepare*).
-3. Replace *snapshot* device-mapper target with *snapshot-merge*, other parameters (chunk size etc) remains untouched. Now kernel starts merging changes stored in *root-cow.img.old* into *root.img*. d-m device can be used normally (if needed).
-4. Waits for merge completed: *dmsetup status* shows used snapshot blocks – it should be equal to metadata size when completed.
-5. Replace *snapshot-merge* d-m target back to *snapshot*.
-6. Cleanup snapshot device (if nobody uses it at the moment).
-7. Move *root-cow.img.old* to *root-cow.img* (overriding existing file).
+Refer to volume backup and revert [documentation](/doc/volume-backup-revert) for more information.
 
 ### Snapshot device in AppVM
 

From 9218f2316760612376313fc7a126b13ded1e6fc4 Mon Sep 17 00:00:00 2001
From: "Dr. Gerhard Weck" <GerhardWeck@online.de>
Date: Sun, 25 Aug 2024 10:12:11 +0200
Subject: [PATCH 203/332] Describe Move user profiles without QWT installation

---
 user/templates/windows/windows-qubes-4-1.md | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/user/templates/windows/windows-qubes-4-1.md b/user/templates/windows/windows-qubes-4-1.md
index 4d38a4bb..62210c0a 100644
--- a/user/templates/windows/windows-qubes-4-1.md
+++ b/user/templates/windows/windows-qubes-4-1.md
@@ -231,7 +231,16 @@ For additional information on configuring a Windows qube, see the [Customizing W
 
 ## Windows as a template
 
-As described above Windows 7, 8.1, 10 and 11 can be installed as TemplateVM. To have the user data stored in AppVMs depending on this template, the option `Move User Profiles` has to be selected on installation of Qubes Windows Tools. For Windows 7, before installing QWT, the private disk `D:` has to be renamed to `Q:`, see the QWT installation documentation in [Qubes Windows Tools](/doc/templates/windows/qubes-windows-tools-4-1).
+As described above Windows 7, 8.1, 10, and 11 can be installed as TemplateVM. To have the user data stored in AppVMs depending on this template, the user data have to be stored on a private disk named `Q:`. If there is already a disk for user data, possibly called `D:`, it has to be renamed to `Q:`. Otherwise, this disk has to be created via the Windows `diskpart` utility, or the Disk Management administrative function by formatting the qube's private volume and associating the letter `Q:` with it. The volume name is of no importance.
+
+Moving the user data is not directly possible under Windows, because the directory `C:\Users` is permanently open and thus locked. Qubes Windows Tools provides a function to move these data on Windows reboot when the directory is not yet locked. To use this function, a working version of QWT has to be used (see the documentation on QWT installation). For Qubes R4.2, this is currently the version 4.1.69. There are two possibilities to move the user data to this volume `Q:`.
+
+- If Qubes Windows Tools is installed, the option `Move User Profiles` has to be selected on the installation. In this case, the user files are moved to the new disk during the reboot at the end of the installation.
+
+- This can also be accomplished without QWT installation, avoiding the installation of the Xen PV drivers, if the risk of a compromised version of these drivers according to QSB-091 is considered too severe. In this case, the file `relocate_dir.exe` has to be extracted from the QWT installer kit `qubes-tools-x64.msi`, which will be shown as the content of the CDROM made available by starting the Windows qube with the additional option `--install-windows-tools` (see the QWT installation documentation). The installer kit is a specially formatted archive, from which the file `relocate_dir.exe` can be extracted using a utility like 7-Zip. The file has then to be copied to `%windir%\system32`, i.e. usually `C:\Windows\system32`. Furthermore, locate the registry key `HKLM\SYSTEM\CurrentControlSet\Control\Session Manager`, and add the text `relocate_dir.exe C:\Users Q:\Users` as a new line to the REG_MULTI_SZ-value `\BootExecute` in this key. On rebooting the Windows qube, the user files will be moved to the disk `Q:`, and the additional registry entry will be removed, such that this action occurs only once.
+
+If the user data have been moved to `Q:`, be sure not to user the option `Move User Profeiles`on subsequent installations of Qubes Windows tools.
+
 
 AppVMs based on these templates can be created the normal way by using the Qube Manager or by specifying
 ~~~

From 649444de0e249012ee46b18bb4f380641660f002 Mon Sep 17 00:00:00 2001
From: Randy <RandyTheOtter@proton.me>
Date: Fri, 30 Aug 2024 07:57:10 +0000
Subject: [PATCH 204/332] Update config-files.md

Fix header syntax according to [the documentation guidelines](https://www.qubes-os.org/doc/documentation-style-guide/#headings)
---
 user/advanced-topics/config-files.md | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/user/advanced-topics/config-files.md b/user/advanced-topics/config-files.md
index 3ffdfd55..37ee7c03 100644
--- a/user/advanced-topics/config-files.md
+++ b/user/advanced-topics/config-files.md
@@ -11,8 +11,7 @@ ref: 180
 title: Config files
 ---
 
-Qubes-specific VM config files
-------------------------------
+## Qubes-specific VM config files
 
 These files are placed in `/rw`, which survives a VM restart.
 That way, they can be used to customize a single VM instead of all VMs based on the same template.
@@ -76,8 +75,7 @@ Note that scripts need to be executable (`chmod +x`) to be used.
 
 Also, take a look at [bind-dirs](/doc/bind-dirs) for instructions on how to easily modify arbitrary system files in an app qube and have those changes persist.
 
-GUI and audio configuration in dom0
------------------------------------
+## GUI and audio configuration in dom0
 
 The GUI configuration file `/etc/qubes/guid.conf` in one of a few not managed by `qubes-prefs` or the Qubes Manager tool.
 Sample config (included in default installation):

From 35ae77260208d3bcd5e5c712068acca877120302 Mon Sep 17 00:00:00 2001
From: Randy <RandyTheOtter@proton.me>
Date: Fri, 30 Aug 2024 07:59:49 +0000
Subject: [PATCH 205/332] Update how-to-enter-fullscreen-mode.md

Fix headers according to the [documentation guidelines](https://www.qubes-os.org/doc/documentation-style-guide/#headings)
---
 user/how-to-guides/how-to-enter-fullscreen-mode.md | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/user/how-to-guides/how-to-enter-fullscreen-mode.md b/user/how-to-guides/how-to-enter-fullscreen-mode.md
index 201d6d2e..2ff92990 100644
--- a/user/how-to-guides/how-to-enter-fullscreen-mode.md
+++ b/user/how-to-guides/how-to-enter-fullscreen-mode.md
@@ -11,20 +11,17 @@ ref: 205
 title: How to enter fullscreen mode
 ---
 
-What is fullscreen mode?
--------------------------
+## What is fullscreen mode?
 
 Normally, the Qubes GUI virtualization daemon restricts the VM from "owning" the full screen, ensuring that there are always clearly marked decorations drawn by the trusted Window Manager around each of the VMs window.
 This allows the user to easily realize to which domain a specific window belongs.
 See the [screenshots](/doc/QubesScreenshots/) page for examples.
 
-Why is fullscreen mode potentially dangerous?
-----------------------------------------------
+## Why is fullscreen mode potentially dangerous?
 
 If one allowed one of the VMs to "own" the full screen, e.g. to show a movie on a full screen, it might not be possible for the user to know if the applications/VM really "released" the full screen, or if it has started emulating the whole desktop and is pretending to be the trusted Window Manager, drawing shapes on the screen that look e.g. like other windows, belonging to other domains (e.g. to trick the user into entering a secret passphrase into a window that looks like belonging to some trusted domain).
 
-Secure use of fullscreen mode
-------------------------------
+## Secure use of fullscreen mode
 
 However, it is possible to deal with fullscreen mode in a secure way assuming there are mechanisms that can be used at any time to switch between windows or show the full desktop and that cannot be intercepted by the VM.
 The simplest example is the use of Alt+Tab for switching between windows, which is a shortcut handled by dom0.
@@ -33,8 +30,7 @@ Other examples such mechanisms are the KDE "Present Windows" and "Desktop Grid"
 Those effects are enabled by default in KDE once Compositing gets enabled in KDE (System Settings -\> Desktop -\> Enable Desktop Effects), which is recommended anyway.
 By default, they are triggered by Ctrl-F8 and Ctrl-F9 key combinations, but can also be reassigned to other shortcuts.
 
-Enabling fullscreen mode for select VMs
-----------------------------------------
+## Enabling fullscreen mode for select VMs
 
 You can always put a window into fullscreen mode in Xfce4 using the trusted window manager by right-clicking on a window's title bar and selecting "Fullscreen" or pressing `alt` + `f11`.
 This functionality should still be considered safe, since a VM window still can't voluntarily enter fullscreen mode.

From 88384e0dc5d5e39e1fadfcd23a761e50ad09c2e4 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Mon, 2 Sep 2024 08:59:33 -0700
Subject: [PATCH 206/332] Update recommendations and notes regarding microcode
 and AMD

---
 user/hardware/system-requirements.md | 57 +++++++++++++++++++++++++---
 1 file changed, 52 insertions(+), 5 deletions(-)

diff --git a/user/hardware/system-requirements.md b/user/hardware/system-requirements.md
index a31c582a..018f7cab 100644
--- a/user/hardware/system-requirements.md
+++ b/user/hardware/system-requirements.md
@@ -33,9 +33,13 @@ title: System requirements
 
 ## Recommended
 
-- **CPU:** 64-bit Intel or AMD processor (also known as `x86_64`, `x64`, and `AMD64`)
-  - [Intel VT-x](https://en.wikipedia.org/wiki/X86_virtualization#Intel_virtualization_.28VT-x.29) with [EPT](https://en.wikipedia.org/wiki/Second_Level_Address_Translation#Extended_Page_Tables) or [AMD-V](https://en.wikipedia.org/wiki/X86_virtualization#AMD_virtualization_.28AMD-V.29) with [RVI](https://en.wikipedia.org/wiki/Second_Level_Address_Translation#Rapid_Virtualization_Indexing)
-  - [Intel VT-d](https://en.wikipedia.org/wiki/X86_virtualization#Intel-VT-d) or [AMD-Vi (also known as AMD IOMMU)](https://en.wikipedia.org/wiki/X86_virtualization#I.2FO_MMU_virtualization_.28AMD-Vi_and_Intel_VT-d.29)
+- **CPU:** 64-bit Intel processor (also known as `x86_64`, `x64`, and `Intel 64`)
+  - [Intel VT-x](https://en.wikipedia.org/wiki/X86_virtualization#Intel_virtualization_.28VT-x.29) with [EPT](https://en.wikipedia.org/wiki/Second_Level_Address_Translation#Extended_Page_Tables)
+  - [Intel VT-d](https://en.wikipedia.org/wiki/X86_virtualization#Intel-VT-d)
+  - For security, we recommend processors that are recent enough to still be
+    receiving microcode updates (see [below](#important-updates) for details).
+  - AMD processors are not recommended due to inconsistent security support on
+    client platforms (see [below](#important-updates) for details).
 
 - **Memory:** 16 GB RAM
 
@@ -44,9 +48,9 @@ title: System requirements
 
 - **Graphics:** Intel integrated graphics processor (IGP) strongly recommended
   - Nvidia GPUs may require significant
-    [troubleshooting](/doc/install-nvidia-driver/)
+    [troubleshooting](/doc/install-nvidia-driver/).
   - AMD GPUs have not been formally tested, but Radeons (especially RX580 and
-    earlier) generally work well
+    earlier) generally work well.
 
 - **Peripherals:** A non-USB keyboard or multiple USB controllers
 
@@ -84,6 +88,49 @@ We recommend consulting these resources when selecting hardware for Qubes OS:
 - **Installing Qubes in a virtual machine is not recommended, as it uses its
   own bare-metal hypervisor (Xen).**
 
+- There is a class of security vulnerabilities that can be fixed only by
+  microcode updates. If your computer or the CPU in it no longer receives
+  microcode updates (e.g., because it is too old), it may not be possible for
+  some of these vulnerabilities to be mitigated on your system, leaving you
+  vulnerable. For this reason, we recommend using Qubes OS on systems that are
+  still receiving microcode updates. Nonetheless, Qubes OS **can** run on
+  systems that no longer receive microcode updates, and such systems will still
+  offer significant security advantages over conventional operating systems on
+  the same hardware.
+
+- Intel and AMD handle microcode updates differently, which has significant
+  security implications. On Intel platforms, microcode updates can typically be
+  loaded from the operating system. This allows the Qubes security team to
+  respond rapidly to new vulnerabilities by shipping microcode updates alongside
+  other security updates directly to users. By contrast, on AMD client (as
+  opposed to server) platforms, microcode updates are typically shipped only as
+  part of system firmware and generally cannot be loaded from the operating
+  system. This means that AMD users typically must wait for:
+  
+  1. AMD to distribute microcode updates to original equipment manufacturers
+  (OEMs), original design manufacturers (ODMs), and motherboard manufacturers
+  (MB); and
+  2. The user's OEM, ODM, or MB to provide a suitable BIOS or (U)EFI update for
+  the user's system.
+  
+  Historically, AMD has often been slow to complete step (1), at least for its
+  client (as opposed to server) platforms. In some cases, AMD has made fixes
+  available for its server platforms very shortly after a security embargo was
+  lifted, but it did not make fixes  available for client platforms facing the
+  same vulnerability until weeks or months later. (A "security embargo" is the
+  practice of avoiding public disclosure of a security vulnerability prior to a
+  designated date.) By contrast, Intel has consistently made fixes available for
+  new CPU vulnerabilities across its supported platforms very shortly after
+  security embargoes have been lifted.
+
+  Step (2) varies by vendor. Many vendors fail to complete step (2) at all,
+  while some others take a very long time to complete it.
+  
+  The bottom line is that Qubes OS **can** run on AMD systems, and the Qubes and
+  Xen security teams do their best to provide security support for AMD systems.
+  However, without the ability to ship microcode updates, there is only so much
+  they can do.
+
 - Qubes **can** be installed on many systems that do not meet the recommended
   requirements. Such systems will still offer significant security improvements
   over traditional operating systems, since things like GUI isolation and

From 1bc8ddb4728107aba532fef306b0ae09c68d7bc0 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Tue, 3 Sep 2024 01:41:18 -0700
Subject: [PATCH 207/332] Include link to Intel's list of end-of-support dates

---
 user/hardware/system-requirements.md | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/user/hardware/system-requirements.md b/user/hardware/system-requirements.md
index 018f7cab..ffe39f7c 100644
--- a/user/hardware/system-requirements.md
+++ b/user/hardware/system-requirements.md
@@ -98,6 +98,15 @@ We recommend consulting these resources when selecting hardware for Qubes OS:
   offer significant security advantages over conventional operating systems on
   the same hardware.
 
+  Intel maintains a
+  [list](https://www.intel.com/content/www/us/en/support/articles/000022396/processors.html)
+  of end-of-support dates for its processors. However, this list seems to
+  include only processors that are no longer supported or will soon no longer
+  be supported. Many newer Intel processors are missing from this list. To our
+  knowledge, Intel does not announce end-of-support dates for its newer
+  processors in advance, nor does it have a public policy governing how long
+  support will last.
+
 - Intel and AMD handle microcode updates differently, which has significant
   security implications. On Intel platforms, microcode updates can typically be
   loaded from the operating system. This allows the Qubes security team to
@@ -116,7 +125,7 @@ We recommend consulting these resources when selecting hardware for Qubes OS:
   Historically, AMD has often been slow to complete step (1), at least for its
   client (as opposed to server) platforms. In some cases, AMD has made fixes
   available for its server platforms very shortly after a security embargo was
-  lifted, but it did not make fixes  available for client platforms facing the
+  lifted, but it did not make fixes available for client platforms facing the
   same vulnerability until weeks or months later. (A "security embargo" is the
   practice of avoiding public disclosure of a security vulnerability prior to a
   designated date.) By contrast, Intel has consistently made fixes available for

From bdc020a10eb0ae7d97508661aa50d3cc805d5d53 Mon Sep 17 00:00:00 2001
From: qm <3440586+qm@users.noreply.github.com>
Date: Tue, 3 Sep 2024 17:23:25 -0400
Subject: [PATCH 208/332] new line

---
 user/downloading-installing-upgrading/installation-guide.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/user/downloading-installing-upgrading/installation-guide.md b/user/downloading-installing-upgrading/installation-guide.md
index c38cbc35..6e3a07d9 100644
--- a/user/downloading-installing-upgrading/installation-guide.md
+++ b/user/downloading-installing-upgrading/installation-guide.md
@@ -172,6 +172,8 @@ You can have as many keyboard layout and languages as you want. Post-install, yo
 Don't forget to select your time and date by clicking on the Time & Date entry.
 
 [![Time and date](/attachment/doc/time-and-date.png)](/attachment/doc/time-and-date.png)
+
+
 ### Installation destination
 
 Under the System section, you must choose the installation destination. Select the storage device on which you would like to install Qubes OS.

From 54ce8c2f4ae86f434a0f1036eddad3924ce26166 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Thu, 5 Sep 2024 06:18:08 -0700
Subject: [PATCH 209/332] Add NovaCustom V56 Series to certified computer list

---
 user/hardware/certified-hardware.md | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/user/hardware/certified-hardware.md b/user/hardware/certified-hardware.md
index a5ef3789..10aee505 100644
--- a/user/hardware/certified-hardware.md
+++ b/user/hardware/certified-hardware.md
@@ -25,53 +25,59 @@ Qubes-certified computers are certified for a [major release](/doc/version-schem
 
 The current Qubes-certified models are listed below in reverse chronological order of certification.
 
+### NovaCustom V56 Series 16.0 inch coreboot laptop
+
+[![Photo of the NovaCustom V56 Series 16.0 inch coreboot laptop](/attachment/site/novacustom-v56-series.png)](https://novacustom.com/product/nv41-series/)
+
+The [NovaCustom V56 Series 16.0 inch coreboot laptop](https://novacustom.com/product/v56-series/) is certified for Qubes OS Release 4.
+
 ### NitroPC Pro 2
 
 [![Photo of the NitroPC Pro 2](/attachment/posts/nitropc-pro.jpg)](https://shop.nitrokey.com/shop/nitropc-pro-2-523)
 
-The [NitroPC Pro 2](https://shop.nitrokey.com/shop/nitropc-pro-2-523) is a desktop based on the MSI PRO Z790-P DDR5 motherboard. It is certified for Qubes OS 4.
+The [NitroPC Pro 2](https://shop.nitrokey.com/shop/nitropc-pro-2-523) is a desktop based on the MSI PRO Z790-P DDR5 motherboard. It is certified for Qubes OS Release 4.
 
 ### Star Labs StarBook
 
 [![Photo of the Star Labs StarBook](/attachment/site/starlabs-starbook.png)](https://starlabs.systems/pages/starbook)
 
-The [Star Labs StarBook](https://starlabs.systems/pages/starbook) is a 14-inch laptop. It is certified for Qubes OS 4.
+The [Star Labs StarBook](https://starlabs.systems/pages/starbook) is a 14-inch laptop. It is certified for Qubes OS Release 4.
 
 ### NitroPC Pro
 
 [![Photo of the NitroPC Pro](/attachment/posts/nitropc-pro.jpg)](https://shop.nitrokey.com/shop/product/nitropc-pro-523)
 
-The [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523) is a desktop based on the MSI PRO Z690-A DDR5 motherboard. It is certified for Qubes OS 4.
+The [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523) is a desktop based on the MSI PRO Z690-A DDR5 motherboard. It is certified for Qubes OS Release 4.
 
 ### NovaCustom NV41 Series
 
 [![Photo of the NovaCustom NV41 Series](/attachment/site/novacustom-nv41-series.png)](https://novacustom.com/product/nv41-series/)
 
-The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is a 14-inch custom laptop. It is certified for Qubes OS 4.
+The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is a 14-inch custom laptop. It is certified for Qubes OS Release 4.
 
 ### Dasharo FidelisGuard Z690
 
 [![Photo of the Dasharo FidelisGuard Z690](/attachment/site/dasharo-fidelisguard-z690.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
 
-The [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is a desktop based on the MSI PRO Z690-A DDR4 motherboard. It is certified for Qubes OS 4.
+The [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is a desktop based on the MSI PRO Z690-A DDR4 motherboard. It is certified for Qubes OS Release 4.
 
 ### NitroPad T430
 
 [![Photo of the NitroPad T430](/attachment/site/nitropad-t430.jpg)](https://shop.nitrokey.com/shop/product/nitropad-t430-119)
 
-The [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119) is a laptop based on the ThinkPad T430. It is certified for Qubes OS 4.
+The [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119) is a laptop based on the ThinkPad T430. It is certified for Qubes OS Release 4.
 
 ### NitroPad X230
 
 [![Photo of the NitroPad X230](/attachment/site/nitropad-x230.jpg)](https://shop.nitrokey.com/shop/product/nitropad-x230-67)
 
-The [NitroPad X230](https://shop.nitrokey.com/shop/product/nitropad-x230-67) is a laptop based on the ThinkPad X230. It is certified for Qubes OS 4.
+The [NitroPad X230](https://shop.nitrokey.com/shop/product/nitropad-x230-67) is a laptop based on the ThinkPad X230. It is certified for Qubes OS Release 4.
 
 ### Insurgo PrivacyBeast X230
 
 [![Photo of the Insurgo PrivacyBeast X230](/attachment/site/insurgo-privacybeast-x230.png)](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/)
 
-The [Insurgo PrivacyBeast X230](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/) is a laptop based on the ThinkPad X230. It is certified for Qubes OS 4.
+The [Insurgo PrivacyBeast X230](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/) is a laptop based on the ThinkPad X230. It is certified for Qubes OS Release 4.
 
 ## Become hardware certified
 

From 4d98540a5e0a27ece1bb8abb5460d3ef80b69105 Mon Sep 17 00:00:00 2001
From: vysotskylev <11317846+vysotskylev@users.noreply.github.com>
Date: Fri, 6 Sep 2024 20:28:34 +0200
Subject: [PATCH 210/332] Fix typo in how-to-install-software.md

---
 user/how-to-guides/how-to-install-software.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/how-to-guides/how-to-install-software.md b/user/how-to-guides/how-to-install-software.md
index da7aae0e..be3ee664 100644
--- a/user/how-to-guides/how-to-install-software.md
+++ b/user/how-to-guides/how-to-install-software.md
@@ -429,7 +429,7 @@ these in an app qube you need to take the following steps:
    When the install is complete you can close the terminal window.
 
 3. Refresh the Applications list for the app qube. In the Qubes Menu for the
-   **app qube*** launch the Qube Settings. Then go to the Applications tab and
+   **app qube** launch the Qube Settings. Then go to the Applications tab and
    click "Refresh Applications"
 
    The refresh will take a few minutes; after it's complete the Snap app will

From 6c32c9dc4e33d16758540241f35d523d2434b181 Mon Sep 17 00:00:00 2001
From: qm <3440586+qm@users.noreply.github.com>
Date: Thu, 12 Sep 2024 09:50:01 -0400
Subject: [PATCH 211/332] preparation for rst conversion

---
 introduction/getting-started.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/introduction/getting-started.md b/introduction/getting-started.md
index 93833e45..4c06d62a 100644
--- a/introduction/getting-started.md
+++ b/introduction/getting-started.md
@@ -150,7 +150,7 @@ All aspects of Qubes OS can be controlled using command-line tools. Opening a
 terminal emulator in dom0 can be done in several ways:
 
 - Go to the App Menu and select **Terminal Emulator** at the top.
-- Press `Alt`+`F3` and search for `xfce terminal`.
+- Press `Alt` + `F3` and search for `xfce terminal`.
 - Right-click on the desktop and select **Open Terminal Here**.
 
 Terminal emulators can also be run in other qubes as normal programs. Various

From 3006e841f84400c85769334b6d36847c3e4ccd76 Mon Sep 17 00:00:00 2001
From: qm <3440586+qm@users.noreply.github.com>
Date: Thu, 12 Sep 2024 14:58:55 -0400
Subject: [PATCH 212/332] preparation for rst conversion

---
 introduction/support.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/introduction/support.md b/introduction/support.md
index a21b73cf..b41765da 100644
--- a/introduction/support.md
+++ b/introduction/support.md
@@ -499,11 +499,11 @@ too](https://forum.qubes-os.org/t/using-the-forum-via-email/533)!)
 
 The Qubes OS Project has a presence on the following social media platforms:
 
-- <a rel="me" href="https://twitter.com/QubesOS">Twitter</a>
-- <a rel="me" href="https://mastodon.social/@QubesOS">Mastodon</a>
-- <a rel="me" href="https://www.reddit.com/r/Qubes/">Reddit</a>
-- <a rel="me" href="https://www.facebook.com/QubesOS/">Facebook</a>
-- <a rel="me" href="https://www.linkedin.com/company/qubes-os/">LinkedIn</a>
+- [Twitter](https://twitter.com/QubesOS)
+- [Mastodon](https://mastodon.social/@QubesOS)
+- [Reddit](https://www.reddit.com/r/Qubes/)
+- [Facebook](https://www.facebook.com/QubesOS/)
+- [LinkedIn](https://www.linkedin.com/company/qubes-os/)
 
 Generally speaking, these are not intended to be primary support venues. (Those
 would be [qubes-users](#qubes-users) and the [forum](#forum).) Rather, these

From a086123e56d2993762dc5484492fd2092f611deb Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Tue, 17 Sep 2024 19:14:37 -0700
Subject: [PATCH 213/332] Fix link

---
 user/hardware/certified-hardware.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/hardware/certified-hardware.md b/user/hardware/certified-hardware.md
index 10aee505..be7ff693 100644
--- a/user/hardware/certified-hardware.md
+++ b/user/hardware/certified-hardware.md
@@ -27,7 +27,7 @@ The current Qubes-certified models are listed below in reverse chronological ord
 
 ### NovaCustom V56 Series 16.0 inch coreboot laptop
 
-[![Photo of the NovaCustom V56 Series 16.0 inch coreboot laptop](/attachment/site/novacustom-v56-series.png)](https://novacustom.com/product/nv41-series/)
+[![Photo of the NovaCustom V56 Series 16.0 inch coreboot laptop](/attachment/site/novacustom-v56-series.png)](https://novacustom.com/product/nv56-series/)
 
 The [NovaCustom V56 Series 16.0 inch coreboot laptop](https://novacustom.com/product/v56-series/) is certified for Qubes OS Release 4.
 

From fa335c4ed5d7f1406f7474d42cb76d11f4a55c40 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Tue, 17 Sep 2024 19:20:36 -0700
Subject: [PATCH 214/332] Fix link

---
 user/hardware/certified-hardware.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/hardware/certified-hardware.md b/user/hardware/certified-hardware.md
index be7ff693..f6c6fd43 100644
--- a/user/hardware/certified-hardware.md
+++ b/user/hardware/certified-hardware.md
@@ -27,7 +27,7 @@ The current Qubes-certified models are listed below in reverse chronological ord
 
 ### NovaCustom V56 Series 16.0 inch coreboot laptop
 
-[![Photo of the NovaCustom V56 Series 16.0 inch coreboot laptop](/attachment/site/novacustom-v56-series.png)](https://novacustom.com/product/nv56-series/)
+[![Photo of the NovaCustom V56 Series 16.0 inch coreboot laptop](/attachment/site/novacustom-v56-series.png)](https://novacustom.com/product/v56-series/)
 
 The [NovaCustom V56 Series 16.0 inch coreboot laptop](https://novacustom.com/product/v56-series/) is certified for Qubes OS Release 4.
 

From bfbad2b1860233ae16db1bbe75cbfb3c51e537fe Mon Sep 17 00:00:00 2001
From: qm <3440586+qm@users.noreply.github.com>
Date: Fri, 20 Sep 2024 13:00:42 -0400
Subject: [PATCH 215/332] removed a TODO comment for better rst conversion

---
 developer/services/qrexec.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/developer/services/qrexec.md b/developer/services/qrexec.md
index fbdc7327..4ee41d98 100644
--- a/developer/services/qrexec.md
+++ b/developer/services/qrexec.md
@@ -238,7 +238,6 @@ This means it is possible to install a different script for a particular service
 
 See [below](#rpc-service-with-argument-file-reader) for an example of an RPC service using an argument.
 
-<!-- TODO document "Yes to All" authorization if it is reintroduced -->
 
 ## Qubes RPC examples
 

From 1ffc54d84b2d887b656d58c3ef7ded1ded773955 Mon Sep 17 00:00:00 2001
From: qm <3440586+qm@users.noreply.github.com>
Date: Fri, 20 Sep 2024 13:15:36 -0400
Subject: [PATCH 216/332] fixed list for better rst conversion

---
 project-security/verifying-signatures.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/project-security/verifying-signatures.md b/project-security/verifying-signatures.md
index 5a474674..8d6a4a7d 100644
--- a/project-security/verifying-signatures.md
+++ b/project-security/verifying-signatures.md
@@ -833,6 +833,7 @@ the arguments to `gpg2`. (The signature file goes first.)
 ### Why am I getting "WARNING: This key is not certified with a trusted signature! There is no indication that the signature belongs to the owner."?
 
 There are several possibilities:
+
 - You don't have the [Qubes Master Signing
   Key](#how-to-import-and-authenticate-the-qubes-master-signing-key).
 - You have not [set the Qubes Master Signing Key's trust level

From 63bf921aa6179d0d96215a8a252daaaa3ef5d3ca Mon Sep 17 00:00:00 2001
From: "Dr. Gerhard Weck" <GerhardWeck@online.de>
Date: Sat, 21 Sep 2024 13:27:20 +0200
Subject: [PATCH 217/332] Formal change

---
 user/templates/windows/windows-qubes-4-1.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/templates/windows/windows-qubes-4-1.md b/user/templates/windows/windows-qubes-4-1.md
index 62210c0a..84bf67ff 100644
--- a/user/templates/windows/windows-qubes-4-1.md
+++ b/user/templates/windows/windows-qubes-4-1.md
@@ -237,7 +237,7 @@ Moving the user data is not directly possible under Windows, because the directo
 
 - If Qubes Windows Tools is installed, the option `Move User Profiles` has to be selected on the installation. In this case, the user files are moved to the new disk during the reboot at the end of the installation.
 
-- This can also be accomplished without QWT installation, avoiding the installation of the Xen PV drivers, if the risk of a compromised version of these drivers according to QSB-091 is considered too severe. In this case, the file `relocate_dir.exe` has to be extracted from the QWT installer kit `qubes-tools-x64.msi`, which will be shown as the content of the CDROM made available by starting the Windows qube with the additional option `--install-windows-tools` (see the QWT installation documentation). The installer kit is a specially formatted archive, from which the file `relocate_dir.exe` can be extracted using a utility like 7-Zip. The file has then to be copied to `%windir%\system32`, i.e. usually `C:\Windows\system32`. Furthermore, locate the registry key `HKLM\SYSTEM\CurrentControlSet\Control\Session Manager`, and add the text `relocate_dir.exe C:\Users Q:\Users` as a new line to the REG_MULTI_SZ-value `\BootExecute` in this key. On rebooting the Windows qube, the user files will be moved to the disk `Q:`, and the additional registry entry will be removed, such that this action occurs only once.
+- This can also be accomplished without QWT installation, avoiding the installation of the Xen PV drivers, if the risk of a compromised version of these drivers according to QSB-091 is considered too severe. In this case, the file `relocate_dir.exe` has to be extracted from the QWT installer kit `qubes-tools-x64.msi`, which will be shown as the content of the CDROM made available by starting the Windows qube with the additional option `--install-windows-tools` (see the QWT installation documentation). The installer kit is a specially formatted archive, from which the file `relocate_dir.exe` can be extracted using a utility like 7-Zip. The file has then to be copied to `%windir%\system32`, i.e. usually `C:\Windows\system32`. Furthermore, locate the registry key `HKLM\SYSTEM\CurrentControlSet\Control\Session Manager`, and add the text `relocate_dir.exe C:\Users Q:\Users` as a new line to the `REG_MULTI_SZ` value `\BootExecute` in this key. On rebooting the Windows qube, the user files will be moved to the disk `Q:`, and the additional registry entry will be removed, such that this action occurs only once.
 
 If the user data have been moved to `Q:`, be sure not to user the option `Move User Profeiles`on subsequent installations of Qubes Windows tools.
 

From b330828152d9b1ebe070d1cb066c8d8d91bf57bf Mon Sep 17 00:00:00 2001
From: Tobias Killer <tokidev@posteo.de>
Date: Sat, 21 Sep 2024 19:34:01 +0200
Subject: [PATCH 218/332] Reformat for better conversion to RST

- essentially concerning the newline issue in lists
---
 introduction/issue-tracking.md                |  4 +-
 .../upgrade/3_1.md                            | 10 +--
 .../how-to-back-up-restore-and-migrate.md     | 66 ++++++++---------
 user/how-to-guides/how-to-install-software.md |  8 +--
 .../how-to-reinstall-a-template.md            | 10 +--
 .../how-to-use-block-storage-devices.md       | 12 ++--
 user/security-in-qubes/data-leaks.md          |  8 +--
 user/security-in-qubes/firewall.md            | 18 ++---
 user/security-in-qubes/split-gpg.md           | 70 +++++++++----------
 user/troubleshooting/uefi-troubleshooting.md  |  1 +
 .../troubleshooting/update-troubleshooting.md |  1 +
 11 files changed, 105 insertions(+), 103 deletions(-)

diff --git a/introduction/issue-tracking.md b/introduction/issue-tracking.md
index 13ebb449..d628b3d4 100644
--- a/introduction/issue-tracking.md
+++ b/introduction/issue-tracking.md
@@ -96,12 +96,12 @@ Meta-issues must abide by the following rules:
 - Only members of the core team may create meta-issues (or convert existing issues into meta-issues).
 
 
-  Rationale: The purpose of meta-issues is to track the development of certain features that fit into the overall goals of the Qubes OS Project, which requires making informed project-management decisions with the approval of the project lead.
+  - Rationale: The purpose of meta-issues is to track the development of certain features that fit into the overall goals of the Qubes OS Project, which requires making informed project-management decisions with the approval of the project lead.
 
 - Meta-issues must be [locked](https://docs.github.com/en/communities/moderating-comments-and-conversations/locking-conversations).
 
 
-  Rationale: One of the historical problems we've experienced with meta-issues (and one of the reasons they were discouraged for a long time) is that each meta-issue tends to turn into a discussion thread that becomes hopelessly long to the point where the person who is supposed to work on it has no idea what is supposed to be done or where to start, and it eventually just gets closed. Locking is intended to prevent that from happening again.
+  - Rationale: One of the historical problems we've experienced with meta-issues (and one of the reasons they were discouraged for a long time) is that each meta-issue tends to turn into a discussion thread that becomes hopelessly long to the point where the person who is supposed to work on it has no idea what is supposed to be done or where to start, and it eventually just gets closed. Locking is intended to prevent that from happening again.
 
 - Meta-issues must have informative descriptions, not just lists of issues. In particular, each meta-issue should explain its goal, what is in scope, and what the relevant categories and priorities are.
 
diff --git a/user/downloading-installing-upgrading/upgrade/3_1.md b/user/downloading-installing-upgrading/upgrade/3_1.md
index 40aff365..09b67956 100644
--- a/user/downloading-installing-upgrading/upgrade/3_1.md
+++ b/user/downloading-installing-upgrading/upgrade/3_1.md
@@ -98,11 +98,11 @@ complete.
 
 4. Reboot dom0.
     
-    The system may hang during the reboot. If that happens, do not panic. All
-    the filesystems will have already been unmounted at this stage, so you can
-    simply perform a hard reboot (e.g., hold the physical power button down
-    until the machine shuts off, wait a moment, then press it again to start it
-    back up).
+   - The system may hang during the reboot. If that happens, do not panic. All
+     the filesystems will have already been unmounted at this stage, so you can
+     simply perform a hard reboot (e.g., hold the physical power button down
+     until the machine shuts off, wait a moment, then press it again to start it
+     back up).
 
 Please note that if you use [Anti Evil Maid](/doc/anti-evil-maid), it won't be
 able to unseal the passphrase the first time the system boots after performing
diff --git a/user/how-to-guides/how-to-back-up-restore-and-migrate.md b/user/how-to-guides/how-to-back-up-restore-and-migrate.md
index fa33d83e..0cb0ef5a 100644
--- a/user/how-to-guides/how-to-back-up-restore-and-migrate.md
+++ b/user/how-to-guides/how-to-back-up-restore-and-migrate.md
@@ -53,44 +53,44 @@ fresh installation.
 2. Move the VMs that you want to back up to the right-hand **Selected** column.
    VMs in the left-hand **Available** column will not be backed up.
 
-   You may choose whether to compress backups by checking or unchecking the
-   **Compress the backup** box. Normally this should be left on unless you have
-   a specific reason otherwise.
+   - You may choose whether to compress backups by checking or unchecking the
+     **Compress the backup** box. Normally this should be left on unless you have
+     a specific reason otherwise.
 
-   Once you have selected all desired VMs, click **Next**.
+   - Once you have selected all desired VMs, click **Next**.
 
 3. Select the destination for the backup:
 
-   If you wish to send your backup to a (currently running) VM, select the VM
-   in the drop-down box next to **Target app qube**. If you wish to send your
-   backup to a [USB mass storage device](/doc/usb/), you can use the directory
-   selection widget to mount a connected device (under "Other locations" item
-   on the left); or first mount the device in a VM, then select the mount point
-   inside that VM as the backup destination.
+   - If you wish to send your backup to a (currently running) VM, select the VM
+     in the drop-down box next to **Target app qube**. If you wish to send your
+     backup to a [USB mass storage device](/doc/usb/), you can use the directory
+     selection widget to mount a connected device (under "Other locations" item
+     on the left); or first mount the device in a VM, then select the mount point
+     inside that VM as the backup destination.
 
-   You must also specify a directory on the device or in the VM, or a command
-   to be executed in the VM as a destination for your backup. For example, if
-   you wish to send your backup to the `~/backups` folder in the target VM, you
-   would simply browse to it using the convenient directory selection dialog
-   (`...`) at the right. This destination directory must already exist. If it
-   does not exist, you must create it manually prior to backing up.
+   - You must also specify a directory on the device or in the VM, or a command
+     to be executed in the VM as a destination for your backup. For example, if
+     you wish to send your backup to the `~/backups` folder in the target VM, you
+     would simply browse to it using the convenient directory selection dialog
+     (`...`) at the right. This destination directory must already exist. If it
+     does not exist, you must create it manually prior to backing up.
 
-   By specifying the appropriate directory as the destination in a VM, it is
-   possible to send the backup directly to, e.g., a USB mass storage device
-   attached to the VM. Likewise, it is possible to enter any command as a
-   backup target by specifying the command as the destination in the VM. This
-   can be used to send your backup directly to, e.g., a remote server using
-   SSH.
+   - By specifying the appropriate directory as the destination in a VM, it is
+     possible to send the backup directly to, e.g., a USB mass storage device
+     attached to the VM. Likewise, it is possible to enter any command as a
+     backup target by specifying the command as the destination in the VM. This
+     can be used to send your backup directly to, e.g., a remote server using
+     SSH.
 
-   **Note:** The supplied passphrase is used for **both** encryption/decryption
-   and integrity verification.
+   - **Note:** The supplied passphrase is used for **both** encryption/decryption
+     and integrity verification.
 
-   At this point, you may also choose whether to save your settings by checking
-   or unchecking the **Save settings as default backup profile** box.
+   - At this point, you may also choose whether to save your settings by checking
+     or unchecking the **Save settings as default backup profile** box.
 
-   **Warning: Saving the settings will result in your backup passphrase being
-   saved in plaintext in dom0, so consider your threat model before checking
-   this box.**
+   - **Warning: Saving the settings will result in your backup passphrase being
+     saved in plaintext in dom0, so consider your threat model before checking
+     this box.**
 
 4. You will now see the summary of VMs to be backed up. If there are any issues
    preventing the backup, they will be listed here and the **Next** button
@@ -148,10 +148,10 @@ fresh installation.
 a passphrase was supplied during the creation of your backup (regardless of
 whether it is encrypted), then you must supply it here.
 
-   **Note:** The passphrase which was supplied when the backup was created is
-   used for **both** encryption/decryption and integrity verification. If the
-   backup was not encrypted, the supplied passphrase is used only for integrity
-   verification. All backups made from a Qubes R4.0 system will be encrypted.
+   - **Note:** The passphrase which was supplied when the backup was created is
+     used for **both** encryption/decryption and integrity verification. If the
+     backup was not encrypted, the supplied passphrase is used only for integrity
+     verification. All backups made from a Qubes R4.0 system will be encrypted.
 
 5. You will now see the summary of VMs to be restored. If there are any issues
 preventing the restore, they will be listed here and the **Next** button grayed
diff --git a/user/how-to-guides/how-to-install-software.md b/user/how-to-guides/how-to-install-software.md
index da7aae0e..9a156b93 100644
--- a/user/how-to-guides/how-to-install-software.md
+++ b/user/how-to-guides/how-to-install-software.md
@@ -432,10 +432,10 @@ these in an app qube you need to take the following steps:
    **app qube*** launch the Qube Settings. Then go to the Applications tab and
    click "Refresh Applications"
 
-   The refresh will take a few minutes; after it's complete the Snap app will
-   appear in the app qube's list of available applications. At this point the
-   snap will be persistent within the app qube and will receive updates when
-   the app qube is running.
+   - The refresh will take a few minutes; after it's complete the Snap app will
+     appear in the app qube's list of available applications. At this point the
+     snap will be persistent within the app qube and will receive updates when
+     the app qube is running.
 
 
 ### Autostarting Installed Applications
diff --git a/user/how-to-guides/how-to-reinstall-a-template.md b/user/how-to-guides/how-to-reinstall-a-template.md
index baf99ce7..f7d803bf 100644
--- a/user/how-to-guides/how-to-reinstall-a-template.md
+++ b/user/how-to-guides/how-to-reinstall-a-template.md
@@ -49,15 +49,15 @@ If you want to reinstall more than one template, repeat these instructions for e
 1. Clone the existing target template.
 
 
-   This can be a good idea if you've customized the existing template and want to keep your customizations.
-   On the other hand, if you suspect that this template is broken, misconfigured, or compromised, be certain you do not start any VMs using it in the below procedure.
+   - This can be a good idea if you've customized the existing template and want to keep your customizations.
+     On the other hand, if you suspect that this template is broken, misconfigured, or compromised, be certain you do not start any VMs using it in the below procedure.
 
 2. Temporarily change all VMs based on the target template to the new clone template, or remove them.
 
 
-   This can be a good idea if you have user data in these VMs that you want to keep.
-   On the other hand, if you suspect that these VMs (or the templates on which they are based) are broken, misconfigured, or compromised, you may want to remove them instead.
-   You can do this in Qubes Manager by right-clicking on the VM and clicking **Remove VM**, or you can use the command `qvm-remove <vm-name>` in dom0.
+   - This can be a good idea if you have user data in these VMs that you want to keep.
+     On the other hand, if you suspect that these VMs (or the templates on which they are based) are broken, misconfigured, or compromised, you may want to remove them instead.
+     You can do this in Qubes Manager by right-clicking on the VM and clicking **Remove VM**, or you can use the command `qvm-remove <vm-name>` in dom0.
 
 3. Uninstall the target template from dom0:
 
diff --git a/user/how-to-guides/how-to-use-block-storage-devices.md b/user/how-to-guides/how-to-use-block-storage-devices.md
index 5658682a..a46f1a8e 100644
--- a/user/how-to-guides/how-to-use-block-storage-devices.md
+++ b/user/how-to-guides/how-to-use-block-storage-devices.md
@@ -90,9 +90,9 @@ If you don't see anything that looks like your drive, run `sudo udevadm trigger
     qvm-block attach work sys-usb:sdb
     ```
 
-    This will attach the device to the qube as `/dev/xvdi` if that name is not already taken by another attached device, or `/dev/xvdj`, etc.
+    - This will attach the device to the qube as `/dev/xvdi` if that name is not already taken by another attached device, or `/dev/xvdj`, etc.
 
-    You may also mount one partition at a time by using the same command with the partition number, e.g. `sdb1`.
+    - You may also mount one partition at a time by using the same command with the partition number, e.g. `sdb1`.
 
 3. The block device is now attached to the qube.
    If using a default qube, you may open the Nautilus file manager in the qube, and your drive should be visible in the **Devices** panel on the left.
@@ -106,7 +106,7 @@ If you don't see anything that looks like your drive, run `sudo udevadm trigger
 
 4. When you finish using the block device, click the eject button or right-click and select **Unmount**.
 
-    If you've manually mounted a single partition in the above step, use:
+    - If you've manually mounted a single partition in the above step, use:
 
     ```
     sudo umount mnt
@@ -179,10 +179,10 @@ To attach a file as block device to another qube, first turn it into a loopback
 2. If you want to use the GUI, you're done.
     Click the Device Manager ![device manager icon](/attachment/doc/media-removable.png) and select the `loop0`-device to attach it to another qube.
 
-    If you rather use the command line, continue:
+    - If you rather use the command line, continue:
 
-    In dom0, run `qvm-block` to display known block devices.
-    The newly created loop device should show up:
+    - In dom0, run `qvm-block` to display known block devices.
+      The newly created loop device should show up:
 
     ```shell_session
     ~]$ qvm-block
diff --git a/user/security-in-qubes/data-leaks.md b/user/security-in-qubes/data-leaks.md
index 82b736e7..bae9ad7d 100644
--- a/user/security-in-qubes/data-leaks.md
+++ b/user/security-in-qubes/data-leaks.md
@@ -49,9 +49,9 @@ Such attacks have been described in the academic literature, but it is doubtful
    For example, software which automatically sends error reports to a remote server, where these reports contain details about the system which the user did not want to share.
 
 
-   Both Qubes firewall and an empty NetVM (i.e., setting the NetVM of an app qube to "none") can fully protect against leaks of type 3.
-   However, neither Qubes firewall nor an empty NetVM are guaranteed to protect against leaks of types 1 and 2.
-   There are few effective, practical policy measures available to end-users today to stop the leaks of type 1.
-   It is likely that the only way to fully protect against leaks of type 2 is to either pause or shut down all other VMs while performing sensitive operations in the target VM(s) (such as key generation).
+Both Qubes firewall and an empty NetVM (i.e., setting the NetVM of an app qube to "none") can fully protect against leaks of type 3.
+However, neither Qubes firewall nor an empty NetVM are guaranteed to protect against leaks of types 1 and 2.
+There are few effective, practical policy measures available to end-users today to stop the leaks of type 1.
+It is likely that the only way to fully protect against leaks of type 2 is to either pause or shut down all other VMs while performing sensitive operations in the target VM(s) (such as key generation).
 
 For further discussion, see [this thread](https://groups.google.com/d/topic/qubes-users/t0cmNfuVduw/discussion).
diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index a94f087a..558a34aa 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -165,7 +165,7 @@ Consider the following example. `mytcp-service` qube has a TCP service running o
     [user@untrusted #]$ qvm-connect-tcp 444:@default:444
     ~~~
 
-> Note: The syntax is the same as SSH tunnel handler. The first `444` correspond to the localport destination of `untrusted`, `@default` the remote machine and the second `444` to the remote machine port.
+- **Note:** The syntax is the same as SSH tunnel handler. The first `444` correspond to the localport destination of `untrusted`, `@default` the remote machine and the second `444` to the remote machine port.
 
 The service of `mytcp-service` running on port `444` is now accessible in `untrusted` as `localhost:444`.
 
@@ -263,9 +263,9 @@ In order to allow a service present in a qube to be exposed to the outside world
 
 As an example we can take the use case of qube QubeDest running a web server listening on port 443 that we want to expose on our physical interface ens6, but only to our local network 192.168.x.y/24.
 
-> Note: To have all interfaces available and configured, make sure the 3 qubes are up and running
+- **Note:** To have all interfaces available and configured, make sure the 3 qubes are up and running
 
-> Note: [Issue #4028](https://github.com/QubesOS/qubes-issues/issues/4028) discusses adding a command to automate exposing the port.
+- **Note:** [Issue #4028](https://github.com/QubesOS/qubes-issues/issues/4028) discusses adding a command to automate exposing the port.
 
 **1. Identify the IP addresses you will need to use for sys-net, sys-firewall and the destination qube.**
 
@@ -278,7 +278,7 @@ You can get this information using various methods, but only the first one can b
 
 Note the IP addresses you will need, they will be required in the next steps.
 
-> Note: The vifx.0 interface is the one used by qubes connected to this netvm so it is _not_ an outside world interface.
+- **Note:** The vifx.0 interface is the one used by qubes connected to this netvm so it is _not_ an outside world interface.
 
 **2. Route packets from the outside world to the FirewallVM**
 
@@ -290,9 +290,9 @@ In the sys-net VM's Terminal, the first step is to define an ntables chain that
 nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
 ```
 
-> Note: the name `custom-dnat-qubeDST` is arbitrary
+- **Note:** the name `custom-dnat-qubeDST` is arbitrary
 
-> Note: while we use a DNAT chain for a single qube, it's totally possible to have a single DNAT chain for multiple qubes
+- **Note:** while we use a DNAT chain for a single qube, it's totally possible to have a single DNAT chain for multiple qubes
 
 Second step, code a natting firewall rule to route traffic on the outside interface for the service to the sys-firewall VM
 
@@ -306,9 +306,9 @@ Third step, code the appropriate new filtering firewall rule to allow new connec
 nft add rule qubes custom-forward iif == "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
 ```
 
-> Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
+- **Note:** If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
 
-> If you want to expose the service on multiple interfaces, repeat the steps 2 and 3 described above, for each interface. Alternatively, you can leave out the interface completely.
+- If you want to expose the service on multiple interfaces, repeat the steps 2 and 3 described above, for each interface. Alternatively, you can leave out the interface completely.
 
 Verify the rules on sys-net firewall correctly match the packets you want by looking at its counters, check for the counter lines in the chains `custom-forward` and `custom-dnat-qubeDEST`:
 
@@ -380,7 +380,7 @@ Third step, code the appropriate new filtering firewall rule to allow new connec
 nft add rule qubes custom-forward iif == "eth0" ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
 ```
 
-> Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
+- **Note:** If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
 
 Once you have confirmed that the counters increase, store these commands in the script `/rw/config/qubes-firewall-user-script`
 
diff --git a/user/security-in-qubes/split-gpg.md b/user/security-in-qubes/split-gpg.md
index f13b5ff5..afaf37e9 100644
--- a/user/security-in-qubes/split-gpg.md
+++ b/user/security-in-qubes/split-gpg.md
@@ -298,64 +298,64 @@ In this example, the following keys are stored in the following locations (see b
 * `sec` (master secret key)
 
 
-   Depending on your needs, you may wish to create this as a **certify-only (C)** key, i.e., a key which is capable only of signing (a.k.a., "certifying") other keys.
-   This key may be created *without* an expiration date.
-   This is for two reasons.
-   First, the master secret key is never to leave the `vault` VM, so it is extremely unlikely ever to be obtained by an adversary (see below).
-   Second, an adversary who *does* manage to obtain the master secret key either possesses the passphrase to unlock the key (if one is used) or does not.
-   An adversary who *does* possess the passphrase can simply use it to legally extend the expiration date of the key (or remove it entirely).
-   An adversary who does *not* possess the passphrase cannot use the key at all.
-   In either case, an expiration date provides no additional benefit.
+   * Depending on your needs, you may wish to create this as a **certify-only (C)** key, i.e., a key which is capable only of signing (a.k.a., "certifying") other keys.
+     This key may be created *without* an expiration date.
+     This is for two reasons.
+     First, the master secret key is never to leave the `vault` VM, so it is extremely unlikely ever to be obtained by an adversary (see below).
+     Second, an adversary who *does* manage to obtain the master secret key either possesses the passphrase to unlock the key (if one is used) or does not.
+     An adversary who *does* possess the passphrase can simply use it to legally extend the expiration date of the key (or remove it entirely).
+     An adversary who does *not* possess the passphrase cannot use the key at all.
+     In either case, an expiration date provides no additional benefit.
 
-   By the same token, however, having a passphrase on the key is of little value.
-   An adversary who is capable of stealing the key from your `vault` would almost certainly also be capable of stealing the passphrase as you enter it.
-   An adversary who obtains the passphrase can then use it in order to change or remove the passphrase from the key.
-   Therefore, using a passphrase at all should be considered optional.
-   It is, however, recommended that a **revocation certificate** be created and safely stored in multiple locations so that the master keypair can be revoked in the (exceedingly unlikely) event that it is ever compromised.
+   * By the same token, however, having a passphrase on the key is of little value.
+     An adversary who is capable of stealing the key from your `vault` would almost certainly also be capable of stealing the passphrase as you enter it.
+     An adversary who obtains the passphrase can then use it in order to change or remove the passphrase from the key.
+     Therefore, using a passphrase at all should be considered optional.
+     It is, however, recommended that a **revocation certificate** be created and safely stored in multiple locations so that the master keypair can be revoked in the (exceedingly unlikely) event that it is ever compromised.
 
 * `ssb` (secret subkey)
 
 
-   Depending on your needs, you may wish to create two different subkeys: one for **signing (S)** and one for **encryption (E)**.
-   You may also wish to give these subkeys reasonable expiration dates (e.g., one year).
-   Once these keys expire, it is up to you whether to *renew* these keys by extending the expiration dates or to create *new* subkeys when the existing set expires.
+   * Depending on your needs, you may wish to create two different subkeys: one for **signing (S)** and one for **encryption (E)**.
+     You may also wish to give these subkeys reasonable expiration dates (e.g., one year).
+     Once these keys expire, it is up to you whether to *renew* these keys by extending the expiration dates or to create *new* subkeys when the existing set expires.
 
-   On the one hand, an adversary who obtains any existing encryption subkey (for example) will be able to use it in order to decrypt all emails (for example) which were encrypted to that subkey.
-   If the same subkey were to continue to be used--and its expiration date continually extended--only that one key would need to be stolen (e.g., as a result of the `work-gpg` VM being compromised; see below) in order to decrypt *all* of the user's emails.
-   If, on the other hand, each encryption subkey is used for at most approximately one year, then an adversary who obtains the secret subkey will be capable of decrypting at most approximately one year's worth of emails.
+   * On the one hand, an adversary who obtains any existing encryption subkey (for example) will be able to use it in order to decrypt all emails (for example) which were encrypted to that subkey.
+     If the same subkey were to continue to be used--and its expiration date continually extended--only that one key would need to be stolen (e.g., as a result of the `work-gpg` VM being compromised; see below) in order to decrypt *all* of the user's emails.
+     If, on the other hand, each encryption subkey is used for at most approximately one year, then an adversary who obtains the secret subkey will be capable of decrypting at most approximately one year's worth of emails.
 
-   On the other hand, creating a new signing subkey each year without renewing (i.e., extending the expiration dates of) existing signing subkeys would mean that all of your old signatures would eventually read as "EXPIRED" whenever someone attempts to verify them.
-   This can be problematic, since there is no consensus on how expired signatures should be handled.
-   Generally, digital signatures are intended to last forever, so this is a strong reason against regularly retiring one's signing subkeys.
+   * On the other hand, creating a new signing subkey each year without renewing (i.e., extending the expiration dates of) existing signing subkeys would mean that all of your old signatures would eventually read as "EXPIRED" whenever someone attempts to verify them.
+     This can be problematic, since there is no consensus on how expired signatures should be handled.
+     Generally, digital signatures are intended to last forever, so this is a strong reason against regularly retiring one's signing subkeys.
 
 * `pub` (public key)
 
 
-   This is the complement of the master secret key.
-   It can be uploaded to keyservers (or otherwise publicly distributed) and may be signed by others.
+   * This is the complement of the master secret key.
+     It can be uploaded to keyservers (or otherwise publicly distributed) and may be signed by others.
 
 * `vault`
 
 
-   This is a network-isolated VM.
-   The initial master keypair and subkeys are generated in this VM.
-   The master secret key *never* leaves this VM under *any* circumstances.
-   No files or text is *ever* [copied](/doc/how-to-copy-and-move-files/#security) or [pasted](/doc/how-to-copy-and-paste-text/#security) into this VM under *any* circumstances.
+   * This is a network-isolated VM.
+     The initial master keypair and subkeys are generated in this VM.
+     The master secret key *never* leaves this VM under *any* circumstances.
+     No files or text is *ever* [copied](/doc/how-to-copy-and-move-files/#security) or [pasted](/doc/how-to-copy-and-paste-text/#security) into this VM under *any* circumstances.
 
 * `work-gpg`
 
 
-   This is a network-isolated VM.
-   This VM is used *only* as the GPG backend for `work-email`.
-   The secret subkeys (but *not* the master secret key) are [copied](/doc/how-to-copy-and-move-files/#security) from the `vault` VM to this VM.
-   Files from less trusted VMs are *never* [copied](/doc/how-to-copy-and-move-files/#security) into this VM under *any* circumstances.
+   * This is a network-isolated VM.
+     This VM is used *only* as the GPG backend for `work-email`.
+     The secret subkeys (but *not* the master secret key) are [copied](/doc/how-to-copy-and-move-files/#security) from the `vault` VM to this VM.
+     Files from less trusted VMs are *never* [copied](/doc/how-to-copy-and-move-files/#security) into this VM under *any* circumstances.
 
 * `work-email`
 
 
-   This VM has access to the mail server.
-   It accesses the `work-gpg` VM via the Split GPG protocol.
-   The public key may be stored in this VM so that it can be attached to emails and for other such purposes.
+   * This VM has access to the mail server.
+     It accesses the `work-gpg` VM via the Split GPG protocol.
+     The public key may be stored in this VM so that it can be attached to emails and for other such purposes.
 
 ### Security Benefits
 
diff --git a/user/troubleshooting/uefi-troubleshooting.md b/user/troubleshooting/uefi-troubleshooting.md
index 35e33877..890fa091 100644
--- a/user/troubleshooting/uefi-troubleshooting.md
+++ b/user/troubleshooting/uefi-troubleshooting.md
@@ -23,6 +23,7 @@ If you've installed successfully in legacy mode but had to change some kernel pa
 04. Install using your modified boot entry
 
 **Change xen configuration directly in an iso image**
+
 01. Set up a loop device (replacing `X` with your ISO's version name): `losetup -P /dev/loop0 Qubes-RX-x86_64.iso`
 02. Mount the loop device: `sudo mount /dev/loop0p2 /mnt`
 03. Edit `EFI/BOOT/BOOTX64.cfg` to add your params to the `kernel` configuration key
diff --git a/user/troubleshooting/update-troubleshooting.md b/user/troubleshooting/update-troubleshooting.md
index 5cbcf081..60cc2fec 100644
--- a/user/troubleshooting/update-troubleshooting.md
+++ b/user/troubleshooting/update-troubleshooting.md
@@ -43,5 +43,6 @@ This can usually be fixed by updating via the command line.
 In dom0, open a terminal and run `sudo qubes-dom0-update`.
 
 Depending on your operating system, open a terminal in the templates and run:
+
 * Fedora: `sudo dnf upgrade`
 * Debian: `apt-get update && apt-get dist-upgrade`

From 8003064f511f4f65f721e9ed8480f18bd39f63be Mon Sep 17 00:00:00 2001
From: qm <3440586+qm@users.noreply.github.com>
Date: Sun, 22 Sep 2024 07:38:20 -0400
Subject: [PATCH 219/332] fixed identation in lists, created sublists of lists,
 minor formatting fixes

---
 developer/releases/4_2/release-notes.md       |  14 +-
 developer/services/admin-api.md               |   3 +-
 developer/services/qrexec-internals.md        |  62 ++++-----
 developer/system/gui.md                       |   4 +-
 user/advanced-topics/managing-vm-kernels.md   |   1 +
 .../backup-emergency-restore-v3.md            |  16 +--
 .../backup-emergency-restore-v4.md            |   6 +-
 user/security-in-qubes/data-leaks.md          |   1 -
 user/security-in-qubes/firewall.md            |  12 +-
 user/security-in-qubes/firewall_4.1.md        |  40 +++---
 user/security-in-qubes/mfa.md                 | 131 +++++++++---------
 user/security-in-qubes/split-gpg.md           |  18 +--
 .../windows/qubes-windows-tools-4-0.md        |  10 +-
 user/templates/windows/windows-qubes-4-1.md   |  40 +++---
 14 files changed, 171 insertions(+), 187 deletions(-)

diff --git a/developer/releases/4_2/release-notes.md b/developer/releases/4_2/release-notes.md
index 2590f55b..b5a34b80 100644
--- a/developer/releases/4_2/release-notes.md
+++ b/developer/releases/4_2/release-notes.md
@@ -56,17 +56,17 @@ We strongly recommend [updating Qubes OS](/doc/how-to-update/) immediately after
 
 - Qubes 4.2.2 includes a fix for [#8332: File-copy qrexec service is overly restrictive](https://github.com/QubesOS/qubes-issues/issues/8332). 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.
+  - 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.
+  - 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:
+  - 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
-  ```
+    ```
+    qubes.Filecopy    +allow-all-names    @anyvm    @anyvm    deny
+    ```
   
-  For more information, see [RPC policies](/doc/rpc-policy/) and [Qube configuration interface](/doc/vm-interface/#qubes-rpc).
+  - For more information, see [RPC policies](/doc/rpc-policy/) and [Qube configuration interface](/doc/vm-interface/#qubes-rpc).
 
 ## Download
 
diff --git a/developer/services/admin-api.md b/developer/services/admin-api.md
index 0087bcaf..495d9576 100644
--- a/developer/services/admin-api.md
+++ b/developer/services/admin-api.md
@@ -13,8 +13,7 @@ ref: 36
 title: Admin API
 ---
 
-_You may also be interested in the article
-[Introducing the Qubes Admin API](/news/2017/06/27/qubes-admin-api/)._
+_You may also be interested in the article [Introducing the Qubes Admin API](/news/2017/06/27/qubes-admin-api/)._
 
 ## Goals
 
diff --git a/developer/services/qrexec-internals.md b/developer/services/qrexec-internals.md
index 8f0a10ac..4c7fdf40 100644
--- a/developer/services/qrexec-internals.md
+++ b/developer/services/qrexec-internals.md
@@ -122,25 +122,25 @@ Details of all possible use cases and the messages involved are described below.
 
       qrexec-client -d domX [-l local_program] user:cmd
 
-  (If `local_program` is set, `qrexec-client` executes it and uses that child's stdin/stdout in place of its own when exchanging data with `qrexec-agent` later.)
+  - (If `local_program` is set, `qrexec-client` executes it and uses that child's stdin/stdout in place of its own when exchanging data with `qrexec-agent` later.)
 
-  `qrexec-client` translates that request into a `MSG_EXEC_CMDLINE` message sent to `qrexec-daemon`, with `connect_domain` set to 0 (connect to **dom0**) and `connect_port also set to 0 (allocate a port).
+  - `qrexec-client` translates that request into a `MSG_EXEC_CMDLINE` message sent to `qrexec-daemon`, with `connect_domain` set to 0 (connect to **dom0**) and `connect_port also set to 0 (allocate a port).
 
 - **dom0**: `qrexec-daemon` allocates a free port (in this case 513), and sends a `MSG_EXEC_CMDLINE` back to the client with connection parameters (**domX** and 513) and with command field empty.
 
-  `qrexec-client` disconnects from the daemon, starts a vchan server on port 513 and awaits connection.
+  - `qrexec-client` disconnects from the daemon, starts a vchan server on port 513 and awaits connection.
 
-  Then, `qrexec-daemon` passes on the request as `MSG_EXEC_CMDLINE` message to the `qrexec-agent` running in **domX**. In this case, the connection parameters are **dom0** and 513.
+  - Then, `qrexec-daemon` passes on the request as `MSG_EXEC_CMDLINE` message to the `qrexec-agent` running in **domX**. In this case, the connection parameters are **dom0** and 513.
 
 - **domX**: `qrexec-agent` receives `MSG_EXEC_CMDLINE`, and starts the command (`user:cmd`, or `cmd` as user `user`). If possible, this is actually delegated to a separate server (`qrexec-fork-server`) also running on domX.
 
-  After starting the command, `qrexec-fork-server` connects to `qrexec-client` in **dom0** over the provided vchan port 513.
+  - After starting the command, `qrexec-fork-server` connects to `qrexec-client` in **dom0** over the provided vchan port 513.
 
 - Data is forwarded between the `qrexec-client` in **dom0** and the command executed in **domX** using `MSG_DATA_STDIN`, `MSG_DATA_STDOUT` and `MSG_DATA_STDERR`.
 
-  Empty messages (with data `len` field set to 0 in `msg_header`) are an EOF marker. Peer receiving such message should close the associated input/output pipe.
+  - Empty messages (with data `len` field set to 0 in `msg_header`) are an EOF marker. Peer receiving such message should close the associated input/output pipe.
 
-  When `cmd` terminates, **domX**'s `qrexec-fork-server` sends `MSG_DATA_EXIT_CODE` header to `qrexec-client` followed by the exit code (**int**).
+  - When `cmd` terminates, **domX**'s `qrexec-fork-server` sends `MSG_DATA_EXIT_CODE` header to `qrexec-client` followed by the exit code (**int**).
 
 ### domX: request execution of service `admin.Service` in dom0
 
@@ -150,41 +150,41 @@ Details of all possible use cases and the messages involved are described below.
 
       qrexec-client-vm dom0 admin.Service [local_program] [params]
 
-  (If `local_program` is set, it will be executed in **domX** and connected to the remote command's stdin/stdout).
+  - (If `local_program` is set, it will be executed in **domX** and connected to the remote command's stdin/stdout).
 
-  `qrexec-client-vm` connects to `qrexec-agent` and requests service execution (`admin.Service`) in **dom0**.
+  - `qrexec-client-vm` connects to `qrexec-agent` and requests service execution (`admin.Service`) in **dom0**.
 
-  `qrexec-agent` assigns an internal identifier to the request. It's based on a file descriptor of the connected `qrexec-client-vm`: in this case, `SOCKET11`.
+  - `qrexec-agent` assigns an internal identifier to the request. It's based on a file descriptor of the connected `qrexec-client-vm`: in this case, `SOCKET11`.
 
-  `qrexec-agent` forwards the request (`MSG_TRIGGER_SERVICE3`) to its corresponding `qrexec-daemon` running in dom0.
+  - `qrexec-agent` forwards the request (`MSG_TRIGGER_SERVICE3`) to its corresponding `qrexec-daemon` running in dom0.
 
 - **dom0**: `qrexec-daemon` receives the request and triggers `qrexec-policy` program, passing all necessary parameters: source domain **domX**, target domain **dom0**, service `admin.Service` and identifier `SOCKET11`.
 
-  `qrexec-policy` evaluates if the RPC should be allowed or denied, possibly also launching a GUI confirmation prompt.
+  - `qrexec-policy` evaluates if the RPC should be allowed or denied, possibly also launching a GUI confirmation prompt.
 
-  (If the RPC is denied, it returns with exit code 1, in which case `qrexec-daemon` sends a `MSG_SERVICE_REFUSED` back).
+  - (If the RPC is denied, it returns with exit code 1, in which case `qrexec-daemon` sends a `MSG_SERVICE_REFUSED` back).
 
 - **dom0**: If the RPC is allowed, `qrexec-policy` will launch a `qrexec-client` with the right command:
 
       qrexec-client -d dom0 -c domX,X,SOCKET11 "QUBESRPC admin.Service domX name dom0"
 
-  The `-c domX,X,SOCKET11` are parameters indicating how connect back to **domX** and pass its input/output.
+  - The `-c domX,X,SOCKET11` are parameters indicating how connect back to **domX** and pass its input/output.
 
-  The command parameter describes the RPC call: it contains service name (`admin.Service`), source domain (`domX`) and target description (`name dom0`, could also be e.g. `keyword @dispvm`). The target description is important in case the original target wasn't dom0, but the service is executing in dom0.
+  - The command parameter describes the RPC call: it contains service name (`admin.Service`), source domain (`domX`) and target description (`name dom0`, could also be e.g. `keyword @dispvm`). The target description is important in case the original target wasn't dom0, but the service is executing in dom0.
 
-  `qrexec-client` connects to a `qrexec-daemon` for **domX** and sends a `MSG_SERVICE_CONNECT` with connection parameters (**dom0**, and port 0, indicating a port should be allocated) and request identifier (`SOCKET11`).
+  - `qrexec-client` connects to a `qrexec-daemon` for **domX** and sends a `MSG_SERVICE_CONNECT` with connection parameters (**dom0**, and port 0, indicating a port should be allocated) and request identifier (`SOCKET11`).
 
-  `qrexec-daemon` allocates a free port (513) and sends back connection parameters to `qrexec-client` (**domX** port 513).
+  - `qrexec-daemon` allocates a free port (513) and sends back connection parameters to `qrexec-client` (**domX** port 513).
 
-  `qrexec-client` starts the command, and tries to connect to **domX** over the provided port 513.
+  - `qrexec-client` starts the command, and tries to connect to **domX** over the provided port 513.
 
-  Then, `qrexec-daemon` forwards the connection request (`MSG_SERVICE_CONNECT`) to `qrexec-agent` running in **domX**, with the right parameters (**dom0** port 513, request `SOCKET11`).
+  - Then, `qrexec-daemon` forwards the connection request (`MSG_SERVICE_CONNECT`) to `qrexec-agent` running in **domX**, with the right parameters (**dom0** port 513, request `SOCKET11`).
 
 - **dom0**: Because the command has the form `QUBESRPC: ...`, it is started through the `qubes-rpc-multiplexer` program with the provided parameters (`admin.Service domX name dom0`). That program finds and executes the necessary script in `/etc/qubes-rpc/`.
 
 - **domX**: `qrexec-agent` receives the `MSG_SERVICE_CONNECT` and passes the connection parameters back to the connected `qrexec-client-vm`. It identifies the `qrexec-client-vm` by the request identifier (`SOCKET11` means file descriptor 11).
 
-  `qrexec-client-vm` starts a vchan server on 513 and receives a connection from `qrexec-client`.
+  - `qrexec-client-vm` starts a vchan server on 513 and receives a connection from `qrexec-client`.
 
 - Data is forwarded between **dom0** and **domX** as in the previous example (dom0-VM).
 
@@ -196,37 +196,37 @@ Details of all possible use cases and the messages involved are described below.
 
       qrexec-client-vm domY qubes.Service [local_program] [params]
 
-  (If `local_program` is set, it will be executed in **domX** and connected to the remote command's stdin/stdout).
+  - (If `local_program` is set, it will be executed in **domX** and connected to the remote command's stdin/stdout).
 
 - The request is forwarded as `MSG_TRIGGER_SERVICE3` to `qrexec-daemon` running in **dom0**, then to `qrexec-policy`, then (if allowed) to `qrexec-client`.
 
-  This is the same as in the previous example (VM-dom0).
+  - This is the same as in the previous example (VM-dom0).
 
 - **dom0**: If the RPC is allowed, `qrexec-policy` will launch a `qrexec-client` with the right command:
 
       qrexec-client -d domY -c domX,X,SOCKET11 user:cmd "DEFAULT:QUBESRPC qubes.Service domX"
 
-  The `-c domX,X,SOCKET11` are parameters indicating how connect back to **domX** and pass its input/output.
+  - The `-c domX,X,SOCKET11` are parameters indicating how connect back to **domX** and pass its input/output.
 
-  The command parameter describes the service call: it contains the username (or `DEFAULT`), service name (`qubes.Service`) and source domain (`domX`).
+  - The command parameter describes the service call: it contains the username (or `DEFAULT`), service name (`qubes.Service`) and source domain (`domX`).
 
-  `qrexec-client` will then send a `MSG_EXEC_CMDLINE` message to `qrexec-daemon` for **domY**. The message will be with port number 0, requesting port allocation.
+  - `qrexec-client` will then send a `MSG_EXEC_CMDLINE` message to `qrexec-daemon` for **domY**. The message will be with port number 0, requesting port allocation.
 
-  `qrexec-daemon` for **domY** will allocate a port (513) and send it back. It will also send a `MSG_EXEC_CMDLINE` to its corresponding agent. (It will also translate `DEFAULT` to the configured default username).
+  - `qrexec-daemon` for **domY** will allocate a port (513) and send it back. It will also send a `MSG_EXEC_CMDLINE` to its corresponding agent. (It will also translate `DEFAULT` to the configured default username).
 
-  Then, `qrexec-client` will also send `MSG_SERVICE_CONNECT` message to **domX**'s agent, indicating that it should connect to **domY** over port 513.
+  - Then, `qrexec-client` will also send `MSG_SERVICE_CONNECT` message to **domX**'s agent, indicating that it should connect to **domY** over port 513.
 
-  Having notified both domains about a connection, `qrexec-client` now exits.
+  - Having notified both domains about a connection, `qrexec-client` now exits.
 
 - **domX**: `qrexec-agent` receives a `MSG_SERVICE_CONNECT` with connection parameters (**domY** port 513) and request identifier (`SOCKET11`). It sends the connection parameters back to the right `qrexec-client-vm`.
 
-  `qrexec-client-vm` starts a vchan server on port 513. note that this is different than in the other examples: `MSG_SERVICE_CONNECT` means you should start a server, `MSG_EXEC_CMDLINE` means you should start a client.
+  - `qrexec-client-vm` starts a vchan server on port 513. note that this is different than in the other examples: `MSG_SERVICE_CONNECT` means you should start a server, `MSG_EXEC_CMDLINE` means you should start a client.
 
 - **domY**: `qrexec-agent` receives a `MSG_EXEC_CMDLINE` with the command to execute (`user:QUBESRPC...`) and connection parameters (**domX** port 513).
 
-  It forwards the request to `qrexec-fork-server`, which handles the command and connects to **domX** over the provided port.
+  - It forwards the request to `qrexec-fork-server`, which handles the command and connects to **domX** over the provided port.
 
-  Because the command is of the form `QUBESRPC ...`, `qrexec-fork-server` starts it using `qubes-rpc-multiplexer` program, which finds and executes the necessary script in `/etc/qubes-rpc/`.
+  - Because the command is of the form `QUBESRPC ...`, `qrexec-fork-server` starts it using `qubes-rpc-multiplexer` program, which finds and executes the necessary script in `/etc/qubes-rpc/`.
 
 - After that, the data is passed between **domX** and **domY** as in the previous examples (dom0-VM, VM-dom0).
 
diff --git a/developer/system/gui.md b/developer/system/gui.md
index dfd04801..e2b8c1ee 100644
--- a/developer/system/gui.md
+++ b/developer/system/gui.md
@@ -16,8 +16,8 @@ title: GUI virtualization
 
 All AppVM X applications connect to local (running in AppVM) Xorg servers that use the following "hardware" drivers:
 
-- *`dummyqsb_drv`* - video driver, that paints onto a framebuffer located in RAM, not connected to real hardware
-- *`qubes_drv`* - it provides a virtual keyboard and mouse (in fact, more, see below)
+- `dummyqsb_drv` - video driver, that paints onto a framebuffer located in RAM, not connected to real hardware
+- `qubes_drv` - it provides a virtual keyboard and mouse (in fact, more, see below)
 
 For each AppVM, there is a pair of `qubes-gui` (running in AppVM) and `qubes-guid` (running in the AppVM’s GuiVM, dom0 by default) processes connected over vchan.
 The main responsibilities of `qubes-gui` are:
diff --git a/user/advanced-topics/managing-vm-kernels.md b/user/advanced-topics/managing-vm-kernels.md
index 1dab8a44..bf0745ec 100644
--- a/user/advanced-topics/managing-vm-kernels.md
+++ b/user/advanced-topics/managing-vm-kernels.md
@@ -154,6 +154,7 @@ The newly installed package is set as the default VM kernel.
 It is possible to package a kernel installed in dom0 as a VM kernel.
 This makes it possible to use a VM kernel which is not packaged by Qubes team.
 This includes:
+
  * using a Fedora kernel package
  * using a manually compiled kernel
 
diff --git a/user/how-to-guides/backup-emergency-restore-v3.md b/user/how-to-guides/backup-emergency-restore-v3.md
index 3d3fc392..efa42c2a 100644
--- a/user/how-to-guides/backup-emergency-restore-v3.md
+++ b/user/how-to-guides/backup-emergency-restore-v3.md
@@ -52,13 +52,11 @@ any GNU/Linux system with the following procedure.
         [user@restore ~]$ cat backup-header.hmac
         (stdin)= 5b266783e116fe3b2601a54c249ca5f5f96d421dfe6828eeaeb2dcd014e9e945c27b3d7b0f952f5d55c927318906d9c360f387b0e1f069bb8195e96543e2969c
 
-    **Note:** The hash values should match. If they do not match, then the
+    - **Note:** The hash values should match. If they do not match, then the
     backup file may have been tampered with, or there may have been a storage
     error.
-    
 
-
-    **Note:** If your backup was hashed with a message digest algorithm other
+    - **Note:** If your backup was hashed with a message digest algorithm other
     than `sha512`, you must substitute the correct message digest command. This
     information is contained in the `backup-header` file (see step 4), however
     it is not recommended to open this file until its integrity and
@@ -88,13 +86,11 @@ any GNU/Linux system with the following procedure.
         [user@restore vm1]$ cat private.img.000.hmac
         (stdin)= cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e
 
-    **Note:** The hash values should match. If they do not match, then the
+    - **Note:** The hash values should match. If they do not match, then the
     backup file may have been tampered with, or there may have been a storage
     error.
 
-
-
-    **Note:** If your backup was hashed with a message digest algorithm other
+    - **Note:** If your backup was hashed with a message digest algorithm other
     than `sha512`, you must substitute the correct message digest command. This
     information is contained in the `backup-header` file (see step 4). A
     complete list of supported message digest algorithms can be found with
@@ -139,9 +135,7 @@ any GNU/Linux system with the following procedure.
 10. Success! If you wish to recover data from more than one VM in your backup,
     simply repeat steps 5--9 for each additional VM.
 
-
-
-    **Note:** You may wish to store a copy of these instructions with your
+    - **Note:** You may wish to store a copy of these instructions with your
     Qubes backups in the event that you fail to recall the above procedure
     while this web page is inaccessible. All Qubes documentation, including
     this page, is available in plain text format in the following Git
diff --git a/user/how-to-guides/backup-emergency-restore-v4.md b/user/how-to-guides/backup-emergency-restore-v4.md
index 19367a24..fe9d4421 100644
--- a/user/how-to-guides/backup-emergency-restore-v4.md
+++ b/user/how-to-guides/backup-emergency-restore-v4.md
@@ -152,10 +152,10 @@ Emergency Recovery Instructions
             done | gzip -d | tar -xv
         vm1/private.img
 
-    If this pipeline fails, it is likely that the backup is corrupted or has
+    - If this pipeline fails, it is likely that the backup is corrupted or has
     been tampered with.
 
-    **Note:** If your backup was compressed with a program other than `gzip`,
+    - **Note:** If your backup was compressed with a program other than `gzip`,
     you must substitute the correct compression program in the command above.
     This information is contained in `backup-header` (see step 4). For example,
     if your backup is compressed with `bzip2`, use `bzip2 -d` instead in the
@@ -171,7 +171,7 @@ Emergency Recovery Instructions
  8. Success! If you wish to recover data from more than one VM in your backup,
     simply repeat steps 6 and 7 for each additional VM.
 
-    **Note:** You may wish to store a copy of these instructions with your
+    - **Note:** You may wish to store a copy of these instructions with your
     Qubes backups in the event that you fail to recall the above procedure
     while this web page is inaccessible. All Qubes documentation, including
     this page, is available in plain text format in the following Git
diff --git a/user/security-in-qubes/data-leaks.md b/user/security-in-qubes/data-leaks.md
index 82b736e7..51c81201 100644
--- a/user/security-in-qubes/data-leaks.md
+++ b/user/security-in-qubes/data-leaks.md
@@ -48,7 +48,6 @@ Such attacks have been described in the academic literature, but it is doubtful
 3. **Unintentional leaks.** Non-malicious software which is either buggy or doesn't maintain the privacy of user data, whether by design or accident.
    For example, software which automatically sends error reports to a remote server, where these reports contain details about the system which the user did not want to share.
 
-
    Both Qubes firewall and an empty NetVM (i.e., setting the NetVM of an app qube to "none") can fully protect against leaks of type 3.
    However, neither Qubes firewall nor an empty NetVM are guaranteed to protect against leaks of types 1 and 2.
    There are few effective, practical policy measures available to end-users today to stop the leaks of type 1.
diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index a94f087a..b0f032fa 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -165,7 +165,7 @@ Consider the following example. `mytcp-service` qube has a TCP service running o
     [user@untrusted #]$ qvm-connect-tcp 444:@default:444
     ~~~
 
-> Note: The syntax is the same as SSH tunnel handler. The first `444` correspond to the localport destination of `untrusted`, `@default` the remote machine and the second `444` to the remote machine port.
+  - **Note:** The syntax is the same as SSH tunnel handler. The first `444` correspond to the localport destination of `untrusted`, `@default` the remote machine and the second `444` to the remote machine port.
 
 The service of `mytcp-service` running on port `444` is now accessible in `untrusted` as `localhost:444`.
 
@@ -278,7 +278,7 @@ You can get this information using various methods, but only the first one can b
 
 Note the IP addresses you will need, they will be required in the next steps.
 
-> Note: The vifx.0 interface is the one used by qubes connected to this netvm so it is _not_ an outside world interface.
+  - **Note:** The vifx.0 interface is the one used by qubes connected to this netvm so it is _not_ an outside world interface.
 
 **2. Route packets from the outside world to the FirewallVM**
 
@@ -290,9 +290,9 @@ In the sys-net VM's Terminal, the first step is to define an ntables chain that
 nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
 ```
 
-> Note: the name `custom-dnat-qubeDST` is arbitrary
+  - **Note:** the name `custom-dnat-qubeDST` is arbitrary
 
-> Note: while we use a DNAT chain for a single qube, it's totally possible to have a single DNAT chain for multiple qubes
+  - **Note:** while we use a DNAT chain for a single qube, it's totally possible to have a single DNAT chain for multiple qubes
 
 Second step, code a natting firewall rule to route traffic on the outside interface for the service to the sys-firewall VM
 
@@ -306,7 +306,7 @@ Third step, code the appropriate new filtering firewall rule to allow new connec
 nft add rule qubes custom-forward iif == "ens6" ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
 ```
 
-> Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
+  - **Note:** If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
 
 > If you want to expose the service on multiple interfaces, repeat the steps 2 and 3 described above, for each interface. Alternatively, you can leave out the interface completely.
 
@@ -380,7 +380,7 @@ Third step, code the appropriate new filtering firewall rule to allow new connec
 nft add rule qubes custom-forward iif == "eth0" ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
 ```
 
-> Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
+ -  **Note:** If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
 
 Once you have confirmed that the counters increase, store these commands in the script `/rw/config/qubes-firewall-user-script`
 
diff --git a/user/security-in-qubes/firewall_4.1.md b/user/security-in-qubes/firewall_4.1.md
index 5c00c9f9..7c5e2769 100644
--- a/user/security-in-qubes/firewall_4.1.md
+++ b/user/security-in-qubes/firewall_4.1.md
@@ -155,11 +155,10 @@ Consider the following example. `mytcp-service` qube has a TCP service running o
 
 - In untrusted, use the Qubes tool `qvm-connect-tcp`:
 
-    ~~~
+    ```
     [user@untrusted #]$ qvm-connect-tcp 444:@default:444
-    ~~~
-
-> Note: The syntax is the same as SSH tunnel handler. The first `444` correspond to the localport destination of `untrusted`, `@default` the remote machine and the second `444` to the remote machine port.
+    ```
+- **Note:** The syntax is the same as SSH tunnel handler. The first `444` correspond to the localport destination of `untrusted`, `@default` the remote machine and the second `444` to the remote machine port.
 
 The service of `mytcp-service` running on port `444` is now accessible in `untrusted` as `localhost:444`.
 
@@ -257,15 +256,16 @@ In order to allow a service present in a qube to be exposed to the outside world
 
 As an example we can take the use case of a web server listening on port 443 that we want to expose on our physical interface eth0, but only to our local network 192.168.x.0/24.
 
-> Note: To have all interfaces available and configured, make sure the 3 qubes are up and running
+  - **Note:** To have all interfaces available and configured, make sure the 3 qubes are up and running
 
-> Note: [Issue #4028](https://github.com/QubesOS/qubes-issues/issues/4028) discusses adding a command to automate exposing the port.
+  - **Note:** [Issue #4028](https://github.com/QubesOS/qubes-issues/issues/4028) discusses adding a command to automate exposing the port.
 
 **1. Identify the IP addresses you will need to use for sys-net, sys-firewall and the destination qube.**
 
 You can get this information from the Settings Window for the qube, or by running this command in each qube:
 `ifconfig | grep -i cast `
 Note the IP addresses you will need.
+
 > Note: The vifx.0 interface is the one used by qubes connected to this netvm so it is _not_ an outside world interface.
 
 **2. Route packets from the outside world to the FirewallVM**
@@ -280,23 +280,23 @@ iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.x.y -j DNAT
 
 Code the appropriate new filtering firewall rule to allow new connections for the service
 
-```
-iptables -I FORWARD 2 -i eth0 -d 10.137.1.z -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
-```
+  ```
+  iptables -I FORWARD 2 -i eth0 -d 10.137.1.z -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
+  ```
 
-> If you want to expose the service on multiple interfaces, repeat the steps described in part 1 for each interface.
-> In Qubes R4, at the moment ([QubesOS/qubes-issues#3644](https://github.com/QubesOS/qubes-issues/issues/3644)), nftables is also used which imply that additional rules need to be set in a `qubes-firewall` nft table with a forward chain.
+  - If you want to expose the service on multiple interfaces, repeat the steps described in part 1 for each interface.
+  - In Qubes R4, at the moment ([QubesOS/qubes-issues#3644](https://github.com/QubesOS/qubes-issues/issues/3644)), nftables is also used which imply that additional rules need to be set in a `qubes-firewall` nft table with a forward chain.
 
 `nft add rule ip qubes-firewall forward meta iifname eth0 ip daddr 10.137.1.z tcp dport 443 ct state new counter accept`
 
 Verify you are cutting through the sys-net VM firewall by looking at its counters (column 2)
 
-```
-iptables -t nat -L -v -n
-iptables -L -v -n
-```
+  ```
+  iptables -t nat -L -v -n
+  iptables -L -v -n
+  ```
+  - **Note:** On Qubes R4, you can also check the nft counters
 
-> Note: On Qubes R4, you can also check the nft counters
 
 ```
 nft list table ip qubes-firewall
@@ -358,7 +358,9 @@ if ! iptables -w -n -L FORWARD | grep --quiet MY-HTTPS; then
 fi
 ~~~
 
-> Note: Again in R4 the following needs to be added:
+
+  - **Note:** Again in R4 the following needs to be added:
+
 
 ~~~
 #############
@@ -389,9 +391,9 @@ Code the appropriate new filtering firewall rule to allow new connections for th
 iptables -I FORWARD 2 -i eth0 -s 192.168.x.0/24 -d 10.137.0.xx -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
 ```
 
-> Note: If you do not wish to limit the IP addresses connecting to the service, remove the ` -s 192.168.0.1/24 `
+  - **Note:** If you do not wish to limit the IP addresses connecting to the service, remove the ` -s 192.168.0.1/24 `
 
-> Note: On Qubes R4
+  - **Note:** On Qubes R4
 
 ```
 nft add rule ip qubes-firewall forward meta iifname eth0 ip saddr 192.168.x.0/24 ip daddr 10.137.0.xx tcp dport 443 ct state new counter accept
diff --git a/user/security-in-qubes/mfa.md b/user/security-in-qubes/mfa.md
index 6009926d..ec436f5a 100644
--- a/user/security-in-qubes/mfa.md
+++ b/user/security-in-qubes/mfa.md
@@ -60,7 +60,7 @@ and then use it as an additional factor to login to your Qubes system.
 
 > **Warning**: in the next session if incorrectly performed, there is the risk of locking yourself out. Before procedding ensure that you have an up-to-date backup.
 >
-> For advanced users, to make sure you can quickly recover, you can also open another loging session in a tty. To do this, you do <kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>F2</kbd> and login normally. Should anything go wrong, as long as you don't shut the computer down, you can still access this tty by entering the same key combination and reverting the changes. After you've opened this "backup" login, you can get to your graphical desktop with <kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>F1</kbd>.
+> For advanced users, to make sure you can quickly recover, you can also open another loging session in a tty. To do this, you do `ctrl` + `alt` + `F2` and login normally. Should anything go wrong, as long as you don't shut the computer down, you can still access this tty by entering the same key combination and reverting the changes. After you've opened this "backup" login, you can get to your graphical desktop with `ctrl` + `alt` + `F1`.
 
 Now we are going to add the authenticator as a login requirement:
 
@@ -89,7 +89,7 @@ Now we are going to add the authenticator as a login requirement:
    sudo authselect select custom/mfa
    ```
 
-Now you can test by locking the screen with <kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>l</kbd>. If it was successful and you are pleased with the results, restart your computer.
+Now you can test by locking the screen with `ctrl` + `alt` + `l` . If it was successful and you are pleased with the results, restart your computer.
 
 **Note**: When logging in. the first thing you put is the TOTP secret and then the password. This is true in the screen locker and as well as the session manager (the login window that shows right after you put the disk encryption passphrase).
 
@@ -99,12 +99,12 @@ After this is done, its recommended to do a backup. This is because as long as y
 
 The following assumes you haven't restarted your computer since setting up TOTP secret.
 
-1. Switch to TTY2 with <kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>F2</kbd>.
+1. Switch to TTY2 with `ctrl` + `alt` + `F2` .
 2. Revert to the original policy with:
    ```
    sudo authselect select sssd
    ```
-3. Switch back to the graphical desktop with <kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>F1</kbd>. You should be able to login normally (without multi-factor authentication).
+3. Switch back to the graphical desktop with `ctrl` + `alt` + `F1` . You should be able to login normally (without multi-factor authentication).
 4. Change the mfa custom policy and apply it again.
 
 #### Lost TOTP / authentication device?
@@ -157,30 +157,28 @@ Note that setting up both a YubiKey and a NitroKey3 is not supported.
 1. Install YubiKey / NitroKey3 software in the template on which your USB VM is based.
    Without this software the challenge-response / HOTP mechanism won't work.
 
+   - **YubiKey**
 
-   **YubiKey**
+     - For Fedora.
 
+     ```
+     sudo dnf install ykpers
+     ```
 
-   For Fedora.
+     - For Debian.
 
-    ```
-    sudo dnf install ykpers
-    ```
-
-   For Debian.
-
-    ```
-    sudo apt-get install yubikey-personalization
-    ```
+     ```
+     sudo apt-get install yubikey-personalization
+     ```
    
-   **NitroKey3**
+   - **NitroKey3**
 
 
-   Follow the installation instructions on the official [NitroKey 
+     - Follow the installation instructions on the official [NitroKey 
 website](https://docs.nitrokey.com/software/nitropy/all-platforms/installation).
 
    
-   **WARNING**: *as of April 2024 the official instructions involve using pipx to
+     - **WARNING**: *as of April 2024 the official instructions involve using pipx to
             install the pynitrokey package and its dependencies without any GPG
             verification! This is not a recommended practice, but will soon be
             fixed by NitroKey when they start providing release artifacts with
@@ -190,10 +188,10 @@ website](https://docs.nitrokey.com/software/nitropy/all-platforms/installation).
             **Installing packages using pip or pipx is not recommended!**
 
 
-   **both**
+   - **both**
 
 
-   Shut down your template. Then, either reboot your USB VM (so changes inside
+     - Shut down your template. Then, either reboot your USB VM (so changes inside
    the template take effect in your USB app qube) or install the packages inside
    your USB VM as well if you would like to avoid rebooting it.
 
@@ -207,71 +205,70 @@ website](https://docs.nitrokey.com/software/nitropy/all-platforms/installation).
 3. Configure your YubiKey / NitroKey3:
 
    
-   **YubiKey**
+   - **YubiKey**
 
    
-   Configure your YubiKey for challenge-response `HMAC-SHA1` mode. This can be
+     - Configure your YubiKey for challenge-response `HMAC-SHA1` mode. This can be
    done on any qube, e.g. a disposable (you need to [attach the
 YubiKey](https://www.qubes-os.org/doc/how-to-use-usb-devices/) to this app qube
-though) or directly on the sys-usb vm.
-
-
-   You need to (temporarily) install the package "yubikey-personalization-gui" and
+though) or directly on the sys-usb vm. You need to (temporarily) install the package "yubikey-personalization-gui" and
    run it by typing `yubikey-personalization-gui` in the command line.
 
-   - In the program go to `Challenge-Response`,
-   - select `HMAC-SHA1`,
-   - choose `Configuration Slot 2`,
-   - optional: enable `Require user input (button press)` (recommended),
-   - use `fixed 64 bit input` for `HMAC-SHA1 mode`,
-   - insert the YubiKey (if not done already) and make sure that it is attached
-     to the vm,
-   - press `Write Configuration` once you are ready.
+       - In the program go to `Challenge-Response`,
+       - select `HMAC-SHA1`,
+       - choose `Configuration Slot 2`,
+       - optional: enable `Require user input (button press)` (recommended),
+       - use `fixed 64 bit input` for `HMAC-SHA1 mode`,
+       - insert the YubiKey (if not done already) and make sure that it is attached
+         to the vm,
+       - press `Write Configuration` once you are ready.
 
-   **NitroKey3**
+   - **NitroKey3**
 
 
-   Set up a new NK3 Secrets App HOTP secret by attaching the NitroKey to your
+     - Set up a new NK3 Secrets App HOTP secret by attaching the NitroKey to your
    USB qube and running the following commands in it:
-   ```
-   AESKEY=$(echo -n "your-20-digit-secret" | base32)
-   nitropy nk3 secrets register --kind hotp --hash sha256 --digits-str 8 --counter-start 1 --touch-button loginxs $AESKEY
-   ```
-   Note that the 20 digit sequence can contain any printable ASCII character,
+
+       ```
+       AESKEY=$(echo -n "your-20-digit-secret" | base32)
+       nitropy nk3 secrets register --kind hotp --hash sha256 --digits-str 8 --counter-start 1 --touch-button loginxs $AESKEY
+       ```
+
+     - Note that the 20 digit sequence can contain any printable ASCII character,
    e.g. letters, numbers, punctuation marks. The actual `Secret Key (base 32)`
    is the base32 encoded form of that sequence.
 
 
-   **both**
+   - **both**
 
 
-   We will call the `Secret Key (20 bytes hex)` (YubiKey) or `Secret Key (base 32)` `AESKEY`.
+     - We will call the `Secret Key (20 bytes hex)` (YubiKey) or `Secret Key (base 32)` `AESKEY`.
 
-   - It is recommended to keep a backup of your `AESKEY` in an offline VM used as a vault.
-   - Consider keeping a backup of your `AESKEY` on paper and storing it in a safe place.
-   - If you have multiple YubiKeys for backup purposes (in case one gets
-     lost, stolen or breaks) you can write the same settings into other
-YubiKeys. For YubiKeys you can choose "Program multiple YubiKeys" in the program;
- make sure to select `Same secret for all keys` in this case. For NitroKeys you can set up
-the secret for multiple of them, but you must always use the same NitroKey, because the
-HOTP counter will be incremented in dom0 as well as the used NitroKey whenever you make use
-of this method. If you want to switch to a different NitroKey later, delete the file
-`/etc/qubes/yk-keys/nk-hotp-counter` in dom0 first to make it work with a fresh NitroKey 3.
-Do the same if for some reason your counters get desynchronized (it stops working), e.g. due
-to connectivity issues (NitroKey3A Minis are known to wear out quickly).
+       - It is recommended to keep a backup of your `AESKEY` in an offline VM used as a vault.
+       - Consider keeping a backup of your `AESKEY` on paper and storing it in a safe place.
+       - If you have multiple YubiKeys for backup purposes (in case one gets 
+         lost, stolen or breaks) you can write the same settings into other
+         YubiKeys. For YubiKeys you can choose "Program multiple YubiKeys" in the program;
+         make sure to select `Same secret for all keys` in this case. For NitroKeys you can set up
+         the secret for multiple of them, but you must always use the same NitroKey, because the
+         HOTP counter will be incremented in dom0 as well as the used NitroKey whenever you make use
+         of this method. If you want to switch to a different NitroKey later, delete the file
+         `/etc/qubes/yk-keys/nk-hotp-counter` in dom0 first to make it work with a fresh NitroKey 3.
+         Do the same if for some reason your counters get desynchronized (it stops working), e.g. due
+         to connectivity issues (NitroKey3A Minis are known to wear out quickly).
 
 4. **YubiKey**
 
 
-   Paste your `AESKEY` into `/etc/qubes/yk-keys/yk-secret-key.hex` in dom0.
+   - Paste your `AESKEY` into `/etc/qubes/yk-keys/yk-secret-key.hex` in dom0.
    Note that if you had previously used a NitroKey3 with this package, you *must* delete
    the file `/etc/qubes/yk-keys/nk-hotp-secret` or its content!
 
 
-   **NitroKey3**
+   - **NitroKey3**
 
 
-   Create the file `/etc/qubes/yk-keys/nk-hotp-secret` in dom0 and paste your `AESKEY` 
+     - Create the file `/etc/qubes/yk-keys/nk-hotp-secret` in dom0 and paste your `AESKEY` 
    (in base 32 format) into it.
 
 5. As mentioned before, you need to define a new password that is only used in
@@ -280,23 +277,23 @@ to connectivity issues (NitroKey3A Minis are known to wear out quickly).
 ultimately trusted anyway.
 
 
-    However, if you prefer you can paste a hashed password instead into
+    - However, if you prefer you can paste a hashed password instead into
 `/etc/qubes/yk-keys/login-pass-hashed.hex` in dom0.
 
 
-    You can calculate your hashed password using the following two commands.
+    - You can calculate your hashed password using the following two commands.
     First run the following command to store your password in a temporary variable `password`.
     (This way your password will not leak to the terminal command history file.)
 
-    ```
-    read -r password
-    ```
+      ```
+      read -r password
+      ```
 
-    Now run the following command to calculate your hashed password.
+    - Now run the following command to calculate your hashed password.
 
-    ```
-    echo -n "$password" | openssl dgst -sha1 | cut -f2 -d ' '
-    ```
+      ```
+      echo -n "$password" | openssl dgst -sha1 | cut -f2 -d ' '
+      ```
 
 6. To enable multi-factor authentication for a service, you need to add
 
diff --git a/user/security-in-qubes/split-gpg.md b/user/security-in-qubes/split-gpg.md
index f13b5ff5..33682a8d 100644
--- a/user/security-in-qubes/split-gpg.md
+++ b/user/security-in-qubes/split-gpg.md
@@ -295,8 +295,7 @@ In this example, the following keys are stored in the following locations (see b
 | `ssb`      | `work-gpg`   |
 | `pub`      | `work-email` |
 
-* `sec` (master secret key)
-
+- `sec` (master secret key)
 
    Depending on your needs, you may wish to create this as a **certify-only (C)** key, i.e., a key which is capable only of signing (a.k.a., "certifying") other keys.
    This key may be created *without* an expiration date.
@@ -313,8 +312,7 @@ In this example, the following keys are stored in the following locations (see b
    Therefore, using a passphrase at all should be considered optional.
    It is, however, recommended that a **revocation certificate** be created and safely stored in multiple locations so that the master keypair can be revoked in the (exceedingly unlikely) event that it is ever compromised.
 
-* `ssb` (secret subkey)
-
+- `ssb` (secret subkey)
 
    Depending on your needs, you may wish to create two different subkeys: one for **signing (S)** and one for **encryption (E)**.
    You may also wish to give these subkeys reasonable expiration dates (e.g., one year).
@@ -328,30 +326,26 @@ In this example, the following keys are stored in the following locations (see b
    This can be problematic, since there is no consensus on how expired signatures should be handled.
    Generally, digital signatures are intended to last forever, so this is a strong reason against regularly retiring one's signing subkeys.
 
-* `pub` (public key)
-
+- `pub` (public key)
 
    This is the complement of the master secret key.
    It can be uploaded to keyservers (or otherwise publicly distributed) and may be signed by others.
 
-* `vault`
-
+- `vault`
 
    This is a network-isolated VM.
    The initial master keypair and subkeys are generated in this VM.
    The master secret key *never* leaves this VM under *any* circumstances.
    No files or text is *ever* [copied](/doc/how-to-copy-and-move-files/#security) or [pasted](/doc/how-to-copy-and-paste-text/#security) into this VM under *any* circumstances.
 
-* `work-gpg`
-
+- `work-gpg`
 
    This is a network-isolated VM.
    This VM is used *only* as the GPG backend for `work-email`.
    The secret subkeys (but *not* the master secret key) are [copied](/doc/how-to-copy-and-move-files/#security) from the `vault` VM to this VM.
    Files from less trusted VMs are *never* [copied](/doc/how-to-copy-and-move-files/#security) into this VM under *any* circumstances.
 
-* `work-email`
-
+- `work-email`
 
    This VM has access to the mail server.
    It accesses the `work-gpg` VM via the Split GPG protocol.
diff --git a/user/templates/windows/qubes-windows-tools-4-0.md b/user/templates/windows/qubes-windows-tools-4-0.md
index f1bd0a91..84470d0d 100644
--- a/user/templates/windows/qubes-windows-tools-4-0.md
+++ b/user/templates/windows/qubes-windows-tools-4-0.md
@@ -79,9 +79,9 @@ This will allow you to install the Qubes Windows Tools on Windows 10 both as a S
         
 		certutil -hashfile C:\qubes-tools-4.0.1.3.exe SHA256
 
-	And compare it the value to `148A2A993F0C746B48FA6C5C9A5D1B504E09A7CFBA3FB931A4DCF86FDA4EC9B1` (**it has to exactly match for security reasons**). If it matches, feel free to continue the installation. If not, repeat the download to make sure it was not corrupted due to a network problem. If keeps on not matching it might be an attacker attempting to do something nasty to your system -- Ask for support.
+	- And compare it the value to `148A2A993F0C746B48FA6C5C9A5D1B504E09A7CFBA3FB931A4DCF86FDA4EC9B1` (**it has to exactly match for security reasons**). If it matches, feel free to continue the installation. If not, repeat the download to make sure it was not corrupted due to a network problem. If keeps on not matching it might be an attacker attempting to do something nasty to your system -- Ask for support.
 
-    **Note**: This is a workaround for installing the qubes windows tools on windows 10 since the standard way is broken.
+    - **Note**: This is a workaround for installing the qubes windows tools on windows 10 since the standard way is broken.
 
  7. Install Qubes Windows Tools 4.0.1.3 by starting `qubes-tools-4.0.1.3.exe`, not selecting the `Xen PV disk drivers` and the `Move user profiles` (which would probably lead to problems in Windows, anyhow). If during installation, the Xen driver requests a reboot, select "No" and let the installation continue - the system will be rebooted later.
 
@@ -98,7 +98,9 @@ This will allow you to install the Qubes Windows Tools on Windows 10 both as a S
  
  12. Lastly to enable file copy operations to a Windows 10 VM the `default_user` property should be set the `<username>` that you use to login to the Windows VM. This can be done via the following command on a `dom0` terminal: *(where `<VMname>` is the name of your Windows 10 VM)*
         
-		`qvm-prefs <VMname> default_user <username> `
+        ```
+        qvm-prefs <VMname> default_user <username> 
+        ```
 
   **Note:** If this property is not set or set to a wrong value, files copied to this VM are stored in the folder
 		
@@ -333,7 +335,7 @@ If the VM is inaccessible (doesn't respond to qrexec commands, gui is not functi
 Safe Mode should at least give you access to logs (see above).
 
 **Please include appropriate logs when reporting bugs/problems.** Starting from version 2.4.2 logs contain QWT version, but if you're using an earlier version be sure to mention which one. If the OS crashes (BSOD) please include the BSOD code and parameters in your bug report. The BSOD screen should be visible if you run the VM in debug mode (`qvm-start --debug vmname`). If it's not visible or the VM reboots automatically, try to start Windows in safe mode (see above) and 1) disable automatic restart on BSOD (Control Panel - System - Advanced system settings - Advanced - Startup and recovery), 2) check the system event log for BSOD events. If you can, send the `memory.dmp` dump file from `c:\Windows`.
-Xen logs (/var/log/xen/console/guest-*) are also useful as they contain pvdrivers diagnostic output.
+Xen logs (`/var/log/xen/console/guest-*`) are also useful as they contain pvdrivers diagnostic output.
 
 If a specific component is malfunctioning, you can increase its log verbosity as explained above to get more troubleshooting information. Below is a list of components:
 
diff --git a/user/templates/windows/windows-qubes-4-1.md b/user/templates/windows/windows-qubes-4-1.md
index d20f5a62..bfd3a10f 100644
--- a/user/templates/windows/windows-qubes-4-1.md
+++ b/user/templates/windows/windows-qubes-4-1.md
@@ -62,27 +62,23 @@ Unofficial “debloated” ISOs from projects like reviOS 18 or ameliorated 10 c
 
 Create a VM named WindowsNew in [HVM](/doc/hvm/) mode (Xen's current PVH limitations precludes from using PVH). This can be done in either of two ways:
 
-- Using Qube Manager
+- Using Qube Manager: In order to create the new qube, select the command Qube -> New Qube in the Qube Manager:
 
-
-   In order to create the new qube, select the command Qube -> New Qube in the Qube Manager:
-  
-     - Name: `WindowsNew`, Color: `orange` (for a standalone qubes, `black` for a template)
-     - Type: `StandaloneVM (fully persistent)` or `TemplateVM (template home, persistent root)`
-     - Template: `(none)`
-     - Networking: `sys-firewall (default)`
-     - Launch settings after creation: check
-     - Click "OK".
-  
-     - Settings:
-        - Basic:
-          - System storage: 60.0+ GB
-        - Advanced:
-          - Include in memory balancing: uncheck
-          - Initial memory: 4096+ MB
-          - Kernel: `(none)`
-          - Mode: `HVM`
-        - Click "Apply".
+  - Name: `WindowsNew`, Color: `orange` (for a standalone qubes, `black` for a template)
+  - Type: `StandaloneVM (fully persistent)` or `TemplateVM (template home, persistent root)`
+  - Template: `(none)`
+  - Networking: `sys-firewall (default)`
+  - Launch settings after creation: check
+  - Click "OK".
+    - Settings:
+      - Basic:
+        - System storage: 60.0+ GB
+      - Advanced:
+        - Include in memory balancing: uncheck
+        - Initial memory: 4096+ MB
+        - Kernel: `(none)`
+        - Mode: `HVM`
+      - Click "Apply".
 
    After creation, set `qvm-prefs WindowsNew qrexec_timeout 7200` via CLI in a dom0 terminal.
 
@@ -171,7 +167,7 @@ These parameters are set for the following reasons:
 </div>
 
     
-    The installation of Windows 11 may require an internet connection to grab a Microsoft ID. This is currently true only for the home addition, but will probably extend to the Pro edition, too. A workaround to bypass the internet connection requirements of the Windows 11 setup has been published that currently works for version 21H2 but may be blocked some time in the future by Microsoft:
+  - The installation of Windows 11 may require an internet connection to grab a Microsoft ID. This is currently true only for the home addition, but will probably extend to the Pro edition, too. A workaround to bypass the internet connection requirements of the Windows 11 setup has been published that currently works for version 21H2 but may be blocked some time in the future by Microsoft:
     
     - When you reach the “Let’s Connect You To A Network” page, type Shift-F10 to open a console window.
     - Here you type `taskmgr` to start the Task Manager window so you can see all running processes.
@@ -179,7 +175,7 @@ These parameters are set for the following reasons:
     - Select this process and then hit the “End Task” button.
     - Now you can close these newly opened windows and return to the Windows 11 setup, where you will enter local account information.
  
-    For Windows 11 version 22H2, the following sequence of actions to use a local account instead of a Microsoft account has been published:
+  - For Windows 11 version 22H2, the following sequence of actions to use a local account instead of a Microsoft account has been published:
 
     - Enter `no@thankyou.com` (or some other senseless address) as the email address and click `Next` when Windows 11 setup prompts you to log into your Microsoft account.
     - Enter any text you want in the password field and click `Sign in`. If this method works, you'll get a message saying "Oops, something went wrong."

From ececab9a45884c85c2475589619649962a00f883 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Tue, 24 Sep 2024 17:51:35 -0700
Subject: [PATCH 220/332] Add NitroPad V56

---
 user/hardware/certified-hardware.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/user/hardware/certified-hardware.md b/user/hardware/certified-hardware.md
index f6c6fd43..41b825fe 100644
--- a/user/hardware/certified-hardware.md
+++ b/user/hardware/certified-hardware.md
@@ -25,6 +25,12 @@ Qubes-certified computers are certified for a [major release](/doc/version-schem
 
 The current Qubes-certified models are listed below in reverse chronological order of certification.
 
+### NitroPad V56
+
+[![Photo of the NitroPad V56](/attachment/site/nitropad-v56.png)](https://shop.nitrokey.com/shop/nitropad-v56-684)
+
+The [NitroPad V56](https://shop.nitrokey.com/shop/nitropad-v56-684) is certified for Qubes OS Release 4.
+
 ### NovaCustom V56 Series 16.0 inch coreboot laptop
 
 [![Photo of the NovaCustom V56 Series 16.0 inch coreboot laptop](/attachment/site/novacustom-v56-series.png)](https://novacustom.com/product/v56-series/)

From 0d9309ed58109c7374c58bcf3626c58378e31e26 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Fri, 27 Sep 2024 13:22:43 -0400
Subject: [PATCH 221/332] rst conversion omitting extra space

---
 user/templates/debian/debian-upgrade.md | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/user/templates/debian/debian-upgrade.md b/user/templates/debian/debian-upgrade.md
index 12552f22..dd626566 100644
--- a/user/templates/debian/debian-upgrade.md
+++ b/user/templates/debian/debian-upgrade.md
@@ -189,13 +189,11 @@ instructions](https://www.debian.org/releases/buster/amd64/release-notes/ch-upgr
 
 * If sound is not working, you may need to enable the Qubes testing repository
   to get the testing version of `qubes-gui-agent`. This can be done by editing
-  the `/etc/apt/sources.list.d/qubes-r4.list` file and uncommenting the `Qubes
-  Updates Candidates` repo.
+  the `/etc/apt/sources.list.d/qubes-r4.list` file and uncommenting the `Qubes Updates Candidates` repo.
 
 * User-initiated updates/upgrades may not run when a template first starts.
   This is due to a new Debian config setting that attempts to update
-  automatically; it should be disabled with `sudo systemctl disable
-  apt-daily.{service,timer}`.
+  automatically; it should be disabled with `sudo systemctl disable apt-daily.{service,timer}`.
 
 Relevant discussions:
 

From da85dd62d4b542f6f756183118f3c373d2918824 Mon Sep 17 00:00:00 2001
From: m <3440586+maiska@users.noreply.github.com>
Date: Fri, 27 Sep 2024 13:48:11 -0400
Subject: [PATCH 222/332] from bold to italic in title for better rst
 conversion

---
 user/how-to-guides/how-to-copy-from-dom0.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/how-to-guides/how-to-copy-from-dom0.md b/user/how-to-guides/how-to-copy-from-dom0.md
index 0aacfcbb..321bc680 100644
--- a/user/how-to-guides/how-to-copy-from-dom0.md
+++ b/user/how-to-guides/how-to-copy-from-dom0.md
@@ -15,7 +15,7 @@ title: How to copy from dom0
 This page covers copying files and clipboard text between [dom0](/doc/glossary/#dom0) and [domUs](/doc/glossary/#domu).
 Since dom0 is special, the processes are different from [copying and pasting text between qubes](/doc/how-to-copy-and-paste-text/) and [copying and moving files between qubes](/doc/how-to-copy-and-move-files/).
 
-## Copying **from** dom0
+## Copying *from* dom0
 
 ### Copying files from dom0
 
@@ -61,7 +61,7 @@ In order to easily copy/paste the contents of logs from dom0 to the inter-VM cli
 
 You may now paste the log contents in qube as you normally would (e.g., Ctrl+Shift+V, then Ctrl+V).
 
-## Copying **to** dom0
+## Copying *to* dom0
 
 Copying anything into dom0 is not advised, since doing so can compromise the security of your Qubes system.
 For this reason, there is no simple means of copying anything into dom0, unlike [copying from dom0](#copying-from-dom0).

From 89f81ecf82d1dcd5ee912b8b9381027be6d8ab65 Mon Sep 17 00:00:00 2001
From: qm <3440586+qm@users.noreply.github.com>
Date: Fri, 4 Oct 2024 10:27:11 -0400
Subject: [PATCH 223/332] added sublists for better rst conversion formatting

---
 user/hardware/system-requirements.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/user/hardware/system-requirements.md b/user/hardware/system-requirements.md
index ffe39f7c..63aabd50 100644
--- a/user/hardware/system-requirements.md
+++ b/user/hardware/system-requirements.md
@@ -122,7 +122,7 @@ We recommend consulting these resources when selecting hardware for Qubes OS:
   2. The user's OEM, ODM, or MB to provide a suitable BIOS or (U)EFI update for
   the user's system.
   
-  Historically, AMD has often been slow to complete step (1), at least for its
+  - Historically, AMD has often been slow to complete step (1), at least for its
   client (as opposed to server) platforms. In some cases, AMD has made fixes
   available for its server platforms very shortly after a security embargo was
   lifted, but it did not make fixes available for client platforms facing the
@@ -132,10 +132,10 @@ We recommend consulting these resources when selecting hardware for Qubes OS:
   new CPU vulnerabilities across its supported platforms very shortly after
   security embargoes have been lifted.
 
-  Step (2) varies by vendor. Many vendors fail to complete step (2) at all,
+  - Step (2) varies by vendor. Many vendors fail to complete step (2) at all,
   while some others take a very long time to complete it.
   
-  The bottom line is that Qubes OS **can** run on AMD systems, and the Qubes and
+  - The bottom line is that Qubes OS **can** run on AMD systems, and the Qubes and
   Xen security teams do their best to provide security support for AMD systems.
   However, without the ability to ship microcode updates, there is only so much
   they can do.

From dd93bd2d56917ea8e5f6ceb919cd9ea49b175b75 Mon Sep 17 00:00:00 2001
From: Matthew <944951+Chiramisu@users.noreply.github.com>
Date: Fri, 4 Oct 2024 23:29:05 -0700
Subject: [PATCH 224/332] Fixes broken link to Xen Project Overview in intro.md

---
 introduction/intro.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/introduction/intro.md b/introduction/intro.md
index 142d4095..a9089ea6 100644
--- a/introduction/intro.md
+++ b/introduction/intro.md
@@ -19,7 +19,7 @@ title: Introduction
     <p>
       Qubes OS is a free and open-source, security-oriented operating system for
       single-user desktop computing. Qubes OS leverages
-      <a href="https://wiki.xen.org/wiki/Xen_Project_Software_Overview">
+      <a href="https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview">
       Xen-based virtualization</a> to allow for the creation and management of
       isolated compartments called <a href="/doc/glossary#qube">qubes</a>.
     </p>

From 78b074236271586a3522caa2a793cc951cfe812d Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Sun, 6 Oct 2024 04:06:46 -0700
Subject: [PATCH 225/332] Replace RSK attributes in examples with variables

Users keep getting confused because their output doesn't match the
examples, even though the text already says, "This is just an example,
so the output you receive may not look exactly the same."

Recent examples of this:
- https://www.reddit.com/r/Qubes/comments/1f2b221/
- https://forum.qubes-os.org/t/29384

Specifically, users seem to get confused because their RSK has a
different date and key ID than the one in the example (which makes
sense, because RSKs change with each release), so replacing these
specific values with variables may avert some confusion.
---
 project-security/verifying-signatures.md | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/project-security/verifying-signatures.md b/project-security/verifying-signatures.md
index 5a474674..54e230e8 100644
--- a/project-security/verifying-signatures.md
+++ b/project-security/verifying-signatures.md
@@ -375,11 +375,11 @@ by the QMSK:
 
 ```shell_session
 $ gpg2 --check-signatures "Qubes OS Release X Signing Key"
-pub   rsa4096 2017-03-06 [SC]
-      5817A43B283DE5A9181A522E1848792F9E2795E9
+pub   rsa4096 YYYY-MM-DD [SC]
+      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 uid           [  full  ] Qubes OS Release X Signing Key
-sig!3        1848792F9E2795E9 2017-03-06  Qubes OS Release X Signing Key
-sig!         DDFA1A3E36879494 2017-03-08  Qubes Master Signing Key
+sig!3        XXXXXXXXXXXXXXXX YYYY-MM-DD  Qubes OS Release X Signing Key
+sig!         DDFA1A3E36879494 YYYY-MM-DD  Qubes Master Signing Key
 
 gpg: 2 good signatures
 ```
@@ -397,9 +397,9 @@ As a final sanity check, make sure the RSK is in your keyring with the correct
 trust level:
 
 ```shell_session
-$ gpg2 -k "Qubes OS Release"
-pub   rsa4096 2017-03-06 [SC]
-      5817A43B283DE5A9181A522E1848792F9E2795E9
+$ gpg2 -k "Qubes OS Release X Signing Key"
+pub   rsa4096 YYYY-MM-DD [SC]
+      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 uid           [  full  ] Qubes OS Release X Signing Key
 ```
 
@@ -533,7 +533,7 @@ $ gpg2 -v --verify Qubes-RX-x86_64.iso.DIGESTS
 gpg: armor header: Hash: SHA256
 gpg: armor header: Version: GnuPG v2
 gpg: original file name=''
-gpg: Signature made Tue 20 Sep 2016 10:37:03 AM PDT using RSA key ID 03FA5082
+gpg: Signature made <TIME> using RSA key ID 03FA5082
 gpg: using PGP trust model
 gpg: Good signature from "Qubes OS Release X Signing Key"
 gpg: textmode signature, digest algorithm SHA256
@@ -578,7 +578,7 @@ executing this GPG command in the directory that contains both files:
 ```shell_session
 $ gpg2 -v --verify Qubes-RX-x86_64.iso.asc Qubes-RX-x86_64.iso
 gpg: armor header: Version: GnuPG v1
-gpg: Signature made Tue 08 Mar 2016 07:40:56 PM PST using RSA key ID 03FA5082
+gpg: Signature made <TIME> using RSA key ID 03FA5082
 gpg: using PGP trust model
 gpg: Good signature from "Qubes OS Release X Signing Key"
 gpg: binary signature, digest algorithm SHA256
@@ -698,8 +698,8 @@ Qubes ISOs](#how-to-verify-detached-pgp-signatures-on-qubes-isos).)
 
 ```shell_session
 $ dd if=/dev/sdX bs=1M count=<ISO_SIZE> iflag=count_bytes | gpg -v --verify Qubes-RX-x86_64.iso.asc -
-gpg: Signature made Thu 14 Jul 2022 08:49:38 PM PDT
-gpg:                using RSA key 5817A43B283DE5A9181A522E1848792F9E2795E9
+gpg: Signature made <TIME>
+gpg:                using RSA key XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 gpg: using pgp trust model
 gpg: Good signature from "Qubes OS Release X Signing Key" [full]
 gpg: binary signature, digest algorithm SHA256, key algorithm rsa4096

From c263b40758a4b0bbd6792d054e88d1961faf10b9 Mon Sep 17 00:00:00 2001
From: Marnix Croes <93143998+MarnixCroes@users.noreply.github.com>
Date: Thu, 10 Oct 2024 13:46:53 +0200
Subject: [PATCH 226/332] fix link to section

---
 user/hardware/system-requirements.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/hardware/system-requirements.md b/user/hardware/system-requirements.md
index ffe39f7c..6512dd53 100644
--- a/user/hardware/system-requirements.md
+++ b/user/hardware/system-requirements.md
@@ -37,9 +37,9 @@ title: System requirements
   - [Intel VT-x](https://en.wikipedia.org/wiki/X86_virtualization#Intel_virtualization_.28VT-x.29) with [EPT](https://en.wikipedia.org/wiki/Second_Level_Address_Translation#Extended_Page_Tables)
   - [Intel VT-d](https://en.wikipedia.org/wiki/X86_virtualization#Intel-VT-d)
   - For security, we recommend processors that are recent enough to still be
-    receiving microcode updates (see [below](#important-updates) for details).
+    receiving microcode updates (see [below](#important-notes) for details).
   - AMD processors are not recommended due to inconsistent security support on
-    client platforms (see [below](#important-updates) for details).
+    client platforms (see [below](#important-notes) for details).
 
 - **Memory:** 16 GB RAM
 

From 8ae7c2495886fa33c0b7fa63c5329bbc7fb796c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>
Date: Sun, 20 Oct 2024 00:41:01 +0200
Subject: [PATCH 227/332] Update docs about /rw/config/rc.local* scripts

Specify that files needs to be executable.
Add info about `/rw/config/rc.local.d/*.rc`.
Add info about `/rw/config/rc.local-early.d/*.rc` and
`/rw/config/rc.local-early`
(https://github.com/QubesOS/qubes-core-agent-linux/pull/386)
---
 user/advanced-topics/config-files.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/user/advanced-topics/config-files.md b/user/advanced-topics/config-files.md
index 3ffdfd55..db8a7f07 100644
--- a/user/advanced-topics/config-files.md
+++ b/user/advanced-topics/config-files.md
@@ -19,7 +19,7 @@ That way, they can be used to customize a single VM instead of all VMs based on
 The scripts here all run as root.
 
 - `/rw/config/rc.local` - script runs at VM startup.
-    Good place to change some service settings, replace config files with its copy stored in `/rw/config`, etc.
+    Good place to change some service settings, replace config files with its copy stored in `/rw/config`, etc. The script need to have the executable permission set to be executed.
     Example usage:
 
     ~~~
@@ -33,6 +33,8 @@ The scripts here all run as root.
     echo '127.0.0.1 example.com' >> /etc/hosts
     ~~~
 
+- `/rw/config/rc.local.d/*.rc` - scripts run at VM startup just before `/rw/config/rc.local`
+- `/rw/config/rc.local-early.d/*.rc`, `/rw/config/rc.local-early` - scripts similar to `/rw/config/rc.local`, but running earlier in the system startup sequence - just before `sysinit.target`, and setting up the network.
 - `/rw/config/qubes-ip-change-hook` - script runs in NetVM after every external IP change and on "hardware" link status change.
 
 - In ProxyVMs (or app qubes with `qubes-firewall` service enabled), scripts placed in the following directories will be executed in the listed order followed by `qubes-firewall-user-script` at start up.

From 6b21fa65f3976b1df59b6780d2330a2052e46ad7 Mon Sep 17 00:00:00 2001
From: Ali Mirjamali <ali@mirjamali.com>
Date: Sun, 27 Oct 2024 15:57:04 +0330
Subject: [PATCH 228/332] Document global clipboard for GUI protocol 1.8

According to: https://github.com/QubesOS/qubes-gui-daemon/pull/150#issuecomment-2431883322
According to: https://github.com/QubesOS/qubes-gui-daemon/pull/150#issuecomment-2432486669
---
 developer/system/gui.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/developer/system/gui.md b/developer/system/gui.md
index dfd04801..6de31dc7 100644
--- a/developer/system/gui.md
+++ b/developer/system/gui.md
@@ -90,9 +90,10 @@ Clipboard sharing implementation
 Certainly, it would be insecure to allow AppVM to read/write the clipboards of other AppVMs unconditionally.
 Therefore, the following mechanism is used:
 
-- there is a "qubes clipboard" in dom0 - its contents are stored in a regular file in dom0.
+- there is a "qubes clipboard" in dom0 - its contents are stored in a regular file in dom0 as `/run/qubes/qubes-clipboard.bin`.
 - if the user wants to copy local AppVM clipboard to qubes clipboard, she must focus on any window belonging to this AppVM, and press **Ctrl-Shift-C**. This combination is trapped by `qubes-guid`, and `CLIPBOARD_REQ` message is sent to AppVM. `qubes-gui` responds with `CLIPBOARD_DATA` message followed by clipboard contents.
 - the user focuses on other AppVM window, presses **Ctrl-Shift-V**. This combination is trapped by `qubes-guid`, and `CLIPBOARD_DATA` message followed by qubes clipboard contents is sent to AppVM; `qubes-gui` copies data to the local clipboard, and then user can paste its contents to local applications normally.
+- a supplementary JSON metadata file will be saved as `/run/qubes/qubes-clipboard.bin.metadata` on global clipboard copy or paste actions. Explanation of each field is available in `xside.h` header file of `qubes-guid` under `clipboard_metadata` structure. While the output from `qubes-guid` is fully JSON compatible, the `qubes-guid` parser is limited. It expects line breaks after each key-value pair and only one key-value pair per line. Opening and closing curly braces should be on their own lines. There should be no leading white-space.
 
 This way, the user can quickly copy clipboards between AppVMs.
 This action is fully controlled by the user, it cannot be triggered/forced by any AppVM.

From 721d22d064ec6be92e8276253b96402de0b17779 Mon Sep 17 00:00:00 2001
From: Marnix Croes <93143998+MarnixCroes@users.noreply.github.com>
Date: Wed, 30 Oct 2024 07:09:22 -0400
Subject: [PATCH 229/332] add info about refresh applications

---
 user/how-to-guides/how-to-back-up-restore-and-migrate.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/user/how-to-guides/how-to-back-up-restore-and-migrate.md b/user/how-to-guides/how-to-back-up-restore-and-migrate.md
index fa33d83e..fe46354d 100644
--- a/user/how-to-guides/how-to-back-up-restore-and-migrate.md
+++ b/user/how-to-guides/how-to-back-up-restore-and-migrate.md
@@ -160,6 +160,9 @@ out.
 6. When you are ready, click **Next**. Qubes will proceed to restore from your
 backup. Once the progress bar has completed, you may click **Finish**.
 
+In case that applications are not shown, i.e. "No applications found", open the
+settings of the qube -> select `Applications` -> click `Refresh applications`.
+
 **Note:** When restoring from a dom0 backup, a new directory will be created in
 the current dom0 home directory, and the contents from the backup will be
 placed inside this new directory. This is intentional, as it allows users to

From eea342bdb0e10097f3d00fc670ee7e1135f3fa74 Mon Sep 17 00:00:00 2001
From: Piotr Bartman-Szwarc <prbartman@invisiblethingslab.com>
Date: Tue, 12 Nov 2024 13:05:49 +0100
Subject: [PATCH 230/332] migration to fido2: proxy setup clarification to
 avoid confusing errors

solves QubesOS/qubes-issues/issues/9064
---
 user/security-in-qubes/ctap-proxy.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/security-in-qubes/ctap-proxy.md b/user/security-in-qubes/ctap-proxy.md
index 92e127dc..4c858532 100644
--- a/user/security-in-qubes/ctap-proxy.md
+++ b/user/security-in-qubes/ctap-proxy.md
@@ -85,7 +85,7 @@ $ sudo qubes-dom0-update qubes-ctap-dom0
 $ qvm-service --enable work qubes-ctap-proxy
 ```
 
-The above assumes a `work` qube in which you would like to enable ctap. Repeat the `qvm-service` command for all qubes that should have the proxy enabled.  Alternatively, you can add `qubes-ctap-proxy` in VM settings -> Services in the Qube Manager of each qube you would like to enable the service.
+The above assumes a `work` qube in which you would like to enable ctap. Repeat the `qvm-service` command for all qubes that should have the client proxy enabled.  Alternatively, you can add `qubes-ctap-proxy` in VM settings -> Services in the Qube Manager of each qube you would like to enable the service. Attempting to start the `qubes-ctap-proxy` service in the device-hosting qube (`sys-usb`) will fail.
 
 In Fedora templates:
 

From d1cb9bd2fb45c76fcd59a3b538b0f2c6497442b3 Mon Sep 17 00:00:00 2001
From: Rowen S <ro@freedom.press>
Date: Mon, 25 Nov 2024 13:56:59 -0500
Subject: [PATCH 231/332] Add documentation on qubes-fwupdmgr usage

---
 user/how-to-guides/how-to-update.md | 54 +++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/user/how-to-guides/how-to-update.md b/user/how-to-guides/how-to-update.md
index 2462bafb..e736e750 100644
--- a/user/how-to-guides/how-to-update.md
+++ b/user/how-to-guides/how-to-update.md
@@ -17,6 +17,7 @@ Fully updating your Qubes OS system means updating:
 - [dom0](/doc/glossary/#dom0)
 - [templates](/doc/glossary/#template)
 - [standalones](/doc/glossary/#standalone) (if you have any)
+- your computer's [firmware](https://en.wikipedia.org/wiki/Firmware)
 
 ## Security updates
 
@@ -86,3 +87,56 @@ In the case of Qubes OS itself, we will make an [announcement](/news/categories/
 Periodic upgrades are also important for templates. For example, you might be using a [Fedora template](/doc/templates/fedora/). The [Fedora Project](https://getfedora.org/) is independent of the Qubes OS Project. They set their own [schedule](https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule) for when each Fedora release reaches EOL. You can always find out when an OS reaches EOL from the upstream project that maintains it. We also pass along any EOL notices we receive for official template OSes as a convenience to Qubes users (see the [supported template releases](/doc/supported-releases/#templates)).
 
 The one exception to all this is the specific release used for dom0 (not to be confused with Qubes OS as a whole), which [doesn't have to be upgraded](/doc/supported-releases/#note-on-dom0-and-eol).
+
+## Firmware updates
+
+As of Qubes 4.2, firmware updates can be performed from within Qubes for [fwupd-supported computers](https://fwupd.org/).
+
+### In dom0
+
+First, ensure that your [UpdateVM](/doc/Software/UpdateVM/)
+contains the `fwupd-qubes-vm` package. This package is installed
+by default for qubes with `qubes-vm-recommended` packages.
+
+In a dom0 terminal, install the `fwupd-qubes-dom0` package:
+
+  ```
+  $ sudo qubes-dom0-update fwupd-qubes-dom0
+  ```
+
+Once the package is installed:
+
+   ```
+   $ sudo qubes-fwupdmgr get-devices
+   ```
+
+Examine the terminal output for warnings or errors.
+You may see the following warning:
+
+   ```
+   WARNING: UEFI capsule updates not available or enabled
+   ```
+If so, [adjust your BIOS settings](https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported) to enable UEFI updates. This setting is sometimes named "Windows UEFI Firmware Update."
+
+Once resolved, in a dom0 terminal:
+
+  ```
+  $ sudo qubes-fwupdmgr get-devices
+  $ sudo qubes-fwupdmgr refresh
+  $ sudo qubes-fwupdmgr update
+  ```
+
+A numbered list of devices with available updates will be presented. Ensure your computer is plugged in to a stable power source, then type the list number of the device you wish to update. If a reboot is required, you will be prompted at the console to confirm.
+
+Repeat the update process for any additional devices on your computer.
+
+### In other qubes
+
+Devices that are attached to non-dom0 qubes can be updated via a graphical tool for `fwupd`, or via the `fwupdmgr` commandline tool.
+
+To update the firmware of offline qubes, use the [Updates
+proxy](/doc/how-to/install/software/#updates-proxy).
+
+### Computers without fwupd support
+
+For computers that do not have firmware update support via `fwupd`, follow the firmware update instructions on the manufacturer's website. Verify the authenticity of any firmware updates you apply.

From 7c7911177f2709dce43ce937949ad9895e302c3e Mon Sep 17 00:00:00 2001
From: b90g <63392812+b90g@users.noreply.github.com>
Date: Fri, 29 Nov 2024 20:21:29 +0100
Subject: [PATCH 232/332] Update windows-qubes-4-1.md

evading microsoft account enforcement.
---
 user/templates/windows/windows-qubes-4-1.md | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/user/templates/windows/windows-qubes-4-1.md b/user/templates/windows/windows-qubes-4-1.md
index 4d38a4bb..a89fd2ae 100644
--- a/user/templates/windows/windows-qubes-4-1.md
+++ b/user/templates/windows/windows-qubes-4-1.md
@@ -172,7 +172,15 @@ These parameters are set for the following reasons:
     - Click `Next`. A screen appears saying "Who's going to use this device?" This is the local account creation screen.
     - Enter the username you want to use and click `Next`.
     - Enter a password and click `Next`. You can leave the field blank but it's not recommended.
+   
+    For Windows 11 version 24H2, the following sequence of actions to use a local account instead of a Microsoft account has been proved working:
 
+    - Boot with a disconnected machine.
+    - When you reach the “Let’s Connect You To A Network” page, type Shift-F10 to open a console window.
+    - Enter `oobe\bypassnro` and hit enter.
+    - The machine will restart and then lets you setup a local account.
+    - Machine then can go online again if desired.
+   
 - On systems shipped with a Windows license, the product key may be read from flash via root in dom0:
 
     `strings < /sys/firmware/acpi/tables/MSDM`

From a2d0d042dce2c6dde7fde901851e11af9461ded5 Mon Sep 17 00:00:00 2001
From: kennethrrosen <kennethrrosen@proton.me>
Date: Sat, 30 Nov 2024 11:34:26 +0000
Subject: [PATCH 233/332] Add standalone timeout note

Note standalone `qrexec_timeout` workaround QubesOS/qubes-issues/issues/9251
---
 user/advanced-topics/resize-disk-image.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/user/advanced-topics/resize-disk-image.md b/user/advanced-topics/resize-disk-image.md
index b7805bd2..c06eaa1b 100644
--- a/user/advanced-topics/resize-disk-image.md
+++ b/user/advanced-topics/resize-disk-image.md
@@ -32,7 +32,8 @@ In most cases, the GUI tool Qube Settings (available for every qube from the Sta
 
 ![vm-settings-disk-image.png](/attachment/doc/r4.0-vm-settings-disk-image.png)
 
-In case of standalone qubes and templates, just change the Disk Storage settings above.
+In case of standalone qubes and templates, just change the Disk Storage settings above. If the standalone fails to start, temporarily increase the `qrexec_timeout`, [as described here](https://github.com/QubesOS/qubes-issues/issues/9251#issuecomment-2121596415).
+
 In case of template-based qubes, the private storage (the /home directory and user files) can be changed in the qube's own settings, but the system root image is [inherited from the template](/doc/getting-started/), and so it must be changed in the template settings.
 If you are increasing the disk image size for Linux-based qubes installed from Qubes OS repositories in Qubes 4.0 or later, changing the settings above is all you need to do - in other cases, you may need to do more, according to instructions below.
 See also the OS-specific follow-up instructions below.

From ae26177e4d01d180a959b99ec02d94fc7e265747 Mon Sep 17 00:00:00 2001
From: Christian Tramnitz <ctr49@users.noreply.github.com>
Date: Sun, 1 Dec 2024 12:39:23 +0100
Subject: [PATCH 234/332] add known issues to gui-domain docs

Although sys-gui (and its variants sys-gui-gpu and sys-gui-vnc) are clearly marked to be used by advanced users only, there are some limitations that may go beyond the expectations of an advanced user.

This updates the documentation to contain some known issues that probably don't have a quick fix.
---
 user/advanced-topics/gui-domain.md | 28 ++++++++++++++++++++++------
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/user/advanced-topics/gui-domain.md b/user/advanced-topics/gui-domain.md
index c9aa6f58..6c18d51f 100644
--- a/user/advanced-topics/gui-domain.md
+++ b/user/advanced-topics/gui-domain.md
@@ -120,13 +120,33 @@ A VNC server session is running on `localhost:5900` in `sys-gui-vnc`. In order t
 > **WARNING**: This setup raises multiple security issues: 1) Anyone who can reach the `VNC` server, can take over the control of the Qubes OS machine, 2) A second client can connect even if a connection is already active and potentially get disconnected, 3) You can get disconnected by some unrelated network issues. Generally, if this `VNC` server is exposed to open network, it must be protected with some other (cryptographic) layer like `VPN`. The setup as is, is useful only for purely testing machine.
 
 
-### Troubleshooting
+### Known issues
 
 #### Application menu lacks qubes entries in a fresh GUI domain
 
 See [QubesOS/qubes-issues#5804](https://github.com/QubesOS/qubes-issues/issues/5804)
 
-#### Delete GUI domain
+#### Cannot update dom0 from sys-gui
+
+See [QubesOS/qubes-issues#8934](https://github.com/QubesOS/qubes-issues/issues/8934)
+
+#### GUI of HVM qubes not visible
+
+See [QubesOS/qubes-issues#9385](https://github.com/QubesOS/qubes-issues/issues/9385)
+
+### Power saving/screensaver issues
+
+See [QubesOS/qubes-issues#9033](https://github.com/QubesOS/qubes-issues/issues/9033), [QubesOS/qubes-issues#9384](https://github.com/QubesOS/qubes-issues/issues/9384), [QubesOS/qubes-issues#7989](https://github.com/QubesOS/qubes-issues/issues/7989)
+
+#### Qube startup order (sys-usb and sys-gui)
+
+See [QubesOS/qubes-issues#7954](https://github.com/QubesOS/qubes-issues/issues/7954)
+
+#### Other GUI domain issues
+
+see existing issues `QubesOS/qubes-issues` under [C: gui-domain](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+label%3A%22C%3A+gui-domain%22) label.
+
+### Reverting sys-gui
 
 The following commands have to be run in `dom0`.
 
@@ -149,7 +169,3 @@ You are now able to delete the GUI domain, for example `sys-gui-gpu`:
 ```bash
 qvm-remove -f sys-gui-gpu
 ```
-
-#### General issues
-
-For any general GUI domain issues, please take a loot at existing issues `QubesOS/qubes-issues` under [C: gui-domain](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+label%3A%22C%3A+gui-domain%22) label.

From 4cc913b6b0f54583ab632c86a9c7608f39d023af Mon Sep 17 00:00:00 2001
From: Darekisgit <dgrzelinski@mail.de>
Date: Wed, 4 Dec 2024 12:21:25 +0100
Subject: [PATCH 235/332] Update mfa.md

---
 user/security-in-qubes/mfa.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/security-in-qubes/mfa.md b/user/security-in-qubes/mfa.md
index 62a72e17..559f09a9 100644
--- a/user/security-in-qubes/mfa.md
+++ b/user/security-in-qubes/mfa.md
@@ -66,7 +66,7 @@ Now we are going to add the authenticator as a login requirement:
 
 1. `sudo authselect create-profile mfa --base-on sssd`
 
-2. Edit the custom system authentication template with `sudo nanois encouraged /etc/authselect/custom/mfa/system-auth`.
+2. Edit the custom system authentication template with `sudo nanois encouraged /etc/authselect/custom/mfa/system-auth`. there is an error in this line
 
    Add the following line right after `auth required pam_faildelay.so delay=2000000`:
 

From 01165e5f825a02424eb9a127e386f11f6032c375 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Sat, 7 Dec 2024 05:24:06 -0800
Subject: [PATCH 236/332] Update supported Fedora templates

- Remove Fedora 39 (EOL)
- Add Fedora 41 (QubesOS/qubes-issues#9244)
---
 user/downloading-installing-upgrading/supported-releases.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/downloading-installing-upgrading/supported-releases.md b/user/downloading-installing-upgrading/supported-releases.md
index e694dff4..30d8d4eb 100644
--- a/user/downloading-installing-upgrading/supported-releases.md
+++ b/user/downloading-installing-upgrading/supported-releases.md
@@ -57,7 +57,7 @@ It is the responsibility of each distribution to clearly notify its users in adv
 
 | Qubes OS    | Fedora | Debian |
 | ----------- | ------ | ------ |
-| Release 4.2 | 39, 40 | 12     |
+| Release 4.2 | 40, 41 | 12     |
 
 ### Note on Debian support
 

From 1fca26ce44e4613fb9e15ec47fa724545dc737c7 Mon Sep 17 00:00:00 2001
From: ghijg <70027324+ghijg@users.noreply.github.com>
Date: Tue, 10 Dec 2024 00:13:35 +0100
Subject: [PATCH 237/332] Syntax changed due to dnf5/Fedora41

Syntax changed for enabling repositories with dnf5 which is used by default from Fedora 41 on.

https://dnf5.readthedocs.io/en/latest/changes_from_dnf4.7.html
---
 user/how-to-guides/how-to-install-software.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/user/how-to-guides/how-to-install-software.md b/user/how-to-guides/how-to-install-software.md
index da7aae0e..83c70701 100644
--- a/user/how-to-guides/how-to-install-software.md
+++ b/user/how-to-guides/how-to-install-software.md
@@ -227,10 +227,10 @@ depending on which RPM Fusion repositories you wish to enable (see [RPM
 Fusion](https://rpmfusion.org/) for details):
 
 ~~~
-sudo dnf config-manager --set-enabled rpmfusion-free
-sudo dnf config-manager --set-enabled rpmfusion-free-updates
-sudo dnf config-manager --set-enabled rpmfusion-nonfree
-sudo dnf config-manager --set-enabled rpmfusion-nonfree-updates
+sudo dnf config-manager setopt rpmfusion-free.enabled=1
+sudo dnf config-manager setopt rpmfusion-free-updates.enabled=1
+sudo dnf config-manager setopt rpmfusion-nonfree.enabled=1
+sudo dnf config-manager setopt rpmfusion-nonfree-updates.enabled=1
 sudo dnf upgrade --refresh
 ~~~
 

From cc001965399ce3ac66c9f854e6e776aa16ff6906 Mon Sep 17 00:00:00 2001
From: Rusty Bird <rustybird@net-c.com>
Date: Fri, 20 Dec 2024 19:29:36 +0000
Subject: [PATCH 238/332] luksFormat: add --sector-size=512 argument

---
 user/advanced-topics/secondary-storage.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/user/advanced-topics/secondary-storage.md b/user/advanced-topics/secondary-storage.md
index 24d97e2c..391e3059 100644
--- a/user/advanced-topics/secondary-storage.md
+++ b/user/advanced-topics/secondary-storage.md
@@ -65,10 +65,12 @@ In theory, you can still use file-based disk images ("file" pool driver), but it
 Assuming the secondary hard disk is at /dev/sdb (it will be completely erased), you can set it up for encryption by doing in a dom0 terminal (use the same passphrase as the main Qubes disk to avoid a second password prompt at boot):
 
 ```
-sudo cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sdb
+sudo cryptsetup luksFormat --sector-size=512 --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sdb
 sudo blkid /dev/sdb
 ```
 
+(The `--sector-size=512` argument can sometimes work around an incompatibility of storage hardware with LVM thin pools on Qubes. If this does not apply to your hardware, the argument will make no difference.)
+
 Note the device's UUID (in this example "b209..."), we will use it as its luks name for auto-mounting at boot, by doing:
 
 ```

From 4fb0f0c851a44aeecd0778bca3c9babeebc79ec6 Mon Sep 17 00:00:00 2001
From: Rusty Bird <rustybird@net-c.com>
Date: Fri, 20 Dec 2024 19:29:37 +0000
Subject: [PATCH 239/332] luksFormat: drop arguments that are already the
 default

---
 user/advanced-topics/secondary-storage.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/advanced-topics/secondary-storage.md b/user/advanced-topics/secondary-storage.md
index 391e3059..3e2e8cf9 100644
--- a/user/advanced-topics/secondary-storage.md
+++ b/user/advanced-topics/secondary-storage.md
@@ -65,7 +65,7 @@ In theory, you can still use file-based disk images ("file" pool driver), but it
 Assuming the secondary hard disk is at /dev/sdb (it will be completely erased), you can set it up for encryption by doing in a dom0 terminal (use the same passphrase as the main Qubes disk to avoid a second password prompt at boot):
 
 ```
-sudo cryptsetup luksFormat --sector-size=512 --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sdb
+sudo cryptsetup luksFormat --sector-size=512 --hash=sha512 /dev/sdb
 sudo blkid /dev/sdb
 ```
 

From 65e0511d1521be509a5226296ce9912b39d2eac8 Mon Sep 17 00:00:00 2001
From: Rusty Bird <rustybird@net-c.com>
Date: Fri, 20 Dec 2024 19:29:38 +0000
Subject: [PATCH 240/332] luksFormat: drop --hash=sha512 argument

The default (sha256) seems fine for LUKS2 where the hash algorithm has a
limited role anyway - it's not used for key stretching like in LUKS1.
---
 user/advanced-topics/secondary-storage.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/advanced-topics/secondary-storage.md b/user/advanced-topics/secondary-storage.md
index 3e2e8cf9..d541c3c3 100644
--- a/user/advanced-topics/secondary-storage.md
+++ b/user/advanced-topics/secondary-storage.md
@@ -65,7 +65,7 @@ In theory, you can still use file-based disk images ("file" pool driver), but it
 Assuming the secondary hard disk is at /dev/sdb (it will be completely erased), you can set it up for encryption by doing in a dom0 terminal (use the same passphrase as the main Qubes disk to avoid a second password prompt at boot):
 
 ```
-sudo cryptsetup luksFormat --sector-size=512 --hash=sha512 /dev/sdb
+sudo cryptsetup luksFormat --sector-size=512 /dev/sdb
 sudo blkid /dev/sdb
 ```
 

From 62d9a4f0844114b1abc9f77d0e0f37a5473abbf9 Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Tue, 14 Jan 2025 20:51:46 -0500
Subject: [PATCH 241/332] Fixed hierarchy of titles and added a fullstop

---
 user/advanced-topics/bind-dirs.md |  2 +-
 user/advanced-topics/i3.md        | 10 +++++-----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/user/advanced-topics/bind-dirs.md b/user/advanced-topics/bind-dirs.md
index 210eb383..0481dfb8 100644
--- a/user/advanced-topics/bind-dirs.md
+++ b/user/advanced-topics/bind-dirs.md
@@ -92,7 +92,7 @@ Note that you must create the full folder structure under `/rw/bind-dirs` - e.g
 Any changes you make will not survive a reboot. If you think it likely you will want to edit a file, then either include the parent directory in bind-dirs rather than the file, or perform the file operation on the file in `/rw/bind-dirs`.
 * Some files are altered when a qube boots - e.g. `/etc/hosts`.
 If you try to use bind-dirs on such files you may break your qube in unpredictable ways.
-You can add persistent rules to `/etc/hosts` using [`/rw/config/rc.local`](/doc/config-files)
+You can add persistent rules to `/etc/hosts` using [`/rw/config/rc.local`](/doc/config-files).
 
 ## How to remove binds from bind-dirs.sh?
 
diff --git a/user/advanced-topics/i3.md b/user/advanced-topics/i3.md
index b326988d..6df92a3e 100644
--- a/user/advanced-topics/i3.md
+++ b/user/advanced-topics/i3.md
@@ -24,7 +24,7 @@ optionally in case you would prefer writing your own configuration (see
 
 That's it. After logging out, you can select i3 in the login manager.
 
-### Customization
+# Customization
 
 **Caution:** The following external resources may not have been reviewed by the Qubes team.
 
@@ -34,13 +34,13 @@ That's it. After logging out, you can select i3 in the login manager.
 * [i3 config with dmenu-i3-window-jumper](https://github.com/anadahz/qubes-i3-config/blob/master/config)
 * [dmenu script to open a terminal in a chosen VM](https://gist.github.com/dmoerner/65528941dd20b05c98ee79e92d7e0183)
 
-## Compilation and installation from source
+# Compilation and installation from source
 
 Note that the compilation from source is done in a Fedora based domU (could
 be dispvm). The end result is always an `.rpm` that is copied to dom0 and then
 installed through the package manager.
 
-### Getting the code
+## Getting the code
 
 Clone the i3-qubes repository here:
 
@@ -57,7 +57,7 @@ OS and changes some defaults so the user can't override decisions.
 If you want to make any changes to the package, this is the time and place to do
 it.
 
-### Building
+## Building
 
 You'll need to install the build dependencies, which are listed in
 build-deps.list. You can verify them and then install them with:
@@ -76,7 +76,7 @@ $ make verify-sources
 $ make rpms
 ```
 
-### Installing
+## Installing
 
 **Warning**: Manually installing software in dom0 is inherently risky, and the method described here circumvents the usual security mechanisms of qubes-dom0-update.
 

From 4b625ee6667bfaacabc98263f035b63b28fe1d2a Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Wed, 15 Jan 2025 15:29:39 -0500
Subject: [PATCH 242/332] Rearranged hyperlinked words

---
 developer/system/template-implementation.md | 2 +-
 user/how-to-guides/how-to-use-devices.md    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/developer/system/template-implementation.md b/developer/system/template-implementation.md
index 4feb91fb..1cc840a6 100644
--- a/developer/system/template-implementation.md
+++ b/developer/system/template-implementation.md
@@ -27,7 +27,7 @@ This is mounted as /rw and here is placed all VM private data. This includes:
 - */usr/local* – which is symlink to /rw/usrlocal
 - some config files (/rw/config) called by qubes core scripts (ex /rw/config/rc.local)
 
-**Note:** Whenever a TemplateBasedVM is created, the contents of the `/home` directory of its parent TemplateVM [are *not* copied to the child TemplateBasedVM's `/home`](/doc/templates/#inheritance-and-persistence). The child TemplateBasedVM's `/home` is independent from its parent TemplateVM's `/home`, which means that any changes to the parent TemplateVM's `/home` will not affect the child TemplateBasedVM's `/home`. Once a TemplateBasedVM has been created, any changes in its `/home`, `/usr/local`, or `/rw/config` directories will be persistent across reboots, which means that any files stored there will still be available after restarting the TemplateBasedVM. No changes in any other directories in TemplateBasedVMs persist in this manner. If you would like to make changes in other directories which *do* persist in this manner, you must make those changes in the parent TemplateVM.
+**Note:** Whenever a TemplateBasedVM is created, the contents of the `/home` directory of its parent TemplateVM [are *not* copied to the child TemplateBasedVM's](/doc/templates/#inheritance-and-persistence) `/home`. The child TemplateBasedVM's `/home` is independent from its parent TemplateVM's `/home`, which means that any changes to the parent TemplateVM's `/home` will not affect the child TemplateBasedVM's `/home`. Once a TemplateBasedVM has been created, any changes in its `/home`, `/usr/local`, or `/rw/config` directories will be persistent across reboots, which means that any files stored there will still be available after restarting the TemplateBasedVM. No changes in any other directories in TemplateBasedVMs persist in this manner. If you would like to make changes in other directories which *do* persist in this manner, you must make those changes in the parent TemplateVM.
 
 ### modules.img (xvdd)
 
diff --git a/user/how-to-guides/how-to-use-devices.md b/user/how-to-guides/how-to-use-devices.md
index c8d2c0eb..66269c41 100644
--- a/user/how-to-guides/how-to-use-devices.md
+++ b/user/how-to-guides/how-to-use-devices.md
@@ -65,7 +65,7 @@ A list of VMs appears, one showing the eject symbol: ![eject icon](/attachment/d
 Only `mic` should be attached to more than one running VM.
 You may *assign* a device to more than one VM (using the `--persistent` option), however, only one of them can be started at the same time.
 
-But be careful: There is a [bug in `qvm-device block` or `qvm-block`](https://github.com/QubesOS/qubes-issues/issues/4692) which will allow you to *attach* a block device to two running VMs.
+But be careful: There is a [bug in](https://github.com/QubesOS/qubes-issues/issues/4692) `qvm-device block` or `qvm-block` which will allow you to *attach* a block device to two running VMs.
 Don't do that!
 
 

From e1bc45f146c571df58b338f0188c201fa64817f4 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Thu, 16 Jan 2025 07:58:38 -0800
Subject: [PATCH 243/332] Update issue tracking guidelines

- New feature: non-label issue types
- New feature: sub-issues
- Update existing guidelines to match practice
---
 introduction/issue-tracking.md | 46 +++++++++++++---------------------
 1 file changed, 18 insertions(+), 28 deletions(-)

diff --git a/introduction/issue-tracking.md b/introduction/issue-tracking.md
index 3296210e..a77a4680 100644
--- a/introduction/issue-tracking.md
+++ b/introduction/issue-tracking.md
@@ -51,36 +51,36 @@ Great! Thank you for taking the time and effort to help improve Qubes! To ensure
 
 Eventually, your issue may be closed. See [how issues get closed](/doc/issue-tracking/#how-issues-get-closed) for details about when, why, and how this occurs.
 
-## Labels and projects
+## How issues are organized
 
-Labels and projects are features of GitHub's issue tracking system that we use to keep [qubes-issues](https://github.com/QubesOS/qubes-issues/issues) organized.
+Issues can have several different properties and be organized in various ways. This section explains how we use labels, issue types, projects, and other features of GitHub's issue tracking system in order to keep [qubes-issues](https://github.com/QubesOS/qubes-issues/issues) organized.
 
 ### Labels
 
-When an issue is first created, certain [labels](https://github.com/QubesOS/qubes-issues/labels) may automatically be applied to it based on the type of issue the reporter selected. For example, if someone selects the "Bug report" template, then the `T: bug` label will automatically be applied to that issue. After that, only Qubes team members have permission to modify labels. Many labels have descriptions on them that can be viewed by hovering over them or on the [list of labels](https://github.com/QubesOS/qubes-issues/labels). Let's go over some of the most important ones.
-
-#### Type
-
-There are three issue **types**: `T: bug`, `T: enhancement`, and `T: task`.
-
-- `T: bug` --- Type: bug report. A problem or defect resulting in unintended behavior in something that exists.
-- `T: enhancement` --- Type: enhancement. A new feature that does not yet exist **or** improvement of existing functionality.
-- `T: task` --- Type: task. An action item that is neither a bug nor an enhancement.
-
-Every open issue should have **exactly one** type. An open issue should not have more than one type, and it should not lack a type entirely. Bug reports are for problems in things that already exist. If something doesn't exist yet, but you think it ought to exist, then use `T: enhancement` instead. If something already exists, but you think it could be improved in some way, you should again use `T: enhancement`. `T: task` is for issues that fall under neither `T: bug` nor `T: enhancement`.
+When an issue is first created, it will receive the `P: default` (i.e., default priority) [label](https://github.com/QubesOS/qubes-issues/labels) automatically. After an issue has been created, only Qubes team members have permission to modify labels. Many labels have descriptions on them that can be viewed by hovering over them or on the [list of labels](https://github.com/QubesOS/qubes-issues/labels). Let's go over some of the most important ones.
 
 #### Priority
 
-There are several issue **priority** levels ranging from `P: minor` to `P: blocker` (see [here](https://github.com/QubesOS/qubes-issues/labels?q=P%3A) for the full list). Every open issue should have **exactly one** priority. An open issue should not have more than one priority, and it should not lack a priority entirely. See [here](/doc/version-scheme/#bug-priorities) for details about how the developers use these priorities.
+There are several issue **priority** levels ranging from `P: minor` to `P: blocker` (see [here](https://github.com/QubesOS/qubes-issues/labels?q=P%3A) for the full list). Every open issue should have exactly one priority. An open issue should not have more than one priority, and it should not lack a priority entirely. See [here](/doc/version-scheme/#bug-priorities) for details about how the developers use these priorities.
 
 #### Component
 
-There are many **component** labels, each beginning with `C:` (see [here](https://github.com/QubesOS/qubes-issues/labels?q=C%3A) for the full list). Every open issue should have **at least one** component. An open issue may have more than one component, but it should not lack a component entirely. When no other component applies, use `C: other`.
+There are many **component** labels, each beginning with `C:` (see [here](https://github.com/QubesOS/qubes-issues/labels?q=C%3A) for the full list). Every open issue should have at least one component. An open issue may have more than one component, but it should not lack a component entirely. When no other component applies, use `C: other`.
 
 #### Affected release
 
 A label of the form `affects-<RELEASE_NUMBER>` indicates that an issue affects the corresponding Qubes OS release. An issue can have more than one of these labels if it affects multiple releases.
 
+### Types
+
+There are three issue **types**: Bug, Feature, and Task.
+
+- **Bug** --- An unexpected problem or behavior
+- **Feature** --- A request, idea, or new functionality
+- **Task** --- A specific piece of work
+
+Every open issue should have exactly one type. **Bug** reports are for problems in things that already exist. If something doesn't exist yet, but you think it ought to exist, then that issue should instead be a **Feature** request. If something already exists, but you think it could be improved in some way, that also qualifies as a **Feature** request. The **Task** type is for issues that are actionable but that fall under neither the **Bug** nor **Feature** types.
+
 ### Projects
 
 According to GitHub, a [project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects) is "an adaptable spreadsheet, task-board, and road map that integrates with your issues and pull requests on GitHub to help you plan and track your work effectively." The issue tracker has several [projects](https://github.com/QubesOS/qubes-issues/projects). Github projects allows more detailed issue states, and also attaching more metadata to issues. They also allow more focused view.
@@ -89,21 +89,11 @@ There is a special project in Qubes OS project: the [Current team tasks project]
 
 ### Meta-issues
 
-A meta-issue is an issue that serves to collect and organize a group of other issues. We use meta-issues when we need a way to track work on specific features. We cannot use [projects](#projects) for this, because we already use a project for tracking the work of the Qubes team as a whole, and projects cannot contain milestones or other projects.
+A meta-issue is an issue that serves primarily to collect and organize a group of other issues. This group of other issues typically exists in a hierarchy of sub-issues, usually with the meta-issue at the top. (For example, we use meta-issues when we need a way to track work on specific features. We cannot use [projects](#projects) for this, because we already use a project for tracking the work of the Qubes team as a whole, and projects cannot contain milestones or other projects.)
 
-Meta-issues must abide by the following rules:
+Meta-issues should have informative descriptions, not just lists of issues. In particular, each meta-issue should explain its goal, what is in scope, and what the relevant categories and priorities are.
 
-- Only members of the core team may create meta-issues (or convert existing issues into meta-issues).
-
-  Rationale: The purpose of meta-issues is to track the development of certain features that fit into the overall goals of the Qubes OS Project, which requires making informed project-management decisions with the approval of the project lead.
-
-- Meta-issues must be [locked](https://docs.github.com/en/communities/moderating-comments-and-conversations/locking-conversations).
-
-  Rationale: One of the historical problems we've experienced with meta-issues (and one of the reasons they were discouraged for a long time) is that each meta-issue tends to turn into a discussion thread that becomes hopelessly long to the point where the person who is supposed to work on it has no idea what is supposed to be done or where to start, and it eventually just gets closed. Locking is intended to prevent that from happening again.
-
-- Meta-issues must have informative descriptions, not just lists of issues. In particular, each meta-issue should explain its goal, what is in scope, and what the relevant categories and priorities are.
-
-- Meta-issues must have clear, concrete, and actionable criteria for when they will be closed. Meta-issues should never be "open-ended" or expected to stay open indefinitely. If this ever becomes unclear, the meta-issue should be closed until it becomes clear.
+In addition, meta-issues should have clear, concrete, and actionable criteria for when they will be closed. Meta-issues should never be "open-ended" or expected to stay open indefinitely. If this ever becomes unclear, the meta-issue should be closed until it becomes clear.
 
 ## Search tips
 

From 624c1e78228b339af944406047c6aa75d7369cee Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Thu, 16 Jan 2025 09:07:45 -0800
Subject: [PATCH 244/332] Add GitHub doc links

---
 introduction/issue-tracking.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/introduction/issue-tracking.md b/introduction/issue-tracking.md
index a77a4680..46c038fd 100644
--- a/introduction/issue-tracking.md
+++ b/introduction/issue-tracking.md
@@ -73,7 +73,7 @@ A label of the form `affects-<RELEASE_NUMBER>` indicates that an issue affects t
 
 ### Types
 
-There are three issue **types**: Bug, Feature, and Task.
+There are three issue [types](https://docs.github.com/en/issues/tracking-your-work-with-issues/configuring-issues/managing-issue-types-in-an-organization): Bug, Feature, and Task.
 
 - **Bug** --- An unexpected problem or behavior
 - **Feature** --- A request, idea, or new functionality
@@ -89,7 +89,7 @@ There is a special project in Qubes OS project: the [Current team tasks project]
 
 ### Meta-issues
 
-A meta-issue is an issue that serves primarily to collect and organize a group of other issues. This group of other issues typically exists in a hierarchy of sub-issues, usually with the meta-issue at the top. (For example, we use meta-issues when we need a way to track work on specific features. We cannot use [projects](#projects) for this, because we already use a project for tracking the work of the Qubes team as a whole, and projects cannot contain milestones or other projects.)
+A meta-issue is an issue that serves primarily to collect and organize a group of other issues. This group of other issues typically exists in a hierarchy of [sub-issues](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/adding-sub-issues), usually with the meta-issue at the top. (For example, we use meta-issues when we need a way to track work on specific features. We cannot use [projects](#projects) for this, because we already use a project for tracking the work of the Qubes team as a whole, and projects cannot contain milestones or other projects.)
 
 Meta-issues should have informative descriptions, not just lists of issues. In particular, each meta-issue should explain its goal, what is in scope, and what the relevant categories and priorities are.
 

From 79b2bfbb6b9d3f1cf2bc3adfd4e947b1b69849fe Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Thu, 16 Jan 2025 15:35:55 -0500
Subject: [PATCH 245/332] removed extra * char

---
 user/how-to-guides/how-to-install-software.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/how-to-guides/how-to-install-software.md b/user/how-to-guides/how-to-install-software.md
index 9a156b93..333f0485 100644
--- a/user/how-to-guides/how-to-install-software.md
+++ b/user/how-to-guides/how-to-install-software.md
@@ -429,7 +429,7 @@ these in an app qube you need to take the following steps:
    When the install is complete you can close the terminal window.
 
 3. Refresh the Applications list for the app qube. In the Qubes Menu for the
-   **app qube*** launch the Qube Settings. Then go to the Applications tab and
+   **app qube** launch the Qube Settings. Then go to the Applications tab and
    click "Refresh Applications"
 
    - The refresh will take a few minutes; after it's complete the Snap app will

From acfadd11938fa59ca8337b22e1f64287ec4a64be Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Thu, 16 Jan 2025 16:24:24 -0500
Subject: [PATCH 246/332] formatting

---
 user/how-to-guides/how-to-use-disposables.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/how-to-guides/how-to-use-disposables.md b/user/how-to-guides/how-to-use-disposables.md
index 25c1d43a..ffd80402 100644
--- a/user/how-to-guides/how-to-use-disposables.md
+++ b/user/how-to-guides/how-to-use-disposables.md
@@ -42,7 +42,7 @@ In Qubes 4.2, the qube will now appear in the menu as a disposable template (in
 
 In Qubes 4.1: named disposables can be created under **Application Menu -> Create Qubes VM**, set the qube type  to be _DisposableVM_.
 
-In Qubes 4.2: named disposables can be created by **Application Menu -> Settings -> Qubes Settings -> Create New Qube**. Set the qube type to Named disposable_
+In Qubes 4.2: named disposables can be created by **Application Menu -> Settings -> Qubes Settings -> Create New Qube**. Set the qube type to **Named disposable**.
 
 ## Security
 

From cb1f45fe9716930eb8771cd0865d0d6c8891e305 Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Thu, 16 Jan 2025 17:02:58 -0500
Subject: [PATCH 247/332] removed new lines

---
 .../how-to-back-up-restore-and-migrate.md     | 20 +++----------------
 1 file changed, 3 insertions(+), 17 deletions(-)

diff --git a/user/how-to-guides/how-to-back-up-restore-and-migrate.md b/user/how-to-guides/how-to-back-up-restore-and-migrate.md
index 0cb0ef5a..1a5eab7f 100644
--- a/user/how-to-guides/how-to-back-up-restore-and-migrate.md
+++ b/user/how-to-guides/how-to-back-up-restore-and-migrate.md
@@ -197,23 +197,9 @@ the new machine. All of your settings and data will be preserved!
 
 Here are some things to consider when selecting a passphrase for your backups:
 
-- If you plan to store the backup for a long time or on third-party servers,
-  you should make sure to use a very long, high-entropy passphrase. (Depending
-  on the decryption passphrase you use for your system drive, this may
-  necessitate selecting a stronger passphrase. If your system drive decryption
-  passphrase is already sufficiently strong, it may not.)
-- An adversary who has access to your backups may try to substitute one backup
-  for another. For example, when you attempt to retrieve a recent backup, the
-  adversary may instead give you a very old backup containing a compromised VM.
-  If you're concerned about this type of attack, you may wish to use a
-  different passphrase for each backup, e.g., by appending a number or date to
-  the passphrase.
-- If you're forced to enter your system drive decryption passphrase in plain
-  view of others (where it can be shoulder-surfed), then you may want to use a
-  different passphrase for your backups (even if your system drive decryption
-  passphrase is already maximally strong). On the other hand, if you're careful
-  to avoid shoulder-surfing and/or have a passphrase that's difficult to detect
-  via shoulder-surfing, then this may not be a problem for you.
+- If you plan to store the backup for a long time or on third-party servers, you should make sure to use a very long, high-entropy passphrase. (Depending on the decryption passphrase you use for your system drive, this may necessitate selecting a stronger passphrase. If your system drive decryption passphrase is already sufficiently strong, it may not.)
+- An adversary who has access to your backups may try to substitute one backup for another. For example, when you attempt to retrieve a recent backup, the adversary may instead give you a very old backup containing a compromised VM. If you're concerned about this type of attack, you may wish to use a different passphrase for each backup, e.g., by appending a number or date to the passphrase.
+- If you're forced to enter your system drive decryption passphrase in plain view of others (where it can be shoulder-surfed), then you may want to use a different passphrase for your backups (even if your system drive decryption passphrase is already maximally strong). On the other hand, if you're careful to avoid shoulder-surfing and/or have a passphrase that's difficult to detect via shoulder-surfing, then this may not be a problem for you.
 
 ## Notes
 

From 8085719b1cee36c5191d371b16ed7d1bfeaf8c7f Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Sat, 18 Jan 2025 15:21:06 -0500
Subject: [PATCH 248/332] small formatting issues

---
 developer/services/qrexec.md              | 1 +
 user/advanced-topics/gui-configuration.md | 2 +-
 user/advanced-topics/rpc-policy.md        | 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/developer/services/qrexec.md b/developer/services/qrexec.md
index 4ee41d98..d95e952d 100644
--- a/developer/services/qrexec.md
+++ b/developer/services/qrexec.md
@@ -109,6 +109,7 @@ Note that if the request is redirected (`target=` parameter), policy action rema
 If no policy rule is matched, the action is denied.
 
 In the target VM, a file in either of the following locations must exist, containing the file name of the program that will be invoked, or being that program itself -- in which case it must have executable permission set (`chmod +x`):
+
   - `/etc/qubes-rpc/RPC_ACTION_NAME` when you make it in the template qube;
   - `/usr/local/etc/qubes-rpc/RPC_ACTION_NAME` for making it only in an app qube.
 
diff --git a/user/advanced-topics/gui-configuration.md b/user/advanced-topics/gui-configuration.md
index b622ac99..56a06227 100644
--- a/user/advanced-topics/gui-configuration.md
+++ b/user/advanced-topics/gui-configuration.md
@@ -21,7 +21,7 @@ qvm-features dom0 gui-videoram-min $(($WIDTH * $HEIGHT * 4 / 1024))
 qvm-features dom0 gui-videoram-overhead 0
 ```
 
-Where `$WIDTH`×`$HEIGHT` is the maximum desktop size that you anticipate needing.
+Where `$WIDTH` × `$HEIGHT` is the maximum desktop size that you anticipate needing.
 For example, if you expect to use a 1080p display and a 4k display side-by-side, that is `(1920 + 3840) × 2160 × 4 / 1024 = 48600`, or slightly more than 48 MiB per qube.
 After making these adjustments, the qubes need to be restarted.
 
diff --git a/user/advanced-topics/rpc-policy.md b/user/advanced-topics/rpc-policy.md
index 53cf01e4..bd2aa168 100644
--- a/user/advanced-topics/rpc-policy.md
+++ b/user/advanced-topics/rpc-policy.md
@@ -43,7 +43,7 @@ This is how we create a policy that says: "VMs tagged with 'work' are allowed to
 
 When an operation is initiated with a specific target, e.g. `qvm-copy-to-vm other_work_vm some_file` the policy mechanism looks for a row
 matching `source_work_vm other_work_vm PERMISSION`. In this case, assuming both VMs have the `work` tag, the second row would match, and
-the operation would be `allow`ed without any prompts. When an operation is initiated without a specific target, e.g. `qvm-copy some_file`,
+the operation would be `allow`-ed without any prompts. When an operation is initiated without a specific target, e.g. `qvm-copy some_file`,
 the policy mechanism looks for a row matching `source_work_vm @default PERMISSION`. In this case, the first row indicates that the user
 should be prompted for the destination. The list of destination VMs in the prompt is filtered to only include VMs that are valid as per
 the policy (so in this example, only other work VMs would be listed). If the first row was commented out, the second row would not match

From 47f23eda45a61ffcda186b580c9e18c741ab5f09 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sol=C3=A8ne=20Rapenne?= <solene@perso.pw>
Date: Tue, 21 Jan 2025 19:56:49 +0100
Subject: [PATCH 249/332] fix: broken anchor

---
 introduction/issue-tracking.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/introduction/issue-tracking.md b/introduction/issue-tracking.md
index 46c038fd..5326e698 100644
--- a/introduction/issue-tracking.md
+++ b/introduction/issue-tracking.md
@@ -41,7 +41,7 @@ Great! Thank you for taking the time and effort to help improve Qubes! To ensure
  1. Carefully read our issue tracking [guidelines](#guidelines). If your issue would violate any of the guidelines, **stop**. Please do not submit it.
  2. [Search through the existing issues](#search-tips), both open and closed, to see if your issue already exists. If it does, **stop**. [Do not open a duplicate.](/doc/issue-tracking/#new-issues-should-not-be-duplicates-of-existing-issues) Instead, comment on the existing issue.
  3. Go [here](https://github.com/QubesOS/qubes-issues/issues/new/choose).
- 4. Select the [type](#type) of issue you want to open.
+ 4. Select the [type](#types) of issue you want to open.
  5. Enter a descriptive title.
  6. Do not delete the provided issue template. Fill out every applicable section.
  7. Make sure to mention any relevant documentation and other issues you've already seen. We don't know what you've seen unless you tell us. If you don't list it, we'll assume you haven't seen it.

From f58574bca78af8c7a3ff338049e513b170be26ba Mon Sep 17 00:00:00 2001
From: Ali Mirjamali <ali@mirjamali.com>
Date: Sat, 31 Aug 2024 14:51:21 +0330
Subject: [PATCH 250/332] Add instructions on resuming partial downloads

Resolves: https://github.com/QubesOS/qubes-issues/issues/8563

Adding simple instructions on resuming downloads with for users
with unsteady Internet connections who are unfamiliar with wget.
---
 user/downloading-installing-upgrading/installation-guide.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/downloading-installing-upgrading/installation-guide.md b/user/downloading-installing-upgrading/installation-guide.md
index c38cbc35..a4684667 100644
--- a/user/downloading-installing-upgrading/installation-guide.md
+++ b/user/downloading-installing-upgrading/installation-guide.md
@@ -43,7 +43,7 @@ Even on supported hardware, you must ensure that [IOMMU-based virtualization](ht
 
 ### Copying the ISO onto the installation medium
 
-Pick the most secure existing computer and OS you have available for downloading and copying the Qubes ISO onto the installation medium. [Download](/downloads/) a Qubes ISO.
+Pick the most secure existing computer and OS you have available for downloading and copying the Qubes ISO onto the installation medium. [Download](/downloads/) a Qubes ISO. If your Internet connection is unstable and the download is interrupted, you could resume the partial download with `wget --continue` in case you are currently using wget for downloading or use a download-manager with resume capability. Alternatively you can download installation ISO via BitTorrent that sometimes enables higher download speeds and more reliable downloads of large files.
 
 <div class="alert alert-danger" role="alert">
   <i class="fa fa-exclamation-triangle"></i>

From 2d3bfcb39f4a553b4baf49d7c0c71544a76c3189 Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Wed, 22 Jan 2025 13:29:16 -0500
Subject: [PATCH 251/332] small formatting fixes in markdown

---
 developer/services/dom0-secure-updates.md   | 2 +-
 user/security-in-qubes/firewall.md          | 2 +-
 user/templates/fedora/fedora-upgrade.md     | 6 +-----
 user/troubleshooting/gui-troubleshooting.md | 4 +---
 user/troubleshooting/hvm-troubleshooting.md | 2 +-
 5 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/developer/services/dom0-secure-updates.md b/developer/services/dom0-secure-updates.md
index ad922a88..2a5b7d52 100644
--- a/developer/services/dom0-secure-updates.md
+++ b/developer/services/dom0-secure-updates.md
@@ -33,7 +33,7 @@ Keeping Dom0 not connected to any network makes it hard, however, to provide upd
 
 The update process is initiated by [qubes-dom0-update script](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-dom0-update), running in Dom0.
 
-Updates (`*.rpm` files) are checked and downloaded by UpdateVM, which by default is the same as the firewall VM, but can be configured to be any other, network-connected VM. This is done by [qubes-download-dom0-updates.sh script](https://github.com/QubesOS/qubes-core-agent-linux/blob/release2/misc/qubes-download-dom0-updates.sh) (this script is executed using qrexec by the previously mentioned qubes-dom0-update). Note that we assume that this script might get compromised and fetch maliciously compromised downloads -- this is not a problem as Dom0 verifies digital signatures on updates later. The downloaded rpm files are placed in a ~~~/var/lib/qubes/dom0-updates~~~ directory on UpdateVM filesystem (again, they might get compromised while being kept there, still this isn't a problem). This directory is passed to yum using the ~~~--installroot=~~~ option.
+Updates (`*.rpm` files) are checked and downloaded by UpdateVM, which by default is the same as the firewall VM, but can be configured to be any other, network-connected VM. This is done by [qubes-download-dom0-updates.sh script](https://github.com/QubesOS/qubes-core-agent-linux/blob/release2/misc/qubes-download-dom0-updates.sh) (this script is executed using qrexec by the previously mentioned qubes-dom0-update). Note that we assume that this script might get compromised and fetch maliciously compromised downloads -- this is not a problem as Dom0 verifies digital signatures on updates later. The downloaded rpm files are placed in a `/var/lib/qubes/dom0-updates` directory on UpdateVM filesystem (again, they might get compromised while being kept there, still this isn't a problem). This directory is passed to yum using the `--installroot=` option.
 
 Once updates are downloaded, the update script that runs in UpdateVM requests an RPM service [qubes.ReceiveUpdates](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes.ReceiveUpdates) to be executed in Dom0. This service is implemented by [qubes-receive-updates script](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-receive-updates) running in Dom0. The Dom0's qubes-dom0-update script (which originally initiated the whole update process) waits until qubes-receive-updates finished.
 
diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index 558a34aa..9c915752 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -14,7 +14,7 @@ title: Firewall
 Introduction
 ----------------------------------
 This page explains use of the firewall in Qubes 4.2, using `nftables`.  
-In Qubes 4.1, all firewall components used `iptables`. For details of that usage see [here](../firewall_4.1/)
+In Qubes 4.1, all firewall components used `iptables`. For details of that usage see [here](../firewall_4.1/).
 
 
 Understanding firewalling in Qubes
diff --git a/user/templates/fedora/fedora-upgrade.md b/user/templates/fedora/fedora-upgrade.md
index 2d5dad90..b4096367 100644
--- a/user/templates/fedora/fedora-upgrade.md
+++ b/user/templates/fedora/fedora-upgrade.md
@@ -121,11 +121,7 @@ The same general procedure may be used to upgrade any template based on the stan
 
        If this attempt is successful, proceed to step 4.
 
-     * `dnf` may complain:
-
-        `
-        At least X MB more space needed on the / filesystem.
-        `
+     * `dnf` may complain: `At least X MB more space needed on the / filesystem.`
 
        In this case, one option is to [resize the template's disk image](/doc/resize-disk-image/) before reattempting the upgrade process.
        (See [Additional Information](#additional-information) below for other options.)
diff --git a/user/troubleshooting/gui-troubleshooting.md b/user/troubleshooting/gui-troubleshooting.md
index a2761396..d08d482f 100644
--- a/user/troubleshooting/gui-troubleshooting.md
+++ b/user/troubleshooting/gui-troubleshooting.md
@@ -26,9 +26,7 @@ Similarly, while working, the XScreenSaver dialog may pop up (indicating the scr
 
 If you are experiencing the any of the above symptoms, try disabling the window compositor:
 
-`
-    Q → System Tools → Window Manager Tweaks → Compositor → uncheck “Enable display compositing”
-`
+`Q → System Tools → Window Manager Tweaks → Compositor → uncheck “Enable display compositing”`
 
 ## Post installation, screen goes black and freezes following LUKS decryption
 
diff --git a/user/troubleshooting/hvm-troubleshooting.md b/user/troubleshooting/hvm-troubleshooting.md
index 98f87a9e..070c37ec 100644
--- a/user/troubleshooting/hvm-troubleshooting.md
+++ b/user/troubleshooting/hvm-troubleshooting.md
@@ -62,7 +62,7 @@ qvm-prefs <HVMname> kernel ""
 
 ## HVM crashes when booting from ISO
 
-If your HVM crashes when trying to boot an ISO, first ensure that ` qvm-prefs <HVMname> kernel` is empty, as shown above.
+If your HVM crashes when trying to boot an ISO, first ensure that `qvm-prefs <HVMname> kernel` is empty, as shown above.
 If this doesn't help, then disable memory balancing and set the minimum memory to 2GB.
 
 You can disable memory-balancing in the settings, under the “Advanced” tab.

From b9067f7b80a68d32d15b75f10dd1ab9103abafe0 Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Wed, 22 Jan 2025 18:15:27 -0500
Subject: [PATCH 252/332] hyperlink fix in markdown

---
 developer/general/developing-gui-applications.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/developer/general/developing-gui-applications.md b/developer/general/developing-gui-applications.md
index 1ff0387c..19e60a1c 100644
--- a/developer/general/developing-gui-applications.md
+++ b/developer/general/developing-gui-applications.md
@@ -59,7 +59,7 @@ If error should be thrown, you need to provide the error code and name, for exam
       b'2\x00QubesNoSuchPropertyError\x00\x00No such property\x00'
 ```
 
-For details of particular calls, you can use [Extending the mock Qubes object].
+For details of particular calls, you can use [Extending the mock Qubes object](#extending-the-mock-qubes-object).
 
 
 ## Available mocks

From 00785492ad9e965c08d4f06c1405463ce1b2e805 Mon Sep 17 00:00:00 2001
From: Demi Marie Obenour <demi@invisiblethingslab.com>
Date: Sun, 21 Jul 2024 13:47:56 -0400
Subject: [PATCH 253/332] Document /run/qubes/policy.d/

Useful for users of the feature.
---
 developer/services/qrexec.md | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/developer/services/qrexec.md b/developer/services/qrexec.md
index fbdc7327..edee53b1 100644
--- a/developer/services/qrexec.md
+++ b/developer/services/qrexec.md
@@ -86,11 +86,12 @@ Disposable VMs are tightly integrated -- RPC to a DisposableVM is identical to R
 
 ### Policy files
 
-The dom0 directory `/etc/qubes/policy.d/` contains files that set policy for each available RPC action that a VM might call.
+The dom0 directories `/etc/qubes/policy.d/` and `/run/qubes/policy.d/` contain files that set policy for each available RPC action that a VM might call.
 For example, `/etc/qubes/policy.d/90-default.policy` contains the default policy settings.  
 When making changes to existing policies it is recommended that you create a *new* policy file starting with a lower number, like `/etc/qubes/policy.d/30-user.policy`.  
 You may keep your custom policies in one file like `/etc/qubes/policy.d/30-user.policy`, or you may choose to have multiple files, like `/etc/qubes/policy.d/10-copy.policy`, `/etc/qubes/policy.d/10-open.policy`.  
 Together the contents of these files make up the RPC access policy database: the files are merged, with policies in lower number files overriding policies in higher numbered files.
+If there are entries in both `/run/qubes/policy.d/` and `/etc/qubes/policy.d/` with the same name, it isn't specified which takes precedence, so you should avoid this situation.
 
 Policies are defined in lines with the following format:
 
@@ -103,7 +104,7 @@ You can specify the source and destination by name or by one of the reserved key
 Service calls from dom0 are currently always allowed, and `@dispvm` means "new VM created for this particular request," so it is never a source of request.)
 Other methods using *tags* and *types* are also available (and discussed below).
 
-Whenever a RPC request for an action is received, the domain checks the first matching line of the files in `/etc/qubes/policy.d/` to determine access:
+Whenever a RPC request for an action is received, the domain checks the first matching line of the files in `/etc/qubes/policy.d/` and `/run/qubes/policy.d/` to determine access:
 whether to allow the request, what VM to redirect the execution to, and what user account the program should run under.
 Note that if the request is redirected (`target=` parameter), policy action remains the same -- even if there is another rule which would otherwise deny such request.
 If no policy rule is matched, the action is denied.
@@ -112,6 +113,10 @@ In the target VM, a file in either of the following locations must exist, contai
   - `/etc/qubes-rpc/RPC_ACTION_NAME` when you make it in the template qube;
   - `/usr/local/etc/qubes-rpc/RPC_ACTION_NAME` for making it only in an app qube.
 
+Files in `/run/qubes/policy.d/` are deleted when the system is rebooted.
+This is useful for temporary policy that contains the name or UUID of a disposable VM, which will not be meaningful after the system has rebooted.
+Such policy files can be created manually, but they are usually created automatically by a Qrexec call to dom0.
+
 ### Making an RPC call
 
 From outside of dom0, RPC calls take the following form:

From bef2385ba1ec6f5b9fd3a83299215d713cc25535 Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Thu, 23 Jan 2025 17:04:26 -0500
Subject: [PATCH 254/332] icon properly displayed, formatting

---
 user/how-to-guides/how-to-use-pci-devices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/how-to-guides/how-to-use-pci-devices.md b/user/how-to-guides/how-to-use-pci-devices.md
index be70e005..9552cfc6 100644
--- a/user/how-to-guides/how-to-use-pci-devices.md
+++ b/user/how-to-guides/how-to-use-pci-devices.md
@@ -45,7 +45,7 @@ There you can attach PCI-devices to a qube.
 
 1. To reach the settings of any qube either
 
-   - Press Alt+F3 to open the application finder, type in the VM name, select the "![appmenu](/attachment/doc/qubes-appmenu-select.png)\[VM-name\]: Qube Settings" menu entry and press enter or click "Launch"!
+   - Press Alt+F3 to open the application finder, type in the VM name, select the ![appmenu](/attachment/doc/qubes-appmenu-select.png) `[VM-name]: Qube Settings` menu entry and press enter or click `Launch`!
    - Select the VM in Qube Manager and click the settings-button or right-click the VM and select `Qube settings`.
    - Click the Domain Manager, hover the VM you want to attach a device to and select "settings" in the additional menu. (only running VMs!)
 

From db7938992d554ce633cd15cfd8144b232430f657 Mon Sep 17 00:00:00 2001
From: deeplow <47065258+deeplow@users.noreply.github.com>
Date: Mon, 27 Jan 2025 13:49:56 +0000
Subject: [PATCH 255/332] qrexec: add info about QREXEC_REMOTE_DOMAIN

Add information about `QREXEC_REMOTE_DOMAIN` which is still on the qrexec2.md file but not on the V3. However, this still applies, so it should be documented.
---
 developer/services/qrexec.md | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/developer/services/qrexec.md b/developer/services/qrexec.md
index edee53b1..ded9fa97 100644
--- a/developer/services/qrexec.md
+++ b/developer/services/qrexec.md
@@ -109,10 +109,6 @@ whether to allow the request, what VM to redirect the execution to, and what use
 Note that if the request is redirected (`target=` parameter), policy action remains the same -- even if there is another rule which would otherwise deny such request.
 If no policy rule is matched, the action is denied.
 
-In the target VM, a file in either of the following locations must exist, containing the file name of the program that will be invoked, or being that program itself -- in which case it must have executable permission set (`chmod +x`):
-  - `/etc/qubes-rpc/RPC_ACTION_NAME` when you make it in the template qube;
-  - `/usr/local/etc/qubes-rpc/RPC_ACTION_NAME` for making it only in an app qube.
-
 Files in `/run/qubes/policy.d/` are deleted when the system is rebooted.
 This is useful for temporary policy that contains the name or UUID of a disposable VM, which will not be meaningful after the system has rebooted.
 Such policy files can be created manually, but they are usually created automatically by a Qrexec call to dom0.
@@ -140,6 +136,17 @@ It is also possible to call service without specific client program -- in which
 $ qrexec-client-vm target_vm_name RPC_ACTION_NAME
 ```
 
+### Answering an RPC call
+
+In other for a RPC call to be answered in the target VM, a file in either of the following locations must exist, containing the file name of the program that will be invoked, or being that program itself -- in which case it must have executable permission set (`chmod +x`):
+  - `/etc/qubes-rpc/RPC_ACTION_NAME` when you make it in the template qube;
+  - `/usr/local/etc/qubes-rpc/RPC_ACTION_NAME` for making it only in an app qube.
+
+The source VM name can then be accessed in the server process via
+`QREXEC_REMOTE_DOMAIN` environment variable. (Note the source VM has *no*
+control over the name provided in this variable--the name of the VM is
+provided by dom0, and so is trusted.)
+
 ### Specifying VMs: tags, types, targets, etc.
 
 There are severals methods for specifying source/target VMs in RPC policies.

From f3d5fb45d8edceb5c40897dbe144e0bda3b33f88 Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Sun, 9 Feb 2025 14:05:59 -0500
Subject: [PATCH 256/332] add new line for correct conversion of code block
 from md to rst

---
 user/templates/windows/windows-qubes-4-1.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/user/templates/windows/windows-qubes-4-1.md b/user/templates/windows/windows-qubes-4-1.md
index bfd3a10f..09f13e5e 100644
--- a/user/templates/windows/windows-qubes-4-1.md
+++ b/user/templates/windows/windows-qubes-4-1.md
@@ -113,6 +113,7 @@ These parameters are set for the following reasons:
 - Setting memory to 4096MB may work in most cases, but using 6144MB (or even 8192MB) may reduce the likelihood of crashes during installation, especially for Windows 10 or 11. This is important as Windows qubes have to be created without memory balancing, as requested by the parameter settings described above.
 
 - The Windows' installer requires a significant amount of memory or else the VM will crash with such errors:
+
     ~~~
     /var/log/xen/console/hypervisor.log:
 

From 8fb701ea798adf8f5ec59b0c1c0a3d1f8cbfb04b Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Sun, 9 Feb 2025 17:23:15 -0500
Subject: [PATCH 257/332] add new line for correct conversion from md to rst

---
 user/advanced-topics/config-files.md | 3 +--
 user/hardware/system-requirements.md | 2 +-
 user/security-in-qubes/vm-sudo.md    | 2 ++
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/user/advanced-topics/config-files.md b/user/advanced-topics/config-files.md
index 37ee7c03..01faaeae 100644
--- a/user/advanced-topics/config-files.md
+++ b/user/advanced-topics/config-files.md
@@ -113,8 +113,7 @@ VM: {
 Currently supported settings:
 
 - `allow_fullscreen` - allow VM to request its windows to go fullscreen (without any colorful frame).
-
-    **Note:** Regardless of this setting, you can always put a window into fullscreen mode in Xfce4 using the trusted window manager by right-clicking on a window's title bar and selecting "Fullscreen".
+    - **Note:** Regardless of this setting, you can always put a window into fullscreen mode in Xfce4 using the trusted window manager by right-clicking on a window's title bar and selecting "Fullscreen".
     This functionality should still be considered safe, since a VM window still can't voluntarily enter fullscreen mode.
     The user must select this option from the trusted window manager in dom0.
     To exit fullscreen mode from here, press `alt` + `space` to bring up the title bar menu again, then select "Leave Fullscreen".
diff --git a/user/hardware/system-requirements.md b/user/hardware/system-requirements.md
index 552da7a0..b0b4a978 100644
--- a/user/hardware/system-requirements.md
+++ b/user/hardware/system-requirements.md
@@ -98,7 +98,7 @@ We recommend consulting these resources when selecting hardware for Qubes OS:
   offer significant security advantages over conventional operating systems on
   the same hardware.
 
-  Intel maintains a
+  - Intel maintains a
   [list](https://www.intel.com/content/www/us/en/support/articles/000022396/processors.html)
   of end-of-support dates for its processors. However, this list seems to
   include only processors that are no longer supported or will soon no longer
diff --git a/user/security-in-qubes/vm-sudo.md b/user/security-in-qubes/vm-sudo.md
index 3001c367..103644e8 100644
--- a/user/security-in-qubes/vm-sudo.md
+++ b/user/security-in-qubes/vm-sudo.md
@@ -59,9 +59,11 @@ user ALL=(ALL) NOPASSWD: ALL
 #
 # joanna.
 ```
+
 The core of this statement continues to reflect the views of the Qubes developers.
 
 Passwordless root is provided by the `qubes-core-agent-passwordless-root` package.  
+
 Details of the implementation are [here](/doc/vm-sudo-implementation).
 
 [Minimal templates](/doc/templates/minimal/), which are intended for use by advanced users, do not have this package installed by default.

From d6925e063d7e6259e6b6d9afd3eb77f78a90284e Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Fri, 14 Feb 2025 17:51:17 -0500
Subject: [PATCH 258/332] QA rst conversion releases section: replace master
 with main in 1 file, archive link from a currently dead one, typo fix

---
 developer/releases/2_0/release-notes.md | 2 +-
 developer/releases/4_0/release-notes.md | 2 +-
 developer/releases/version-scheme.md    | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/developer/releases/2_0/release-notes.md b/developer/releases/2_0/release-notes.md
index e0a5751d..a428a121 100644
--- a/developer/releases/2_0/release-notes.md
+++ b/developer/releases/2_0/release-notes.md
@@ -68,7 +68,7 @@ Note: if the user has custom Template VMs (i.e. other than the default template,
 
 #### From Qubes R1 to R2 beta1
 
-If you're already running Qubes Release 1, you don't need to reinstall, it's just enough to update the packages in your Dom0 and the template VM(s). This procedure is described [here?](/doc/upgrade-to-r2/).
+If you're already running Qubes Release 1, you don't need to reinstall, it's just enough to update the packages in your Dom0 and the template VM(s). This procedure is described [here](/doc/upgrade-to-r2/).
 
 #### From Qubes R1 or R2 Beta 1 to R2 beta2
 
diff --git a/developer/releases/4_0/release-notes.md b/developer/releases/4_0/release-notes.md
index b80a1959..f58eb0b9 100644
--- a/developer/releases/4_0/release-notes.md
+++ b/developer/releases/4_0/release-notes.md
@@ -9,7 +9,7 @@ title: Qubes R4.0 release notes
 New features since 3.2
 ----------------------
 
-* Core management scripts rewrite with better structure and extensibility, [API documentation](https://dev.qubes-os.org/projects/qubes-core-admin/en/latest/)
+* Core management scripts rewrite with better structure and extensibility, [API documentation](https://web.archive.org/web/20230128102821/https://dev.qubes-os.org/projects/qubes-core-admin/en/latest/)
 * [Admin API](/news/2017/06/27/qubes-admin-api/) allowing strictly controlled managing from non-dom0
 * All `qvm-*` command-line tools rewritten, some options have changed
 * Renaming VM directly is prohibited, there is GUI to clone under new name and remove old VM
diff --git a/developer/releases/version-scheme.md b/developer/releases/version-scheme.md
index a96f9ca6..f241a70a 100644
--- a/developer/releases/version-scheme.md
+++ b/developer/releases/version-scheme.md
@@ -71,7 +71,7 @@ When enough progress has been made, we announce the first stable release, e.g.
 `3.0.0`. This is not only a version but an actual release. It is considered
 stable, and we commit to supporting it according to our [support
 schedule](/doc/supported-releases/). Core components are branched at this
-moment, and bug fixes are backported from the master branch. Please see [help,
+moment, and bug fixes are backported from the main branch. Please see [help,
 support, mailing lists, and forum](/support/) for places to ask questions about
 stable releases. No major features or interface incompatibilities are to be
 included in this release. We release bug fixes as patch releases (`3.0.1`,
@@ -173,7 +173,7 @@ We mark each component version in the repository by tag containing
 
 At the release of some release we create branches named like `release2`. Only
 bug fixes and compatible improvements are backported to these branches. These
-branches should compile. All new development is done in `master` branch. This
+branches should compile. All new development is done in `main` branch. This
 branch is totally unsupported and may not even compile depending on maintainer
 of repository.
 

From f62ae0b14bf8b14597a8941036067573bb80ed6a Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Sat, 15 Feb 2025 20:55:00 -0500
Subject: [PATCH 259/332] added mailing list clarification

---
 developer/building/development-workflow.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/developer/building/development-workflow.md b/developer/building/development-workflow.md
index dd72699a..10199e50 100644
--- a/developer/building/development-workflow.md
+++ b/developer/building/development-workflow.md
@@ -39,7 +39,8 @@ on github.
 
 When you are ready to submit your changes to Qubes to be merged, push your
 changes, then create a signed git tag (using `git tag -s`). Finally, send a
-letter to the Qubes listserv describing the changes and including the link to
+letter to the Qubes the [qubes-devel](/support/#qubes-devel) mailing list
+describing the changes and including the link to
 your repository. You can also create pull request on github. Don't forget to
 include your public PGP key you use to sign your tags.
 

From aa1c72268737e6599b410e8eebeb78b2eedf8c4f Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Wed, 19 Feb 2025 05:09:27 -0800
Subject: [PATCH 260/332] Remove Facebook from social media list (no longer
 being updated)

---
 introduction/support.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/introduction/support.md b/introduction/support.md
index b12bb55f..e7e9d71a 100644
--- a/introduction/support.md
+++ b/introduction/support.md
@@ -502,7 +502,6 @@ The Qubes OS Project has a presence on the following social media platforms:
 - <a rel="me" href="https://twitter.com/QubesOS">Twitter</a>
 - <a rel="me" href="https://mastodon.social/@QubesOS">Mastodon</a>
 - <a rel="me" href="https://www.reddit.com/r/Qubes/">Reddit</a>
-- <a rel="me" href="https://www.facebook.com/QubesOS/">Facebook</a>
 - <a rel="me" href="https://www.linkedin.com/company/qubes-os/">LinkedIn</a>
 
 Generally speaking, these are not intended to be primary support venues. (Those

From 832bcf8855b50c5906e9132ec9312dd1c23ada68 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Wed, 19 Feb 2025 05:35:26 -0800
Subject: [PATCH 261/332] Add NovaCustom V54 Series

---
 user/hardware/certified-hardware.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/user/hardware/certified-hardware.md b/user/hardware/certified-hardware.md
index 41b825fe..31a53e7e 100644
--- a/user/hardware/certified-hardware.md
+++ b/user/hardware/certified-hardware.md
@@ -25,6 +25,12 @@ Qubes-certified computers are certified for a [major release](/doc/version-schem
 
 The current Qubes-certified models are listed below in reverse chronological order of certification.
 
+### NovaCustom V54 Series 14.0 inch coreboot laptop
+
+[![Photo of the NovaCustom V54 Series 14.0 inch coreboot laptop](/attachment/site/novacustom-v54-series.png)](https://novacustom.com/product/v54-series/)
+
+The [NovaCustom V54 Series 14.0 inch coreboot laptop](https://novacustom.com/product/v54-series/) is certified for Qubes OS Release 4.
+
 ### NitroPad V56
 
 [![Photo of the NitroPad V56](/attachment/site/nitropad-v56.png)](https://shop.nitrokey.com/shop/nitropad-v56-684)

From cab3bec6a7dd1084143e3b20c314dbc82ff448be Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Wed, 19 Feb 2025 06:15:58 -0800
Subject: [PATCH 262/332] Add step for pushing qubes-release to current

QubesOS/qubes-issues#9783
---
 developer/releases/todo.md | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/developer/releases/todo.md b/developer/releases/todo.md
index 23d370ed..bcac1b17 100644
--- a/developer/releases/todo.md
+++ b/developer/releases/todo.md
@@ -37,6 +37,7 @@ On final release
 * finish release notes
 * update InstallationInstructions
 * build ISO and push to mirrors
+* push `qubes-release` package to `current`
 * notify @Rudd-O about the new ISO for new torrent hosting
-* write blog post
-* announce on Twitter
+* write news post
+* announce

From 90235722693d30e4b3f31606aa7b7e76bb3e9248 Mon Sep 17 00:00:00 2001
From: jermanuts <109705802+jermanuts@users.noreply.github.com>
Date: Wed, 19 Feb 2025 18:47:19 +0200
Subject: [PATCH 263/332] Update rufus link

---
 user/downloading-installing-upgrading/installation-guide.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/downloading-installing-upgrading/installation-guide.md b/user/downloading-installing-upgrading/installation-guide.md
index a4684667..3377f744 100644
--- a/user/downloading-installing-upgrading/installation-guide.md
+++ b/user/downloading-installing-upgrading/installation-guide.md
@@ -74,7 +74,7 @@ Change `Qubes-RX-x86_64.iso` to the filename of the version you're installing, a
 
 #### Windows ISO to USB
 
-On Windows, you can use the [Rufus](https://rufus.akeo.ie/) tool to write the ISO to a USB key. Be sure to select "Write in DD Image mode" *after* selecting the Qubes ISO and pressing "START" on the Rufus main window.
+On Windows, you can use the [Rufus](https://rufus.ie/) tool to write the ISO to a USB key. Be sure to select "Write in DD Image mode" *after* selecting the Qubes ISO and pressing "START" on the Rufus main window.
 
 <div class="alert alert-info" role="alert">
   <i class="fa fa-info-circle"></i>

From cc13bd9ee82c128c132663709c48824305accc0a Mon Sep 17 00:00:00 2001
From: Demi Marie Obenour <demi@invisiblethingslab.com>
Date: Thu, 3 Oct 2024 17:16:07 -0400
Subject: [PATCH 264/332] Provide evidence that AMD is slow to ship client
 microcode

The claims in the documentation are corrrect, but no sources were
provided.  Add links to sources.

Fixes: QubesOS/qubes-issues#9485
---
 user/hardware/system-requirements.md | 24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/user/hardware/system-requirements.md b/user/hardware/system-requirements.md
index ffe39f7c..bd279ed7 100644
--- a/user/hardware/system-requirements.md
+++ b/user/hardware/system-requirements.md
@@ -114,16 +114,16 @@ We recommend consulting these resources when selecting hardware for Qubes OS:
   other security updates directly to users. By contrast, on AMD client (as
   opposed to server) platforms, microcode updates are typically shipped only as
   part of system firmware and generally cannot be loaded from the operating
-  system. This means that AMD users typically must wait for:
-  
+  system [^1]. This means that AMD users typically must wait for:
+
   1. AMD to distribute microcode updates to original equipment manufacturers
   (OEMs), original design manufacturers (ODMs), and motherboard manufacturers
   (MB); and
   2. The user's OEM, ODM, or MB to provide a suitable BIOS or (U)EFI update for
   the user's system.
-  
+
   Historically, AMD has often been slow to complete step (1), at least for its
-  client (as opposed to server) platforms. In some cases, AMD has made fixes
+  client (as opposed to server) platforms [^2]. In some cases, AMD has made fixes
   available for its server platforms very shortly after a security embargo was
   lifted, but it did not make fixes available for client platforms facing the
   same vulnerability until weeks or months later. (A "security embargo" is the
@@ -134,7 +134,7 @@ We recommend consulting these resources when selecting hardware for Qubes OS:
 
   Step (2) varies by vendor. Many vendors fail to complete step (2) at all,
   while some others take a very long time to complete it.
-  
+
   The bottom line is that Qubes OS **can** run on AMD systems, and the Qubes and
   Xen security teams do their best to provide security support for AMD systems.
   However, without the ability to ship microcode updates, there is only so much
@@ -163,3 +163,17 @@ We recommend consulting these resources when selecting hardware for Qubes OS:
 
 - You can check whether an Intel processor has VT-x and VT-d on
   [ark.intel.com](https://ark.intel.com/content/www/us/en/ark.html#@Processors).
+
+[^1]: There is an `amd-ucode-firmware` package, but it only contains
+      microcode for servers and outdated microcode for Chromebooks.  Also,
+      the [AMD security website](https://www.amd.com/en/resources/product-security.html)
+      only lists microcode as a mitigation for data center CPUs.
+
+[^2]: As shown on [the AMD page for Speculative Return Stack Overflow](https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7005.html),
+      updated AGESA™ firmware for AMD Ryzen™ Threadripper™ 5000WX Processors
+      was not available until 2024-01-11, even though the vulnerability became
+      public on 2023-08-08.  AMD did not provide updated firmware for other client
+      processors until a date between 2023-08-22 to 2023-08-25.
+
+      For Zenbleed, firmware was not available until 2024 for most client parts,
+      even though server parts got microcode on 2023-06-06.

From 2f094ef07dce13bf4d071178aae7ded12faf79aa Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Fri, 21 Feb 2025 04:40:39 -0500
Subject: [PATCH 265/332] url fixes, md link fix for rst translation

---
 developer/general/gsod.md                   | 4 ++--
 developer/system/gui.md                     | 2 +-
 developer/system/template-implementation.md | 2 +-
 developer/system/template-manager.md        | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/developer/general/gsod.md b/developer/general/gsod.md
index 0ca6b7af..ad714e50 100644
--- a/developer/general/gsod.md
+++ b/developer/general/gsod.md
@@ -58,9 +58,9 @@ Qubes OS regularly participates in Google Summer of Code and Google Season of Do
 
 ## Past Projects
 
-You can view the project we had in 2019 in the [2019 GSoD archive](https://developers.google.com/season-of-docs/docs/2019/participants/project-qubes) and the [2019 writer's report](https://refre.ch/report-qubesos/).
+You can view the project we had in 2019 in the [2019 GSoD archive](https://developers.google.com/season-of-docs/docs/2019/participants/project-qubes) and the [2019 writer's report](https://web.archive.org/web/20200928002746/https://refre.ch/report-qubesos/).
 
-You can view the project we had in 2020 in the [2020 GSoD archive](https://developers.google.com/season-of-docs/docs/2020/participants/project-qubesos-c1e0) and the [2020 writer's report](https://gist.github.com/PROTechThor/bfe9b8b28295d88c438b6f6c754ae733).
+You can view the project we had in 2020 in the [2020 GSoD archive](https://developers.google.com/season-of-docs/docs/2020/participants/project-qubesos-c1e0) and the [2020 writer's report](https://web.archive.org/web/20210723170547/https://gist.github.com/PROTechThor/bfe9b8b28295d88c438b6f6c754ae733).
 
 You can view the results of the project we had in 2023 [here](https://www.youtube.com/playlist?list=PLjwSYc73nX6aHcpqub-6lzJbL0vhLleTB).
 
diff --git a/developer/system/gui.md b/developer/system/gui.md
index 27dab9ec..3eecccf5 100644
--- a/developer/system/gui.md
+++ b/developer/system/gui.md
@@ -119,7 +119,7 @@ AppVM -> GuiVM messages
 Proper handling of the below messages is security-critical.
 Note that all messages except for `CLIPBOARD`, `MFNDUMP`, and `WINDOW_DUMP` have fixed size, so the parsing code can be small.
 
-The `override_redirect` window attribute is explained at [Override Redirect Flag](https://tronche.com/gui/x/xlib/window/attributes/override-redirect.html). The `transient_for` attribute is explained at [`transient_for` attribute](https://tronche.com/gui/x/icccm/sec-4.html#WM_TRANSIENT_FOR).
+The `override_redirect` window attribute is explained at [Override Redirect Flag](https://tronche.com/gui/x/xlib/window/attributes/override-redirect.html). The `transient_for` attribute is explained at `transient_for` [attribute](https://tronche.com/gui/x/icccm/sec-4.html#WM_TRANSIENT_FOR).
 
 Window manager hints and flags are described in the [Extended Window Manager Hints (EWMH) spec](https://standards.freedesktop.org/wm-spec/latest/), especially under the `_NET_WM_STATE` section.
 
diff --git a/developer/system/template-implementation.md b/developer/system/template-implementation.md
index 59b5c453..6f08977a 100644
--- a/developer/system/template-implementation.md
+++ b/developer/system/template-implementation.md
@@ -27,7 +27,7 @@ This is mounted as /rw and here is placed all VM private data. This includes:
 - */usr/local* – which is symlink to /rw/usrlocal
 - some config files (/rw/config) called by qubes core scripts (ex /rw/config/rc.local)
 
-**Note:** Whenever a TemplateBasedVM is created, the contents of the `/home` directory of its parent TemplateVM [are *not* copied to the child TemplateBasedVM's](/doc/templates/#inheritance-and-persistence) `/home`. The child TemplateBasedVM's `/home` is independent from its parent TemplateVM's `/home`, which means that any changes to the parent TemplateVM's `/home` will not affect the child TemplateBasedVM's `/home`. Once a TemplateBasedVM has been created, any changes in its `/home`, `/usr/local`, or `/rw/config` directories will be persistent across reboots, which means that any files stored there will still be available after restarting the TemplateBasedVM. No changes in any other directories in TemplateBasedVMs persist in this manner. If you would like to make changes in other directories which *do* persist in this manner, you must make those changes in the parent TemplateVM.
+**Note:** Whenever a TemplateBasedVM is created, the contents of the `/home` directory of its parent TemplateVM are *not* copied to the [child TemplateBasedVM's](/doc/templates/#inheritance-and-persistence) `/home`. The child TemplateBasedVM's `/home` is independent from its parent TemplateVM's `/home`, which means that any changes to the parent TemplateVM's `/home` will not affect the child TemplateBasedVM's `/home`. Once a TemplateBasedVM has been created, any changes in its `/home`, `/usr/local`, or `/rw/config` directories will be persistent across reboots, which means that any files stored there will still be available after restarting the TemplateBasedVM. No changes in any other directories in TemplateBasedVMs persist in this manner. If you would like to make changes in other directories which *do* persist in this manner, you must make those changes in the parent TemplateVM.
 
 ### modules.img (xvdd)
 
diff --git a/developer/system/template-manager.md b/developer/system/template-manager.md
index 82d57d53..6a3912e2 100644
--- a/developer/system/template-manager.md
+++ b/developer/system/template-manager.md
@@ -23,7 +23,7 @@ specifically override the changes.) Other operations that work well on normal
 VMs are also somewhat inconsistent on RPM-managed templates. This includes
 actions such as renaming
 ([#839](https://github.com/QubesOS/qubes-issues/issues/839)), removal
-([#5509](https://github.com/QubesOS/qubes-issues/issues/5509)) and
+([#5509](https://web.archive.org/web/20210526123932/https://github.com/QubesOS/qubes-issues/issues/5509)) and
 backup/restore ([#1385](https://github.com/QubesOS/qubes-issues/issues/1385),
 [#1453](https://github.com/QubesOS/qubes-issues/issues/1453), [discussion
 thread

From d4461fb4cbbd0bf9345aadc0a240c0256141753e Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Thu, 27 Feb 2025 16:10:31 -0500
Subject: [PATCH 266/332] formatting, webarchive links, add icons

---
 developer/services/qfilecopy.md             |  2 +-
 developer/services/qmemman.md               | 12 +++++++++---
 user/advanced-topics/bind-dirs.md           |  2 +-
 user/advanced-topics/gui-configuration.md   |  4 ++--
 user/advanced-topics/mount-from-other-os.md |  2 +-
 user/reference/glossary.md                  |  2 +-
 6 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/developer/services/qfilecopy.md b/developer/services/qfilecopy.md
index 2f3fc0a6..dea4ef51 100644
--- a/developer/services/qfilecopy.md
+++ b/developer/services/qfilecopy.md
@@ -24,6 +24,6 @@ This has the following disadvantages:
 
 In modern Qubes OS releases, we have reimplemented interVM file copy using qrexec, which addresses the above mentioned disadvantages. Nowadays, even more generic solution (qubes rpc) is used. See the developer docs on qrexec and qubes rpc. In a nutshell, the file sender and the file receiver just read/write from stdin/stdout, and the qubes rpc layer passes data properly - so, no block devices are used.
 
-The rpc action for regular file copy is *qubes.Filecopy*, the rpc client is named *qfile-agent*, the rpc server is named *qfile-unpacker*. For DispVM copy, the rpc action is *qubes.OpenInVM*, the rpc client is named *qopen-in-vm*, rpc server is named *vm-file-editor*. Note that the qubes.OpenInVM action can be done on a normal AppVM, too.
+The rpc action for regular file copy is *qubes.Filecopy*, the rpc client is named *qfile-agent*, the rpc server is named *qfile-unpacker*. For DispVM copy, the rpc action is *qubes.OpenInVM*, the rpc client is named *qopen-in-vm*, rpc server is named *vm-file-editor*. Note that the *qubes.OpenInVM* action can be done on a normal AppVM, too.
 
 Being a rpc server, *qfile-unpacker* must be coded securely, as it processes potentially untrusted data format. Particularly, we do not want to use external tar or cpio and be prone to all vulnerabilities in them; we want a simplified, small utility, that handles only directory/file/symlink file type, permissions, mtime/atime, and assume user/user ownership. In the current implementation, the code that actually parses the data from srcVM has ca 100 lines of code and executes chrooted to the destination directory. The latter is hardcoded to `~user/QubesIncoming/srcVM`; because of chroot, there is no possibility to alter files outside of this directory.
diff --git a/developer/services/qmemman.md b/developer/services/qmemman.md
index 03495c25..f1f4d0d2 100644
--- a/developer/services/qmemman.md
+++ b/developer/services/qmemman.md
@@ -15,7 +15,7 @@ Rationale
 
 Traditionally, Xen VMs are assigned a fixed amount of memory. It is not the optimal solution, as some VMs may require more memory than assigned initially, while others underutilize memory. Thus, there is a need for solution capable of shifting free memory from VM to another VM.
 
-The [tmem](https://oss.oracle.com/projects/tmem/) project provides a "pseudo-RAM" that is assigned on per-need basis. However this solution has some disadvantages:
+The [tmem](https://web.archive.org/web/20210712161104/https://oss.oracle.com/projects/tmem/) project provides a "pseudo-RAM" that is assigned on per-need basis. However this solution has some disadvantages:
 
 - It does not provide real RAM, just an interface to copy memory to/from fast, RAM-based storage. It is perfect for swap, good for file cache, but not ideal for many tasks.
 - It is deeply integrated with the Linux kernel. When Qubes will support Windows guests natively, we would have to port *tmem* to Windows, which may be challenging.
@@ -24,13 +24,19 @@ Therefore, in Qubes another solution is used. There is the *qmemman* dom0 daemon
 
 Similarly, when there is need for Xen free memory (for instance, in order to create a new VM), traditionally the memory is obtained from dom0 only. When *qmemman* is running, it offers an interface to obtain memory from all domains.
 
-To sum up, *qmemman* pros and cons. Pros:
+To sum up, *qmemman* pros and cons.
+
+<div class="focus">
+  <i class="fa fa-check"></i> <strong>Pros</strong>
+</div>
 
 - provides automatic balancing of memory across participating PV and HVM domains, based on their memory demand
 - works well in practice, with less than 1% CPU consumption in the idle case
 - simple, concise implementation
 
-Cons:
+<div class="focus">
+  <i class="fa fa-times"></i> <strong>Cons</strong>
+</div>
 
 - the algorithm to calculate the memory requirement for a domain is necessarily simple, and may not closely reflect reality
 - *qmemman* is notified by a VM about memory usage change not more often than 10 times per second (to limit CPU overhead in VM). Thus, there can be up to 0.1s delay until qmemman starts to react to the new memory requirements
diff --git a/user/advanced-topics/bind-dirs.md b/user/advanced-topics/bind-dirs.md
index 0481dfb8..945d336e 100644
--- a/user/advanced-topics/bind-dirs.md
+++ b/user/advanced-topics/bind-dirs.md
@@ -19,7 +19,7 @@ In an app qube all of the file system comes from the template except `/home`, `/
 This means that changes in the rest of the filesystem are lost when the app qube is shutdown.
 bind-dirs provides a mechanism whereby files usually taken from the template can be persisted across reboots.
 
-For example, in Whonix, Tor's data dir `/var/lib/tor` [has been made persistent](https://github.com/Whonix/qubes-whonix/blob/8438d13d75822e9ea800b9eb6024063f476636ff/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf#L5) in the TemplateBased ProxyVM sys-whonix. In this way sys-whonix can benefit from the Tor anonymity feature 'persistent Tor entry guards' but does not have to be a standalone.
+For example, in Whonix, Tor's data dir `/var/lib/tor` [has been made persistent in the TemplateBased ProxyVM sys-whonix](https://github.com/Whonix/qubes-whonix/blob/8438d13d75822e9ea800b9eb6024063f476636ff/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf#L5). In this way sys-whonix can benefit from the Tor anonymity feature 'persistent Tor entry guards' but does not have to be a standalone.
 
 ## How to use bind-dirs.sh?
 
diff --git a/user/advanced-topics/gui-configuration.md b/user/advanced-topics/gui-configuration.md
index 56a06227..533cb084 100644
--- a/user/advanced-topics/gui-configuration.md
+++ b/user/advanced-topics/gui-configuration.md
@@ -42,8 +42,8 @@ You might face issues when playing video, if the video is choppy instead of
 smooth display this could be because the X server doesn't work. You can use the
 Linux terminal (Ctrl-Alt-F2) after starting the virtual machine, login. You can
 look at the Xorg logs file. As an option you can have the below config as
-well present in `/etc/X11/xorg.conf.d/90-intel.conf`, depends on HD graphics
-though -
+well present in `/etc/X11/xorg.conf.d/90-intel.conf` (depends on HD graphics
+though).
 
 ```bash
 Section "Device"
diff --git a/user/advanced-topics/mount-from-other-os.md b/user/advanced-topics/mount-from-other-os.md
index e930cf8e..a5e16cbf 100644
--- a/user/advanced-topics/mount-from-other-os.md
+++ b/user/advanced-topics/mount-from-other-os.md
@@ -90,7 +90,7 @@ Reverting Changes
 -----------------------------------------
 
 Any changes which were made to the system in the above steps will need to be reverted before the disk will properly boot.
-However, LVM will not allow an VG to be renamed to a name already in use.
+However, LVM will not allow a VG to be renamed to a name already in use.
 Thes steps must occur either in an app qube or using recovery media.
 
 1. Unmount any disks that were accessed.
diff --git a/user/reference/glossary.md b/user/reference/glossary.md
index 98649dd4..897f77ab 100644
--- a/user/reference/glossary.md
+++ b/user/reference/glossary.md
@@ -137,7 +137,7 @@ its net qube.
 
 ## policies
 
-In Qubes OS, "policies" govern interactions between qubes, powered by [Qubes' qrexec system](https://www.qubes-os.org/doc/qrexec/).
+In Qubes OS, "policies" govern interactions between qubes, powered by [Qubes' qrexec system](/doc/qrexec/).
 A single policy is a rule applied to a qube or set of qubes, that governs how and when information or assets may be shared with other qubes.  
 An example is the rules governing how files can be copied between qubes.  
 Policy rules are grouped together in files under `/etc/qubes/policy.d`  

From e9fc4813706e675ce32d8318e0e7fe2550539e09 Mon Sep 17 00:00:00 2001
From: AleIlMagno <123492061+AleIlMagno@users.noreply.github.com>
Date: Sun, 2 Mar 2025 11:33:20 +0100
Subject: [PATCH 267/332] Update installation-guide.md

---
 .../installation-guide.md                            | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/user/downloading-installing-upgrading/installation-guide.md b/user/downloading-installing-upgrading/installation-guide.md
index 3377f744..2ff54aea 100644
--- a/user/downloading-installing-upgrading/installation-guide.md
+++ b/user/downloading-installing-upgrading/installation-guide.md
@@ -91,25 +91,27 @@ This section will demonstrate a simple installation using mostly default setting
 
 ### Getting to the boot screen
 
-"Booting" is the process of starting your computer. When a computer boots up, it first runs low-level software before the main operating system. Depending on the computer, this low-level software is may be called the ["BIOS"](https://en.wikipedia.org/wiki/BIOS) or ["UEFI"](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface).
+"Booting" is the process of starting your computer. When a computer boots up, it first runs low-level software before the main operating system. Depending on the computer, this low-level software may be called the ["BIOS"](https://en.wikipedia.org/wiki/BIOS) or ["UEFI"](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface).
 
 Since you're installing Qubes OS, you'll need to access your computer's BIOS or UEFI menu so that you can tell it to boot from the USB drive to which you just copied the Qubes installer ISO.
 
 To begin, power off your computer and plug the USB drive into a USB port, but don't press the power button yet. Right after you press the power button, you'll have to immediately press a specific key to enter the BIOS or UEFI menu. The key to press varies from brand to brand. `Esc`, `Del`, and `F10` are common ones. If you're not sure, you can search the web for `<COMPUTER_MODEL> BIOS key` or `<COMPUTER_MODEL> UEFI key` (replacing `<COMPUTER_MODEL>` with your specific computer model) or look it up in your computer's manual.
 
-Once you know the key to press, press your computer's power button, then repeatedly press that key until you've entered your computer's BIOS or UEFI menu. To give you and idea of what you should be looking for, we've provided a couple of example photos below.
+Once you know the key to press, press your computer's power button, then repeatedly press that key until you've entered your computer's BIOS or UEFI menu. To give you an idea of what you should be looking for, we've provided a couple of example photos below.
 
 Here's an example of what the BIOS menu looks like on a ThinkPad T430:
 
 [![ThinkPad T430 BIOS menu](/attachment/doc/Thinkpad-t430-bios-main.jpg)](/attachment/doc/Thinkpad-t430-bios-main.jpg)
 
-And here's an example of what a UEFI menu looks like:
+And here's an example of what a modern UEFI menu looks like:
 
 [![UEFI menu](/attachment/doc/uefi.jpeg)](/attachment/doc/uefi.jpeg)
 
-Once you access your computer's BIOS or UEFI menu, you'll want to go to the "boot menu," which is where you tell your computer which devices to boot from. The goal is to tell the computer to boot from your USB drive so that you can run the Qubes installer. If your boot menu lets you select which device to boot from first, simply select your USB drive. (If you have multiple entries that all look similar to your USB drive, and you're not sure which one is correct, one option is just to try each one until it works.) If, on the other hand, your boot menu presents you with a list of boot devices in order, then you'll want to move your USB drive to the top so that the Qubes installer runs before anything else.
+Once you access your computer's BIOS or UEFI menu, you'll want to go to the "boot menu", which is where you tell your computer which devices to boot from. The goal is to tell the computer to boot from your USB drive so that you can run the Qubes installer. If your boot menu lets you select which device to boot from first, simply select your USB drive. (If you have multiple entries that all look similar to your USB drive, and you're not sure which one is correct, one option is just to try each one until it works.) If, on the other hand, your boot menu presents you with a list of boot devices in order, then you'll want to move your USB drive to the top so that the Qubes installer runs before anything else.
 
-Once you're done on the boot menu, save your changes. How you do this depends on your BIOS or UEFI, but the instructions should be displayed right there on the screen or in a nearby tab. (If you're not sure whether you've saved your changes correctly, you can always reboot your computer and go back into the boot menu to check whether it still reflects your changes.) Once your BIOS or UEFI is configured the way you want it, reboot your computer. This time, don't press any special keys. Instead, let the BIOS or UEFI load and let your computer boot from your USB drive. If you're successful in this step, after a few seconds you'll be presented with the Qubes installer screen:
+Then, if you are on a computer using UEFI, you'll have to disable [Secure Boot](https://en.m.wikipedia.org/wiki/UEFI#SECURE-BOOT) to allow Qubes OS to boot.
+
+Once you're done with the settings, save your changes. How you do this depends on your BIOS or UEFI, but the instructions should be displayed right there on the screen or in a nearby tab. (If you're not sure whether you've saved your changes correctly, you can always reboot your computer and go back into the boot menu to check whether it still reflects your changes.) Once your BIOS or UEFI is configured the way you want it, reboot your computer. This time, don't press any special keys. Instead, let the BIOS or UEFI load and let your computer boot from your USB drive. If you're successful in this step, after a few seconds you'll be presented with the Qubes installer screen:
 
 [![Boot screen](/attachment/doc/boot-screen-4.2.png)](/attachment/doc/boot-screen-4.2.png)
 

From b12d615e1054b47a8b76fb3eac934afcb3be6228 Mon Sep 17 00:00:00 2001
From: Guillaume Chinal <guiiix@invisiblethingslab.com>
Date: Sun, 2 Mar 2025 11:58:13 +0100
Subject: [PATCH 268/332] doc: custom-persist feature

---
 user/advanced-topics/bind-dirs.md | 38 +++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/user/advanced-topics/bind-dirs.md b/user/advanced-topics/bind-dirs.md
index acdc515d..fe6923ab 100644
--- a/user/advanced-topics/bind-dirs.md
+++ b/user/advanced-topics/bind-dirs.md
@@ -109,6 +109,44 @@ binds=( "${binds[@]/'/var/lib/tor'}" )
 
 (Editing `/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf` directly is strongly discouraged, since such changes get lost when that file is changed in the package on upgrades.)
 
+## Custom persist feature ##
+
+Custom persist is an optional advanced feature allowing the creation of minimal state AppVM. The purpose of such an AppVM is to avoid unwanted data to persist as much as possible by the disabling the ability to configure persistence from the VM itself. When enabled, the following happens:
+* ``/rw/config/rc.local`` is no longer executed
+* ``/rw/config/qubes-firewall-user-script`` is ignored
+* ``/rw/config/suspend-module-blacklist`` is ignored
+* User bind dirs defined in ``/rw/config/qubes-bind-dirs.d`` are no longer read
+* ``/home`` and ``/user/local`` are not persistent anymore unless explicitly configured. 
+
+Bind dirs are obviously still supported but this must be configured either in the template (``/usr/lib/qubes-bind-dirs.d`` and ``/etc/qubes-bind-dirs.d``) or from dom0 using ``qvm-features``. The bind dirs declaration must be done this way: ``qvm-features <VMNAME> custom-persist.<ARBITRARY NAME> [PRE-CREATION SETTINGS]<PATH>``
+
+To use this feature, first, enable it:
+
+```
+qvm-service -e my-app-vm custom-persist
+```
+
+Then, configure a persistent directory with ``qvm-features``:
+
+```
+qvm-features my-app-vm custom-persist.my_persistent_dir /var/my_persistent_dir
+```
+
+To re-enable ``/home`` and ``/usr/local`` persistence, just add them to the list:
+```
+qvm-features my-app-vm custom-persist.home /home
+qvm-features my-app-vm custom-persist.usrlocal /usr/local
+```
+
+When starting the VM, declared custom-persist bind dirs are automatically added to the ``binds`` variable described above and are handled in the same way. 
+
+A user may want their bind-dirs to be automatically pre-created in ``/rw/bind-dirs``. Custom persist can do this for you by providing the type of the resource to create (file or dir), owner, group and mode. For example:
+
+```
+qvm-features my-app-vm custom-persist.downloads dir:user:user:0755:/home/user/Downloads
+qvm-features my-app-vm custom-persist.my_ssh_known_hosts_file file:user:user:0600:/home/user/.ssh/known_hosts
+```
+
 ## Discussion ##
 
 [app qubes: make selected files and folders located in the root image persistent- review bind-dirs.sh](https://groups.google.com/forum/#!topic/qubes-devel/tcYQ4eV-XX4/discussion)

From 6f9a1d73430f3e2bf70acedd755069828e030cc1 Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Sun, 9 Mar 2025 15:57:38 -0400
Subject: [PATCH 269/332] formatting, valid url

---
 user/advanced-topics/salt.md                |  6 +++---
 user/templates/windows/windows-qubes-4-1.md | 11 ++++++++---
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/user/advanced-topics/salt.md b/user/advanced-topics/salt.md
index 0b5633de..1b0767f7 100644
--- a/user/advanced-topics/salt.md
+++ b/user/advanced-topics/salt.md
@@ -67,9 +67,9 @@ The lowest level is a single state function, called like
 this `state.single pkg.installed name=firefox-esr`
 When the system compiles data from sls formulas, it generates *chunks* -
 low chunks are at the bottom of the compiler . You can call them with
-`state.low`
+`state.low`.
 Next up is the *lowstate* level - this is the list of all low chunks in
-order. - To see them you have `state.show_lowstate`, and use `state.lowstate` to apply them.
+order. To see them you have `state.show_lowstate`, and use `state.lowstate` to apply them.
 At the top level is *highstate* - this is an interpretation of **all** the data represented in YAML
 in sls files. You can view it with `state.show_highstate`.
 
@@ -219,7 +219,7 @@ Instead, to get this behavior, you would use a `do` statement.
 So you should take a look at the [Jinja API documentation](https://jinja.palletsprojects.com/templates/).
 Documentation about using Jinja to directly call Salt functions and get data
 about your system can be found in the official
-[Salt documentation](https://docs.saltproject.io/en/getstarted/config/jinja.html#get-data-using-salt).
+[Salt documentation](https://docs.saltproject.io/salt/user-guide/en/latest/topics/jinja.html).
 
 ## Salt Configuration, QubesOS layout
 
diff --git a/user/templates/windows/windows-qubes-4-1.md b/user/templates/windows/windows-qubes-4-1.md
index 09f13e5e..f2928a42 100644
--- a/user/templates/windows/windows-qubes-4-1.md
+++ b/user/templates/windows/windows-qubes-4-1.md
@@ -34,7 +34,7 @@ For better integration, a set of drivers and services, called Qubes Windows Tool
 
 ## Importing a Windows VM from an earlier version of Qubes
 
-- Importing from R3.2 or earlier will not work, because  Qubes R3.2 has the old stubdomain by default and this is preserved over backup and restore (as Windows otherwise won't boot.
+- Importing from R3.2 or earlier will not work, because  Qubes R3.2 has the old stubdomain by default and this is preserved over backup and restore (as Windows otherwise won't boot).
 
 - Importing from R4.0 should work, see [Migrate backups of Windows VMs created under Qubes R4.0 to R4.1](/doc/templates/windows/migrate-to-4-1).
 
@@ -127,7 +127,12 @@ These parameters are set for the following reasons:
 - Disable direct boot so that the VM will go through the standard cdrom/HDD boot sequence. This is done by setting the qube's kernel to an empty value.
 
 - After creating the new qube, increase the VM's `qrexec_timeout`: in case you happen to get a BSOD or a similar crash in the VM, utilities like `chkdsk` won't complete on restart before `qrexec_timeout` automatically halts the VM. That can really put the VM in a totally unrecoverable state, whereas with higher `qrexec_timeout`, `chkdsk` or the appropriate utility has plenty of time to fix the VM. Note that Qubes Windows Tools also require a larger timeout to move the user profiles to the private volume the first time the VM reboots after the tools' installation. So set the parameter via the following CLI command from a dom0 terminal, because the Qube manager does not support this setting:
+
+    ~~~
+    qvm-prefs WindowsNew qrexec_timeout 7200
+    ~~~
   
+
 **Start Windows VM**
 
 - The VM is now ready to be started; the best practice is to use an installation ISO [located in a VM](/doc/standalones-and-hvms/#installing-an-os-in-an-hvm). Now boot the newly created qube from the Windows installation media. In the Qubes Manager:
@@ -164,7 +169,7 @@ These parameters are set for the following reasons:
 
 <div class="alert alert-warning" role="alert">
   <i class="fa fa-exclamation-triangle"></i>
-  **Caution:** This temporary patch may cease to work if it so pleases Microsoft some time.
+  **Caution:** This temporary patch may stop functioning at Microsoft's discretion at some point in the future.
 </div>
 
     
@@ -259,7 +264,7 @@ On starting the AppVM, sometimes a message is displayed that the Xen PV Network
 
 **Caution:** These AppVMs must not be started while the corresponding TemplateVM is running, because they share the TemplateVM's license data. Even if this could work sometimes, it would be a violation of the license terms.
 
-Furthermore, if manual IP setup was used for the template, the IP address selected for the template will also be used for the AppVM, as it inherits this address from the template. Qubes, however, will have assigned a different address to the AppVM, which will have to changed to that of the template (e.g. 10.137.0.x) so that the AppVM can access the network, vis the CLI command in a dom0 terminal:
+Furthermore, if manual IP setup was used for the template, the IP address selected for the template will also be used for the AppVM, as it inherits this address from the template. Qubes, however, will have assigned a different address to the AppVM, which will have to be changed to that of the template (e.g. 10.137.0.x) so that the AppVM can access the network, via the CLI command in a dom0 terminal:
 
 ~~~
 qvm-prefs WindowsNew ip 10.137.0.x

From c7465b0d6ef2a093428f0866553dbb400a59ed49 Mon Sep 17 00:00:00 2001
From: parulin <161326115+parulin@users.noreply.github.com>
Date: Tue, 11 Mar 2025 13:43:35 -0400
Subject: [PATCH 270/332] Adding more headers and ideas to troubleshoot
 appmenus

The "App menu shortcut troubleshooting" page seemed to be somewhat
outdated and lacking in information to facilitate troubleshooting. This
is what I did:

* trying to use consistently "qube" instead of "vm"
* trying to get consistent placeholders as uppercase between brackets
* the first part now has a title and distinguishes the GUI from the CLI,
  when needed, it is referred to in the following part, instead of
  repeating it.
* when a shortcut is missing, add a way to check it from the qube, to
  get a better understanding of the problem ("Unavailable desktop
  entry")
* the example of a desktop entry is simplified to its bare minimum
* "Fixing shortcuts" is replaced by a more accurate title. Not sure if
  this part is still useful.
* mention that `my-old-vm` becomes `my_dold_dvm`
* removed an off-topic comment on Windows HVM and a missing (old?) script
* new part about how to troubleshoot a shortcut that doesn't do anything

Todo:

* update the screenshots
* is the "custom entry" still useful ?
* "Behind the scenes" could be developed
---
 .../app-menu-shortcut-troubleshooting.md      | 128 ++++++++++++++----
 1 file changed, 101 insertions(+), 27 deletions(-)

diff --git a/user/troubleshooting/app-menu-shortcut-troubleshooting.md b/user/troubleshooting/app-menu-shortcut-troubleshooting.md
index 4b918736..dd5d7d55 100644
--- a/user/troubleshooting/app-menu-shortcut-troubleshooting.md
+++ b/user/troubleshooting/app-menu-shortcut-troubleshooting.md
@@ -16,19 +16,56 @@ Clicking on such shortcut runs the assigned application in its app qube.
 
 ![dom0-menu.png"](/attachment/doc/r4.0-dom0-menu.png)
 
-To make applications newly installed via the OS's package manager show up in the menu, use the `qvm-sync-appmenus` command (Linux qubes do this automatically):
+How-to add a shortcut
+---------------------
 
-`qvm-sync-appmenus vmname`
+With the graphical user interface
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-After that, select the *Add more shortcuts* entry in the qube's submenu to customize which applications are shown:
+To make applications newly installed show up in the menu, you can use the qube's *Settings*. Under the *Applications* tab, use the *Refresh Applications* button. Linux qubes do this automatically, if the *Settings* are opened after the installation of the package.
 
 ![dom0-appmenu-select.png"](/attachment/doc/r4.0-dom0-appmenu-select.png)
 
-The above image shows that Windows HVMs are also supported (provided that Qubes Tools are installed).
+After that, use the directional buttons (`>`, `>>`, `<` or `<<`) to customize which applications are shown, by moving them to the *Applications shown in App Menu* part (on the right side). Use the *Apply* (or *Ok*) button to see the changes in the app menu.
+
+With the console user interface
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To update the list of available applications, use the `qvm-sync-appmenus` command in dom0, replacing `<QUBE_NAME>` by the qube name:
+
+```console
+$ qvm-sync-appmenus <QUBE_NAME>
+```
+
+When using the *Refresh Applications* button in a qube's settings, the command `qvm-sync-appmenus` is used at least one time. When refreshing an AppvM applications, it is also run against the template. So the console equivalent of clicking the *Refresh button* is the following (always in dom0):
+
+```console
+$ qvm-sync-appmenus <APPVM_NAME>
+$ qvm-sync-appmenus <TEMPLATE_NAME>
+```
+
+In dom0, the `qvm-appmenus` tool allows the user to see the list of available applications (unstable feature), the whitelist of currently show application (unstable feature) and to change this list:
+
+```console
+$ qvm-appmenus --set-whitelist <FILE_PATH> <QUBE_NAME>
+```
+
+To change the whitelist shown in app menu, you need to provide a list of the desktop entries. Each line contains a desktop entry name, with its `.desktop` extension, like this:
+
+```
+qubes-open-file-manager.desktop
+qubes-run-terminal.desktop
+[...]
+```
+
+You can replace the file path by a single hyphen (`-`) to read it from standard input.
 
 What if my application has not been automatically included in the list of available apps?
 -----------------------------------------------------------------------------------------
 
+Missing desktop entry
+^^^^^^^^^^^^^^^^^^^^^
+
 Sometimes applications may not have included a `.desktop` file and may not be detected by `qvm-sync-appmenus`.
 Other times, you may want to make a web shortcut available from the Qubes start menu.
 
@@ -42,22 +79,20 @@ To do this:
 
    ```
    [Desktop Entry]
-   Version=1.0
    Type=Application
-   Terminal=false
-   Icon=/usr/share/icons/Adwaita/256x256/devices/scanner.png
    Name=VueScan
-   GenericName=Scanner
-   Comment=Scan Documents
-   Categories=Office;Scanning;
    Exec=vuescan
    ```
 
-3. In dom0, run `qvm-sync-appmenus <templateName>`.
-4. Go to VM Settings of the app qube(s) to which you want to add the new shortcut, then the Applications tab.
-   Move the newly created shortcut to the right under selected.
+3. Follow the instructions in [How-to add a shortcut](#how-to-add-a-shortcut)
 
-If you only want to create a shortcut for a single app qube, you can create a custom menu entry instead:
+If you only want to create a shortcut for a single app qube:
+
+1. Open a terminal window to the template.
+2. Create a custom `.desktop` file in either `~/.local/share/applications` or `/usr/local/share/applications` (you may need to first create the subdirectory). See the previous instructions about the desktop entry format.
+3. Follow the instructions in [How-to add a shortcut](#how-to-add-a-shortcut)
+
+To add a custom menu entry instead:
 
 1. Open a terminal window to Dom0.
 2. Create a custom `.desktop` file in `~/.local/share/applications`.
@@ -75,46 +110,85 @@ If you only want to create a shortcut for a single app qube, you can create a cu
    </Menu>
    ~~~
 
+Unavailable desktop entry
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If you created a desktop entry but it doesn't show up, there are some steps to run inside the qube, to identify the problem:
+
+1. make sure the name is a valid name (only ascii letters, numbers, hyphens and point)
+2. if this program is available, run `desktop-file-validate <DESKTOP_FILE_PATH>`
+3. run it through `gtk-launch`
+4. run `/etc/qubes-rpc/qubes.GetAppmenus` and check that your desktop entry is listed in the output
+
 What about applications in disposables?
 -----------------------------------
 
 [See here](/doc/disposable-customization/).
 
-Fixing shortcuts
-----------------
+What if a removed application is still in the app menu?
+--------------------------------------------------------
 
 First, try this in dom0:
 
 ```
-$ qvm-appmenus --update --force <vm_name>
+$ qvm-appmenus --update --force <QUBE_NAME>
 ```
 
-If that doesn't work, you can manually modify the files in `~/.local/share/applications/` or `/usr/local/share/applications/`.
-
-For example, suppose you've deleted `my-old-vm`, but there is a leftover Application Menu shortcut, and you find a related file in `~/.local/share/applications/`.
-In dom0:
+You can also try:
 
 ```
-$ rm -i ~/.local/share/applications/my-old-vm-*
+$ qvm-appmenus --remove <QUBE_NAME>
+```
+
+If that doesn't work, you can manually modify the files in `~/.local/share/applications/` or in `~/.local/share/qubes-appmenus/<QUBE_NAME>`.
+
+For example, suppose you've deleted `my-old-vm`, but there is a leftover Application Menu shortcut, and you find a related file in `~/.local/share/applications/`, try to delete it. The hyphens in the name of the qube are replaced by an underscore and the letter, so instead of looking for `my-old-vm`, try `my_dold_dvm`.
+
+What if my application is shown in app menu, but doesn't run anything?
+----------------------------------------------------------------------
+
+First, check in the corresponding `.desktop` file in  `~/.local/share/qubes-appmenus/<QUBE_NAME>/`, inside dom0.
+
+The line starting with `Exec=` points out the exact command run by dom0 to start the application. It should be something like:
+
+```
+Exec=qvm-run -q -a --service -- <QUBE_NAME> qubes.StartApp+<APPLICATION_NAME>
+```
+
+It's possible to run the command to check the output, by copying this line without `Exec=`, and remove `-q` (quiet option). But it could be more useful to run it in the qube, with the `qubes.StartApp` service:
+
+```
+$ /etc/qubes-rpc/qubes.StartApp <APPLICATION_NAME>
 ```
 
 Behind the scenes
 -----------------
 
 `qvm-sync-appmenus` works by invoking the *GetAppMenus* [Qubes service](/doc/qrexec/) in the target domain.
-This service enumerates applications installed in that qube and sends formatted info back to the dom0 script (`/usr/libexec/qubes-appmenus/qubes-receive-appmenus`) which creates `.desktop` files in the app qube/template directory of dom0.
+This service enumerates applications installed in that qube and sends formatted info back to dom0 which creates `.desktop` files in the app qube/template directory of dom0.
 
 For Linux qubes the service script is in `/etc/qubes-rpc/qubes.GetAppMenus`.
 In Windows it's a PowerShell script located in `c:\Program Files\Invisible Things Lab\Qubes OS Windows Tools\qubes-rpc-services\get-appmenus.ps1` by default.
 
-The list of installed applications for each app qube is stored in dom0's `~/.local/share/qubes-appmenus/<vmname>/apps.templates`.
+The list of installed applications for each app qube is stored in dom0's `~/.local/share/qubes-appmenus/<QUBE_NAME>/apps.templates`.
 Each menu entry is a file that follows the [.desktop file format](https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html) with some wildcards (*%VMNAME%*, *%VMDIR%*).
-Applications selected to appear in the menu are stored in `~/.local/share/qubes-appmenus/<vmname>/apps`.
+Applications selected to appear in the menu are stored in `~/.local/share/qubes-appmenus/<QUBE_NAME>/apps` and in `~/.local/share/applications/`.
+
+The whitelist given to `qvm-appmenu --set-whitelist` is stored as a feature called `menu-items`, where each desktop entry is separated by a space.
 
 Actual command lines for the menu shortcuts involve the `qvm-run` command which starts a process in another domain.
-Examples: `qvm-run -q -a --service -- %VMNAME% qubes.StartApp+7-Zip-7-Zip_File_Manager` or `qvm-run -q -a --service -- %VMNAME% qubes.StartApp+firefox`
+Examples:
 
-Note that you can create a shortcut that points to a `.desktop` file in your app qube with e.g. `qvm-run -q -a --service -- personal qubes.StartApp+firefox`.
+```
+qvm-run -q -a --service -- %VMNAME% qubes.StartApp+firefox
+qvm-run -q -a --service -- %VMNAME% qubes.StartApp+7-Zip-7-Zip_File_Manager
+```
+
+Note that you can create a shortcut that points to a `.desktop` file in your app qube with e.g.:
+
+```
+qvm-run -q -a --service -- personal qubes.StartApp+firefox
+```
 
 While this works well for standard applications, creating a menu entry for Windows applications running under *wine* may need an additional step in order to establish the necessary environment in *wine*. Installing software under *wine* will create the needed `.desktop` file in the target Linux qube in the directory `~/.local/share/applications/wine/Programs/` or a subdirectory thereof, depending on the Windows menu structure seen under *wine*. If the name of this file contains spaces, it will not be found, because the `qvm-run` command is falsely seen as terminating at this space. The solution is to remove these spaces by renaming the `.desktop` file accordingly, e.g. by renaming `Microsoft Excel.desktop` to `Excel.desktop`. Refreshing the menu structure will then build working menu entries.
 

From 7d51661c762a4f9334d690b2fc7a89ac0948caf6 Mon Sep 17 00:00:00 2001
From: parulin <161326115+parulin@users.noreply.github.com>
Date: Wed, 12 Mar 2025 09:10:32 -0400
Subject: [PATCH 271/332] Fixing typos on "App menu shortcut troubleshooting"

* correct markdown titles
* correct formating of images (and removing useless alt text)
* other typos
---
 .../app-menu-shortcut-troubleshooting.md      | 40 +++++++------------
 1 file changed, 15 insertions(+), 25 deletions(-)

diff --git a/user/troubleshooting/app-menu-shortcut-troubleshooting.md b/user/troubleshooting/app-menu-shortcut-troubleshooting.md
index dd5d7d55..9da6ace8 100644
--- a/user/troubleshooting/app-menu-shortcut-troubleshooting.md
+++ b/user/troubleshooting/app-menu-shortcut-troubleshooting.md
@@ -14,22 +14,19 @@ title: App menu shortcut troubleshooting
 For ease of use Qubes aggregates shortcuts to applications that are installed in app qubes and shows them in one application menu (aka "app menu" or "start menu") in dom0.
 Clicking on such shortcut runs the assigned application in its app qube.
 
-![dom0-menu.png"](/attachment/doc/r4.0-dom0-menu.png)
+[![](/attachment/doc/r4.0-dom0-menu.png)](/attachment/doc/r4.0-dom0-menu.png)
 
-How-to add a shortcut
----------------------
+## How-to add a shortcut
 
-With the graphical user interface
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+### With the graphical user interface
 
 To make applications newly installed show up in the menu, you can use the qube's *Settings*. Under the *Applications* tab, use the *Refresh Applications* button. Linux qubes do this automatically, if the *Settings* are opened after the installation of the package.
 
-![dom0-appmenu-select.png"](/attachment/doc/r4.0-dom0-appmenu-select.png)
+[![](/attachment/doc/r4.0-dom0-appmenu-select.png)](/attachment/doc/r4.0-dom0-appmenu-select.png)
 
 After that, use the directional buttons (`>`, `>>`, `<` or `<<`) to customize which applications are shown, by moving them to the *Applications shown in App Menu* part (on the right side). Use the *Apply* (or *Ok*) button to see the changes in the app menu.
 
-With the console user interface
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+### With the command-line interface
 
 To update the list of available applications, use the `qvm-sync-appmenus` command in dom0, replacing `<QUBE_NAME>` by the qube name:
 
@@ -37,7 +34,7 @@ To update the list of available applications, use the `qvm-sync-appmenus` comman
 $ qvm-sync-appmenus <QUBE_NAME>
 ```
 
-When using the *Refresh Applications* button in a qube's settings, the command `qvm-sync-appmenus` is used at least one time. When refreshing an AppvM applications, it is also run against the template. So the console equivalent of clicking the *Refresh button* is the following (always in dom0):
+When using the *Refresh Applications* button in a qube's settings, the command `qvm-sync-appmenus` is used at least one time. When refreshing an AppVM application, it is also run against the template. So the console equivalent of clicking the *Refresh button* is the following (always in dom0):
 
 ```console
 $ qvm-sync-appmenus <APPVM_NAME>
@@ -60,11 +57,9 @@ qubes-run-terminal.desktop
 
 You can replace the file path by a single hyphen (`-`) to read it from standard input.
 
-What if my application has not been automatically included in the list of available apps?
------------------------------------------------------------------------------------------
+## What if my application has not been automatically included in the list of available apps?
 
-Missing desktop entry
-^^^^^^^^^^^^^^^^^^^^^
+### Missing desktop entry
 
 Sometimes applications may not have included a `.desktop` file and may not be detected by `qvm-sync-appmenus`.
 Other times, you may want to make a web shortcut available from the Qubes start menu.
@@ -110,23 +105,20 @@ To add a custom menu entry instead:
    </Menu>
    ~~~
 
-Unavailable desktop entry
-^^^^^^^^^^^^^^^^^^^^^^^^^
+### Unavailable desktop entry
 
 If you created a desktop entry but it doesn't show up, there are some steps to run inside the qube, to identify the problem:
 
-1. make sure the name is a valid name (only ascii letters, numbers, hyphens and point)
+1. make sure the name is a valid name (only ASCII letters, numbers, hyphens and point)
 2. if this program is available, run `desktop-file-validate <DESKTOP_FILE_PATH>`
 3. run it through `gtk-launch`
 4. run `/etc/qubes-rpc/qubes.GetAppmenus` and check that your desktop entry is listed in the output
 
-What about applications in disposables?
------------------------------------
+## What about applications in disposables?
 
-[See here](/doc/disposable-customization/).
+See [Adding programs to the app menu in Disposable customization](/doc/disposable-customization/#adding-programs-to-the-app-menu).
 
-What if a removed application is still in the app menu?
---------------------------------------------------------
+## What if a removed application is still in the app menu?
 
 First, try this in dom0:
 
@@ -144,8 +136,7 @@ If that doesn't work, you can manually modify the files in `~/.local/share/appli
 
 For example, suppose you've deleted `my-old-vm`, but there is a leftover Application Menu shortcut, and you find a related file in `~/.local/share/applications/`, try to delete it. The hyphens in the name of the qube are replaced by an underscore and the letter, so instead of looking for `my-old-vm`, try `my_dold_dvm`.
 
-What if my application is shown in app menu, but doesn't run anything?
-----------------------------------------------------------------------
+## What if my application is shown in app menu, but doesn't run anything?
 
 First, check in the corresponding `.desktop` file in  `~/.local/share/qubes-appmenus/<QUBE_NAME>/`, inside dom0.
 
@@ -161,8 +152,7 @@ It's possible to run the command to check the output, by copying this line witho
 $ /etc/qubes-rpc/qubes.StartApp <APPLICATION_NAME>
 ```
 
-Behind the scenes
------------------
+## Behind the scenes
 
 `qvm-sync-appmenus` works by invoking the *GetAppMenus* [Qubes service](/doc/qrexec/) in the target domain.
 This service enumerates applications installed in that qube and sends formatted info back to dom0 which creates `.desktop` files in the app qube/template directory of dom0.

From 4bc755033b9525eeaf8eb5b1c1d71411ca8660dc Mon Sep 17 00:00:00 2001
From: kimsmi <kim.smith.11235@proton.me>
Date: Fri, 14 Mar 2025 11:11:11 -0400
Subject: [PATCH 272/332] gui-troubleshooting.md: Improve the section about
 external screens

I was affected by this problem. When I saw this documentation, I didn't realize this was the problem affecting me. I don't have a 4K monitor; I have a wide monitor. I can click on most things, just not in specific sections of the screen.

Rewrite to be more generic.
---
 user/troubleshooting/gui-troubleshooting.md | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/user/troubleshooting/gui-troubleshooting.md b/user/troubleshooting/gui-troubleshooting.md
index a2761396..689990df 100644
--- a/user/troubleshooting/gui-troubleshooting.md
+++ b/user/troubleshooting/gui-troubleshooting.md
@@ -6,16 +6,22 @@ ref: 233
 title: GUI troubleshooting
 ---
 
-## Can't click on anything after connecting 4k external display
+## Can't click on parts of screens after connecting high-resolution external display
 
-When you connect a 4K external display, you may be unable to click on anything but a small area in the upper-right corner.
+When you connect a high-resolution external display, you may be unable to click on parts of the screen.
 
 When a qube starts, a fixed amount of RAM is allocated to the graphics buffer called video RAM.
 This buffer needs to be at least as big as the whole desktop, accounting for all displays that are or will be connected to the machine.
 By default, it is as much as needed for the current display and an additional full HD (FHD) display (1920×1080 8 bit/channel RGBA).
-This logic fails when the machine has primary display in FHD resolution and, after starting some qubes, a 4K display is connected.
+This logic fails when the machine has primary display in FHD resolution and, after starting some qubes, a high-resolution display is connected.
 If the buffer is too small, and internal desktop resize fails.
 
+To determine if this is the problem affecting you, look at the Xorg log inside the Qube at `/home/user/.local/share/xorg/Xorg.0.log` for lines like the following:
+
+~~~
+[  1623.988] (EE) DUMMYQBS(0): Unable to set up a virtual screen size of 3440x1440 with 17101 Kb of video memory available.  Please increase the video memory size.
+~~~
+
 The solution to this problem is to increase the minimum size of the video RAM buffer, as explained in [GUI Configuration](/doc/gui-configuration/#video-ram-adjustment-for-high-resolution-displays).
 
 ## Screen blanks / Weird computer glitches like turning partially black or black boxes

From 1e9029ac7d23588d4c7a0f0deda0d3f2e422303e Mon Sep 17 00:00:00 2001
From: kimsmi <kim.smith.11235@proton.me>
Date: Fri, 14 Mar 2025 11:16:22 -0400
Subject: [PATCH 273/332] Improve phrasing

---
 user/troubleshooting/gui-troubleshooting.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/troubleshooting/gui-troubleshooting.md b/user/troubleshooting/gui-troubleshooting.md
index 689990df..819b7e6b 100644
--- a/user/troubleshooting/gui-troubleshooting.md
+++ b/user/troubleshooting/gui-troubleshooting.md
@@ -6,7 +6,7 @@ ref: 233
 title: GUI troubleshooting
 ---
 
-## Can't click on parts of screens after connecting high-resolution external display
+## Can't click on parts of the screen after connecting high-resolution external display
 
 When you connect a high-resolution external display, you may be unable to click on parts of the screen.
 

From 8db0e634b390c7bef3704c54c161e5d9311e8c6a Mon Sep 17 00:00:00 2001
From: Corey Ford <corey@coreyford.name>
Date: Tue, 18 Mar 2025 19:12:09 +0100
Subject: [PATCH 274/332] firewall: reword DNS resolution note

---
 user/security-in-qubes/firewall.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index a94f087a..5df80b5c 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -40,8 +40,8 @@ If the qube is running, you can open Settings from the Qube Popup Menu.
 ICMP and DNS are not accessible in the GUI, but can be changed via `qvm-firewall` described below.
 Connections to Updates Proxy are not made over a network so can not be allowed or blocked with firewall rules, but are controlled using the relevant policy file (see [R4.x Updates proxy](/doc/software-update-vm/) for more detail).
 
-Note that if you specify a rule by DNS name it will be resolved to IP(s) *at the moment of applying the rules*, and not on the fly for each new connection.
-This means it will not work for servers using load balancing, and traffic to complex web sites which draw from many servers will be difficult to control.
+Note that if you specify a rule by DNS name it will be resolved to IP(s) *at the moment the rules take effect* (including each time the qube or netvm starts), and not on the fly for each new connection.
+This means it will not work reliably for servers that have different IPs at different times as a result of DNS-based load balancing.
 
 Instead of using the firewall GUI, you can use the `qvm-firewall` command in Dom0 to edit the firewall rules by hand.
 This gives you greater control than by using the GUI.

From 0c274977fec6196eb803b58982df18763549039a Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Fri, 21 Mar 2025 18:38:35 -0400
Subject: [PATCH 275/332] minor formatting, wording

---
 user/advanced-topics/bind-dirs.md             |  3 +-
 user/advanced-topics/volume-backup-revert.md  | 14 +++---
 .../windows/qubes-windows-tools-4-1.md        | 48 ++++++++++---------
 3 files changed, 34 insertions(+), 31 deletions(-)

diff --git a/user/advanced-topics/bind-dirs.md b/user/advanced-topics/bind-dirs.md
index 37c26409..07c470b4 100644
--- a/user/advanced-topics/bind-dirs.md
+++ b/user/advanced-topics/bind-dirs.md
@@ -110,7 +110,8 @@ binds=( "${binds[@]/'/var/lib/tor'}" )
 
 ## Custom persist feature ##
 
-Custom persist is an optional advanced feature allowing the creation of minimal state AppVM. The purpose of such an AppVM is to avoid unwanted data to persist as much as possible by the disabling the ability to configure persistence from the VM itself. When enabled, the following happens:
+Custom persist is an optional advanced feature allowing the creation of minimal state AppVM. The purpose of such an AppVM is to avoid unwanted data to persist as much as possible by disabling the ability to configure persistence from the VM itself. When enabled, the following happens:
+
 * ``/rw/config/rc.local`` is no longer executed
 * ``/rw/config/qubes-firewall-user-script`` is ignored
 * ``/rw/config/suspend-module-blacklist`` is ignored
diff --git a/user/advanced-topics/volume-backup-revert.md b/user/advanced-topics/volume-backup-revert.md
index f06f1ca8..4a39334a 100644
--- a/user/advanced-topics/volume-backup-revert.md
+++ b/user/advanced-topics/volume-backup-revert.md
@@ -17,13 +17,13 @@ shutdown. (Note that this is a different, lower level activity than the
 
 In Qubes, when you create a new VM, it's volumes are stored in one of the
 system's [Storage Pools](/doc/storage-pools/). On pool creation, a
-revisions_to_keep default value is set for the entire pool. (For a pool creation
+`revisions_to_keep` default value is set for the entire pool. (For a pool creation
 example, see [Storing app qubes on Secondary Drives](/doc/secondary-storage/).)
 Thereafter, each volume associated with a VM that is stored in this pool
-inherits the pool default revisions_to_keep.
+inherits the pool default `revisions_to_keep`.
 
-For the private volume associated with a VM named vmname, you may inspect the
-value of revisions_to_keep from the dom0 CLI as follows:
+For the private volume associated with a VM named *vmname*, you may inspect the
+value of `revisions_to_keep` from the dom0 CLI as follows:
 
 ```
 qvm-volume info vmname:private
@@ -31,11 +31,11 @@ qvm-volume info vmname:private
 
 The output of the above command will also display the "Available revisions
 (for revert)" at the bottom. For a very large volume in a small pool,
-revisions_to_keep should probably be set to the maximum value of 1 to minimize
+`revisions_to_keep` should probably be set to the maximum value of 1 to minimize
 the possibility of the pool being accidentally filled up by snapshots. For a
 smaller volume for which you would like to have the future option of reverting,
-revisions_to_keep should probably be set to at least 2. To set
-revisions_to_keep for this same VM / volume example:
+`revisions_to_keep` should probably be set to at least 2. To set
+`revisions_to_keep` for this same VM / volume example:
 
 ```
 qvm-volume config vmname:private revisions_to_keep 2
diff --git a/user/templates/windows/qubes-windows-tools-4-1.md b/user/templates/windows/qubes-windows-tools-4-1.md
index 8bf82841..c5fd23aa 100644
--- a/user/templates/windows/qubes-windows-tools-4-1.md
+++ b/user/templates/windows/qubes-windows-tools-4-1.md
@@ -42,7 +42,7 @@ If you prefer to download the corresponding .rpm files for manual QWT installati
 
 **Note**: If you choose to move profiles, drive letter `Q:` must be assigned to the secondary (private) disk.
 
-**Note**: Xen PV disk drivers are not installed by default. This is because they seem to cause problems (BSOD = Blue Screen Of Death). We're working with upstream devs to fix this. *However*, the BSOD seems to only occur after the first boot and everything works fine after that. **Enable the drivers at your own risk** of course, but we welcome reports of success/failure in any case (backup your VM first!). With disk PV drivers absent `qvm-block` will not work for the VM, but you can still use standard Qubes inter-VM file copying mechanisms. On the other hand, the Xen PV drivers allow USB device access even without QWT installation if `qvm-features stubdom-qrexec` is set as `1`
+**Note**: Xen PV disk drivers are not installed by default. This is because they seem to cause problems (BSOD = Blue Screen Of Death). We're working with upstream devs to fix this. *However*, the BSOD seems to only occur after the first boot and everything works fine after that. **Enable the drivers at your own risk** of course, but we welcome reports of success/failure in any case (backup your VM first!). With disk PV drivers absent `qvm-block` will not work for the VM, but you can still use standard Qubes inter-VM file copying mechanisms. On the other hand, the Xen PV drivers allow USB device access even without QWT installation if `qvm-features stubdom-qrexec` is set as `1`.
 
 Below is a breakdown of the feature availability depending on the windows version:
 
@@ -76,7 +76,7 @@ Qubes Windows Tools are open source and are distributed under a GPL license.
  2. In the command prompt type `bcdedit /set testsigning on`
  3. Reboot your Windows VM
 
-In the future this step will not be necessary anymore, because we will sign our drivers with a publicly verifiable certificate. However, it should be noted that even now, the fact that those drivers are not digitally signed, this doesn't affect security of the Windows VM in 'any' way. This is because the actual installation `iso` file can be verified as described in step 3 below. The only downside of those drivers not being signed is the inconvenience to the user that he or she must disable the signature enforcement policy before installing the tools.
+In the future this step will not be necessary anymore, because we will sign our drivers with a publicly verifiable certificate. However, it should be noted that even, given the fact that those drivers are not digitally signed, this doesn't affect security of the Windows VM in 'any' way. This is because the actual installation `iso` file can be verified as described in step 3 below. The only downside of those drivers not being signed is the inconvenience to the user that he or she must disable the signature enforcement policy before installing the tools.
 
 The Xen PV Drivers bundled with QWT are signed by a Linux Foundation certificate. Thus Windows 10 and 11 do not require this security mitigation.
 
@@ -126,33 +126,40 @@ Installing the Qubes Windows Tools on Windows 7, 8.1, 10 and 11 both as a Standa
 
  4. Install Qubes Windows Tools by starting `qubes-tools-x64.msi` (logged in as administrator), optionally selecting the `Xen PV disk drivers`. For installation in a template, you should select `Move user profiles`.
 	
-	[![QWT_install_select](/attachment/doc/QWT_install_select.png)](/attachment/doc/QWT_install_select.png)
+    [![QWT_install_select](/attachment/doc/QWT_install_select.png)](/attachment/doc/QWT_install_select.png)
 
-	Several times, Windows security may ask for confirmation of driver installation. Driver installation has to be allowed; otherwise the installation of Qubes Windows Tools will abort.
+    Several times, Windows security may ask for confirmation of driver installation. Driver installation has to be allowed; otherwise the installation of Qubes Windows Tools will abort.
 	
-	[![QWT_install_driver](/attachment/doc/QWT_install_driver.png)](/attachment/doc/QWT_install_driver.png)
+    [![QWT_install_driver](/attachment/doc/QWT_install_driver.png)](/attachment/doc/QWT_install_driver.png)
 
-	If during installation, the Xen driver requests a reboot, select "No" and let the installation continue - the system will be rebooted later.
+    If during installation, the Xen driver requests a reboot, select "No" and let the installation continue - the system will be rebooted later.
 
-	[![QWT_install_no_restart](/attachment/doc/QWT_install_no_restart.png)](/attachment/doc/QWT_install_no_restart.png)
+    [![QWT_install_no_restart](/attachment/doc/QWT_install_no_restart.png)](/attachment/doc/QWT_install_no_restart.png)
 
  5. After successful installation, the Windows VM must be shut down and started again, possibly a couple of times. On each shutdown, wait until the VM is really stopped, i.e. Qubes shows no more activity.
 
  6. Qubes will automatically detect that the tools have been installed in the VM and will set appropriate properties for the VM, such as `qrexec_installed`, `guiagent_installed`, and `default_user`. This can be verified (but is not required) using the `qvm-prefs` command  *(where* `<VMname>` *is the name of your Windows VM)*:
 
-	        [user@dom0 ~] $ qvm-prefs <VMname>
+
+    ```
+        [user@dom0 ~] $ qvm-prefs <VMname>
+    ```
 
  	It is advisable to set some other parameters in order to enable audio and USB block device access, synchronize the Windows clock with the Qubes clock, and so on:
 	        
-	        [user@dom0 ~] $ qvm-features <VMname> audio-model ich9
-	        [user@dom0 ~] $ qvm-features <VMname> stubdom-qrexec 1
-	        [user@dom0 ~] $ qvm-features <VMname> timezone localtime
+    ```
+	    [user@dom0 ~] $ qvm-features <VMname> audio-model ich9
+	    [user@dom0 ~] $ qvm-features <VMname> stubdom-qrexec 1
+	    [user@dom0 ~] $ qvm-features <VMname> timezone localtime
+    ```
 
-	For audio, the parameter `audio-model`can be selected as `ich6` or `ich9`; select the value that gives the best audio quality. Audio quality may also be improved by setting the following parameters, but this can depend on the Windows version and on your hardware:
-
-	        [user@dom0 ~] $ qvm-features <VMname> timer-period 1000
-	        [user@dom0 ~] $ qvm-features <VMname> out.latency 10000
-	        [user@dom0 ~] $ qvm-features <VMname> out.buffer-length 4000
+	For audio, the parameter `audio-model` can be selected as `ich6` or `ich9`; select the value that gives the best audio quality. Audio quality may also be improved by setting the following parameters, but this can depend on the Windows version and on your hardware:
+    
+    ```
+	    [user@dom0 ~] $ qvm-features <VMname> timer-period 1000
+	    [user@dom0 ~] $ qvm-features <VMname> out.latency 10000
+	    [user@dom0 ~] $ qvm-features <VMname> out.buffer-length 4000
+    ```
 
 	With the value `localtime` the dom0 `timezone` will be provided to virtual hardware, effectively setting the Windows clock to that of Qubes. With a digit value (negative or positive) the guest clock will have an offset (in seconds) applied relative to UTC.
 
@@ -171,16 +178,11 @@ Installing the Qubes Windows Tools on Windows 7, 8.1, 10 and 11 both as a Standa
 	 - Terminate the registry editor.
 	
  	 After the next boot, the VM will start in seamless mode.
-	
 	 If Windows is used in a TemplateVM / AppVM combination, this registry fix has to be applied to the TemplateVM, as the `HKLM` registry key belongs to the template-based part of the registry.
 	
- 10. Lastly to enable file copy operations to a Windows VM, the `default_user` property of this VM should be set to the `<username>` that you use to login to the Windows VM. This can be done via the following command on a `dom0` terminal: *(where* `<VMname>` *is the name of your Windows VM)*
-	
-		`[user@dom0 ~] $ qvm-prefs <VMname> default_user <username>`
+ 10. Lastly to enable file copy operations to a Windows VM, the `default_user` property of this VM should be set to the `<username>` that you use to login to the Windows VM. This can be done via the following command on a `dom0` terminal: `[user@dom0 ~] $ qvm-prefs <VMname> default_user <username>` *(where* `<VMname>` *is the name of your Windows VM)*.
   
-  **Warning:** If this property is not set or set to a wrong value, files copied to this VM are stored in the folder
- 
- 		C:\Windows\System32\config\systemprofile\Documents\QubesIncoming\<source_VM>
+  **Warning:** If this property is not set or set to a wrong value, files copied to this VM are stored in the folder `C:\Windows\System32\config\systemprofile\Documents\QubesIncoming\<source_VM>`.
 
  If the target VM is an AppVM, this has the consequence that the files are stored in the corresponding TemplateVM and so are lost on AppVM shutdown.
 

From 06e37e444b7d2745caf7e6cbf5e5854c26c3e722 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marta=20Marczykowska-G=C3=B3recka?=
 <marmarta@invisiblethingslab.com>
Date: Tue, 2 Jul 2024 16:37:26 +0200
Subject: [PATCH 276/332] Add intro for Builder v2

---
 developer/building/development-workflow.md    |  53 +++---
 developer/building/qubes-builder-v2.md        | 160 ++++++++++++++++++
 developer/debugging/automated-tests.md        |   2 +-
 developer/debugging/test-bench.md             |   5 +-
 developer/general/gsoc.md                     |   4 +-
 introduction/faq.md                           |   2 +-
 .../testing.md                                |   2 +-
 user/templates/templates.md                   |   7 +-
 8 files changed, 192 insertions(+), 43 deletions(-)
 create mode 100644 developer/building/qubes-builder-v2.md

diff --git a/developer/building/development-workflow.md b/developer/building/development-workflow.md
index dd72699a..e4967756 100644
--- a/developer/building/development-workflow.md
+++ b/developer/building/development-workflow.md
@@ -12,14 +12,14 @@ title: Development workflow
 
 A workflow for developing Qubes OS+
 
-First things first, setup [QubesBuilder](/doc/qubes-builder/). This guide
-assumes you're using qubes-builder to build Qubes.
+First things first, setup [QubesBuilder](/doc/qubes-builder-v2/). This guide
+assumes you're using qubes-builder v2 to build Qubes.
 
 ## Repositories and committing Code
 
 Qubes is split into a bunch of git repos. These are all contained in the
-`qubes-src` directory under qubes-builder. Subdirectories there are separate
-components, stored in separate git repositories.
+`artifacts/sources` directory under qubes-builder. Subdirectories there are
+separate components, stored in separate git repositories.
 
 The best way to write and contribute code is to create a git repo somewhere
 (e.g., github) for the repo you are interested in editing (e.g.,
@@ -29,7 +29,7 @@ of Qubes, cd to the repo directory and add your repository as a remote in git
 **Example:**
 
 ~~~
-$ cd qubes-builder/qubes-src/qubes-manager
+$ cd qubes-builder/artifacts/sources/qubes-manager
 $ git remote add abel git@github.com:abeluck/qubes-manager.git
 ~~~
 
@@ -47,7 +47,7 @@ include your public PGP key you use to sign your tags.
 
 #### Prepare fresh version of kernel sources, with Qubes-specific patches applied
 
-In qubes-builder/qubes-src/linux-kernel:
+In qubes-builder/artifacts/sources/linux-kernel:
 
 ~~~
 make prep
@@ -66,7 +66,7 @@ drwxr-xr-x  6 user user 4096 Nov 21 20:48 kernel-3.4.18/linux-obj
 
 #### Go to the kernel tree and update the version
 
-In qubes-builder/qubes-src/linux-kernel:
+In qubes-builder/artifacts/sources/linux-kernel:
 
 ~~~
 cd kernel-3.4.18/linux-3.4.18
@@ -117,8 +117,6 @@ vi series.conf
 
 #### Building RPMs
 
-TODO: Is this step generic for all subsystems?
-
 Now it is a good moment to make sure you have changed kernel release name in
 rel file. For example, if you change it to '1debug201211116c' the
 resulting RPMs will be named
@@ -131,34 +129,23 @@ your changes locally.
 To actually build RPMs, in qubes-builder:
 
 ~~~
-make linux-kernel
+./qb -c linux-kernel package fetch prep build
 ~~~
 
-RPMs will appear in qubes-src/linux-kernel/pkgs/fc20/x86\_64:
+RPMs will appear in
+`artifacts/repository/destination_name/package_name`
+(for example `artifacts/repository/host-fc37/linux-kernel-6.6.31-1.1/`
 
-~~~
--rw-rw-r-- 1 user user 42996126 Nov 17 04:08 kernel-3.4.18-1debug20121116c.pvops.qubes.x86_64.rpm
--rw-rw-r-- 1 user user 43001450 Nov 17 05:36 kernel-3.4.18-1debug20121117a.pvops.qubes.x86_64.rpm
--rw-rw-r-- 1 user user  8940138 Nov 17 04:08 kernel-devel-3.4.18-1debug20121116c.pvops.qubes.x86_64.rpm
--rw-rw-r-- 1 user user  8937818 Nov 17 05:36 kernel-devel-3.4.18-1debug20121117a.pvops.qubes.x86_64.rpm
--rw-rw-r-- 1 user user 54490741 Nov 17 04:08 kernel-qubes-vm-3.4.18-1debug20121116c.pvops.qubes.x86_64.rpm
--rw-rw-r-- 1 user user 54502117 Nov 17 05:37 kernel-qubes-vm-3.4.18-1debug20121117a.pvops.qubes.x86_64.rpm
-~~~
+### Useful [QubesBuilder](/doc/qubes-builder-v2/) commands
 
-### Useful [QubesBuilder](/doc/qubes-builder/) commands
-
-1. `make check` - will check if all the code was committed into repository and
-if all repository are tagged with signed tag.
-2. `make show-vtags` - show version of each component (based on git tags) -
-mostly useful just before building ISO. **Note:** this will not show version
-for components containing changes since last version tag.
-3. `make push` - push change from **all** repositories to git server. You must
-set proper remotes (see above) for all repositories first.
-4. `make prepare-merge` - fetch changes from remote repositories (can be
-specified on commandline via GIT\_SUBDIR or GIT\_REMOTE vars), (optionally)
-verify tags and show the changes. This do not merge the changes - there are
-left for review as FETCH\_HEAD ref. You can merge them using `git merge
-FETCH_HEAD` (in each repo directory). Or `make do-merge` to merge all of them.
+1. `./qb package diff` - show uncommitted changes
+2. ` ./qb repository check-release-status-for-component` and
+`./qb repository check-release-status-for-template`- show version of each
+   component/template (based on git tags)
+3. `./qb package sign` -  sign built packages
+4. `./qb package publish` and `./qb package upload` - publish signed packages
+   and upload published
+   repository
 
 ## Copying Code to dom0
 
diff --git a/developer/building/qubes-builder-v2.md b/developer/building/qubes-builder-v2.md
new file mode 100644
index 00000000..79d85e21
--- /dev/null
+++ b/developer/building/qubes-builder-v2.md
@@ -0,0 +1,160 @@
+---
+lang: en
+layout: doc
+permalink: /doc/qubes-builder-v2/
+redirect_from:
+- /en/doc/qubes-builder-v2/
+- /doc/QubesBuilder2/
+- /wiki/QubesBuilder2/
+ref: 311
+title: Qubes builder v2
+---
+
+This is a brief introduction of using Qubes Builder v2 to work with Qubes OS
+sources. It will walk you through installing and configuring Builder v2 and
+using it to fetch and build Qubes OS packages.
+
+For details and customization, use [Qubes OS v2 builder documentation](https://github.com/QubesOS/qubes-builderv2/).
+
+# Overview
+
+In the second generation of Qubes OS builder, container or disposable qube
+isolation is used to perform every stage of the build and release process.
+From fetching sources to building, everything is executed inside an isolated
+*cage* (either a disposable or a container) using an *executor*. For every
+command that needs to perform an action on sources, like cloning and
+verifying Git repos, rendering a SPEC file, generating SRPM or Debian
+source packages, a new cage is used. Only the signing, publishing, and
+uploading stages are executed locally outside a cage.
+
+
+# Setup
+
+This is a simple setup for using a docker executor (a good default choice,
+if you don't know which executor to use, use docker).
+
+1. First, decide what qube are you going to use for working with Qubes
+   Builder v2. It can be an AppVM or a Standalone qube, with some steps
+   different between the two.
+
+2. Then, clone the qubes-builder v2 repository into a location of your
+   choice:
+    ```shell
+    git clone https://github.com/QubesOS/qubes-builderv2
+    cd qubes-builderv2/
+    ```
+
+3. Installing dependencies
+
+   Dependencies need to be installed for the qube you want to be developing
+   using Qubes Builder v2 - either in its template, or in the qube itself,
+   if it's a standalone.
+    Dependencies are specified in `dependencies-*.
+   txt` files in the main builder directory, and you can install them easily
+   in the following ways:
+   1. for Fedora, use:
+    ```shell
+    $ sudo dnf install $(cat dependencies-fedora.txt)
+    $ test -f /usr/share/qubes/marker-vm && sudo dnf install qubes-gpg-split
+   ```
+   2. for Debian (note: some Debian packages require Debian version 13 or
+      later), use:
+    ```shell
+    $ sudo apt install $(cat dependencies-debian.txt)
+    $ test -f /usr/share/qubes/marker-vm && sudo apt install qubes-gpg-split
+   ```
+
+4. If you haven't used docker in the current qube, you need also to set up
+   some permissions. In particular, the user has to be added to the `docker`
+   group:
+    ```shell
+   $ sudo usermod -aG docker user
+    ```
+    Next, **restart the qube**.
+
+5. Finally, you need to generate a docker image:
+    ```shell
+   $ tools/generate-container-image.sh docker
+    ```
+
+   In an AppVM, as `/var/lib/docker` is not persistent by default, you also
+   need to use bind-dirs to avoid repeating this step after reboot, adding
+   the following to the `/rw/config/qubes-bind-dirs.d/docker.conf` file in
+   this qube:
+
+   ```
+   binds+=( '/var/lib/docker' )
+   ```
+
+# Configuration
+
+To use Qubes OS Builder v2, you need to have a `builder.yml` configuration file.
+You can use one of the sample files from the `example-configs/` directory; for a
+more readable `builder.yml`, you can also include one of the files from that
+directory in your `builder.yml`. An example `builder.yml` is:
+
+```yaml
+# include configuration relevant for the current release
+include:
+- example-configs/qubes-os-r4.2.yml
+
+# which repository to use to fetch sources
+use-qubes-repo:
+  version: 4.2
+  testing: true
+
+# each package built will have local build number appended to package release
+# number. It makes it easier to update in testing environment
+increment-devel-versions: true
+
+# reduce output
+debug: false
+
+# this can be set to true if you do not want sources to be automatically
+# fetched from git
+skip-git-fetch: false
+
+# executor configuration
+executor:
+  type: docker
+  options:
+    image: "qubes-builder-fedora:latest"
+
+```
+
+
+# Using Builder v2
+
+To fetch sources - in this example, for the `core-admin-client` package, you
+can use the following command:
+
+```shell
+$ ./qb -c core-admin-client package fetch
+```
+
+This will fetch the sources for the listed package and place them in
+`artifacts/sources` directory.
+
+To build a package (from sources in the `artifacts/sources` directory), use:
+
+```shell
+$ ./qb -c core-admin-client package fetch prep build
+```
+
+or, if you want to build for a specific target (`host-fc37` is a `dom0`
+using Fedora 37, `vm-fc40` would be a qube using Fedora 40 etc.), use:
+
+```shell
+$ ./qb -c core-admin-client -d host-fc37 package fetch prep build
+```
+
+If you want to fetch entire Qubes OS sources (caution: some repositories might
+have additional requirements; you can disable repositories that are not
+needed in the `example-configs/*.yml` file you are using by commenting them
+out. In particular, `python-fido2`, `lvm` and `windows`-related repositories
+have
+special requirements), use the following:
+
+```shell
+$ ./qb package fetch
+```
diff --git a/developer/debugging/automated-tests.md b/developer/debugging/automated-tests.md
index 38e4aca2..1f72ede8 100644
--- a/developer/debugging/automated-tests.md
+++ b/developer/debugging/automated-tests.md
@@ -132,7 +132,7 @@ Whereas integration tests are mostly stored in the [qubes-core-admin](https://gi
 To for example run the `qubes-core-admin` unit tests, you currently have to clone at least [qubes-core-admin](https://github.com/QubesOS/qubes-core-admin) and
 its dependency [qubes-core-qrexec](https://github.com/QubesOS/qubes-core-qrexec) repository in the branches that you want to test.
 
-The below example however will assume that you set up a build environment as described in the [Qubes Builder documentation](/doc/qubes-builder/).
+The below example however will assume that you set up a build environment as described in the [Qubes Builder documentation](/doc/qubes-builder-v2/).
 
 Assuming you cloned the `qubes-builder` repository to your home directory inside a fedora VM, you can use the following commands to run the unit tests:
 
diff --git a/developer/debugging/test-bench.md b/developer/debugging/test-bench.md
index ca48a5ea..66a072c5 100644
--- a/developer/debugging/test-bench.md
+++ b/developer/debugging/test-bench.md
@@ -205,9 +205,10 @@ pushd ${HOME}/builder >/dev/null
 
 # the following are needed only if you have sources outside builder
 #rm -rf qubes-src/core-admin
-#make COMPONENTS=core-admin get-sources
+#qb -c core-admin package fetch
 
-make core-admin
+qb -c core-admin -d host-fc41 prep build
+# update your dom0 fedora distribution as appropriate
 qtb-install qubes-src/core-admin/rpm/x86_64/qubes-core-dom0-*.rpm
 qtb-runtests
 ```
diff --git a/developer/general/gsoc.md b/developer/general/gsoc.md
index e49d66d9..a2990cd9 100644
--- a/developer/general/gsoc.md
+++ b/developer/general/gsoc.md
@@ -31,7 +31,7 @@ You should start learning the components that you plan on working on before the
 
 Coming up with an interesting idea that you can realistically achieve in the time available to you (one summer) is probably the most difficult part. We strongly recommend getting involved in advance of the beginning of GSoC, and we will look favorably on applications from prospective contributors who have already started to act like free and open source developers.
 
-Before the summer starts, there are some preparatory tasks which are highly encouraged. First, if you aren't already, definitely start using Qubes as your primary OS as soon as possible! Also, it is encouraged that you become familiar and comfortable with the Qubes development workflow sooner than later. A good way to do this (and also a great way to stand out as an awesome applicant and make us want to accept you!) might be to pick up some issues from [qubes-issues](https://github.com/QubesOS/qubes-issues/issues) (our issue-tracking repo) and submit some patches addressing them. Some suitable issues might be those with tags ["help wanted" and "P: minor"](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20label%3A%22P%3A%20minor%22%20label%3A%22help%20wanted%22) (although more significant things are also welcome, of course). Doing this will get you some practice with [qubes-builder](/doc/qubes-builder/), our code-signing policies, and some familiarity with our code base in general so you are ready to hit the ground running come summer.
+Before the summer starts, there are some preparatory tasks which are highly encouraged. First, if you aren't already, definitely start using Qubes as your primary OS as soon as possible! Also, it is encouraged that you become familiar and comfortable with the Qubes development workflow sooner than later. A good way to do this (and also a great way to stand out as an awesome applicant and make us want to accept you!) might be to pick up some issues from [qubes-issues](https://github.com/QubesOS/qubes-issues/issues) (our issue-tracking repo) and submit some patches addressing them. Some suitable issues might be those with tags ["help wanted" and "P: minor"](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20label%3A%22P%3A%20minor%22%20label%3A%22help%20wanted%22) (although more significant things are also welcome, of course). Doing this will get you some practice with [qubes-builder](/doc/qubes-builder-v2/), our code-signing policies, and some familiarity with our code base in general so you are ready to hit the ground running come summer.
 
 ### Contributor proposal guidelines
 
@@ -422,7 +422,7 @@ for more information and qubes-specific background.
 
 **Difficulty**: medium
 
-**Knowledge prerequisite**: qubes-builder [[1]](/doc/qubes-builder/) [[2]](/doc/qubes-builder-details/) [[3]](https://github.com/QubesOS/qubes-builder/tree/master/doc), and efficient at introspecting complex systems: comfortable with tracing and debugging tools, ability to quickly identify and locate issues within a large codebase (upstream build tools), etc.
+**Knowledge prerequisite**: qubes-builder [[1]](/doc/qubes-builder-v2/) [[2]](https://github.com/QubesOS/qubes-builderv2), and efficient at introspecting complex systems: comfortable with tracing and debugging tools, ability to quickly identify and locate issues within a large codebase (upstream build tools), etc.
 
 **Size of the project**: 350 hours
 
diff --git a/introduction/faq.md b/introduction/faq.md
index 2258ee1b..f869f760 100644
--- a/introduction/faq.md
+++ b/introduction/faq.md
@@ -678,7 +678,7 @@ Any rpm-based, 64-bit environment, the preferred OS being Fedora.
 
 ### How do I build Qubes from sources?
 
-See [these instructions](/doc/qubes-builder/).
+See [these instructions](/doc/qubes-builder-v2/).
 
 ### How do I submit a patch?
 
diff --git a/user/downloading-installing-upgrading/testing.md b/user/downloading-installing-upgrading/testing.md
index d6e6339d..4353262f 100644
--- a/user/downloading-installing-upgrading/testing.md
+++ b/user/downloading-installing-upgrading/testing.md
@@ -17,7 +17,7 @@ How to test upcoming Qubes OS releases:
 
 - Test the latest release candidate (RC) on the [downloads](/downloads/) page, if one is currently available. (Or try an older RC from our [FTP server](https://ftp.qubes-os.org/iso/).)
 - Try the [signed weekly builds](https://qubes.notset.fr/iso/). ([Learn more](https://forum.qubes-os.org/t/16929) and [track their status](https://github.com/fepitre/updates-status-iso/issues).)
-- Use [qubes-builder](/doc/qubes-builder/) to build the latest release yourself.
+- Use [qubes-builder](/doc/qubes-builder-v2/) to build the latest release yourself.
 - (No support) Experiment with developer alpha ISOs found from time to time at [Qubes OpenQA](https://openqa.qubes-os.org/).
 
 Please make sure to [report any bugs you encounter](/doc/issue-tracking/).
diff --git a/user/templates/templates.md b/user/templates/templates.md
index 2f7ac64a..681a4951 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -429,8 +429,9 @@ this context: the same as their template filesystem, of course.
 
 * Some templates are available in ready-to-use binary form, but some of them
   are available only as source code, which can be built using the [Qubes
-  Builder](/doc/qubes-builder/). In particular, some template "flavors" are
-  available in source code form only. For the technical details of the template
+  Builder](https://github.com/QubesOS/qubes-builderv2/). In particular, some
+  template "flavors" are  available in source code form only. For the
+  technical details of the template
   system, please see [Template Implementation](/doc/template-implementation/).
-  Take a look at the [Qubes Builder](/doc/qubes-builder/) documentation for
+  Take a look at the [Qubes Builder](/doc/qubes-builder-v2/) documentation for
   instructions on how to compile them.

From 4b87eaa04d3a15f4565423e484f09679cbd94b8c Mon Sep 17 00:00:00 2001
From: Andreas Glashauser <ag@andreasglashauser.com>
Date: Sun, 23 Mar 2025 01:18:05 +0100
Subject: [PATCH 277/332] Removed outdated CentOS references

---
 user/templates/minimal-templates.md | 73 -----------------------------
 user/templates/templates.md         |  2 -
 user/templates/xfce-templates.md    |  4 +-
 3 files changed, 2 insertions(+), 77 deletions(-)

diff --git a/user/templates/minimal-templates.md b/user/templates/minimal-templates.md
index d85e8a0d..c80a02c9 100644
--- a/user/templates/minimal-templates.md
+++ b/user/templates/minimal-templates.md
@@ -55,7 +55,6 @@ Minimal templates of the following distros are available:
 
  - Fedora
  - Debian
- - CentOS
  - Gentoo
 
 A list of all available templates can also be obtained with the [Template Manager](/doc/template-manager/) tool.
@@ -305,75 +304,3 @@ Documentation on all of these can be found in the [docs](/doc/).
 You could, of course, use `qubes-vm-recommended` to automatically install many
 of these, but in that case you are well on the way to a standard Debian
 template.
-
-### CentOS
-
-The following list provides an overview of which packages are needed for which
-purpose. As usual, the required packages are to be installed in the running
-template with the following command (replace `packages` with a space-delimited
-list of packages to be installed):
-
-```
-[user@your-new-clone ~]$ sudo yum install packages
-```
-
-- Commonly used utilities: `pciutils` `vim-minimal` `less` `psmisc`
-  `gnome-keyring`
-- Audio: `pulseaudio-qubes`.
-- Networking: `qubes-core-agent-networking`, and whatever network tools
-  you want. N.B. minimal templates do not include any browser.
-- [FirewallVM](/doc/firewall/), such as the template for `sys-firewall`: at
-  least `qubes-core-agent-networking`, and also `qubes-core-agent-dom0-updates`
-  if you want to use it as the `UpdateVM` (which is normally `sys-firewall`).
-- NetVM, such as the template for `sys-net`: `qubes-core-agent-networking`
-  `qubes-core-agent-network-manager` `NetworkManager-wifi`
-  `network-manager-applet` `notification-daemon`
-  `gnome-keyring`. If your network devices need extra packages for a network
-  VM, use the `lspci` command to identify the devices, then find the package
-  that provides necessary firnware and install it. If you need utilities for
-  debugging and analyzing network connections, install the following packages:
-  `tcpdump` `telnet` `nmap` `nmap-ncat`
-- [USB qube](/doc/usb-qubes/), such as the template for `sys-usb`:
-  `qubes-usb-proxy` to provide USB devices to other Qubes and
-  `qubes-input-proxy-sender` to provide keyboard or mouse input to dom0.
-- [VPN
-  qube](https://forum.qubes-os.org/t/19061):
-  You may need to install network-manager VPN packages, depending on the VPN
-  technology you'll be using. After creating a machine based on this template,
-  follow the [VPN
-  howto](https://forum.qubes-os.org/t/19061#set-up-a-proxyvm-as-a-vpn-gateway-using-networkmanager)
-  to configure it.
-- `default-mgmt-dvm`: requires `qubes-core-agent-passwordless-root` and
-  `qubes-mgmt-salt-vm-connector`.
-
-In Qubes 4.0, additional packages from the `qubes-core-agent` suite may be
-needed to make the customized minimal template work properly. These packages
-are:
-
-- `qubes-core-agent-nautilus`: This package provides integration with the
-  Nautilus file manager (without it, items like "copy to VM/open in disposable"
-  will not be shown in Nautilus).
-- `qubes-core-agent-thunar`: This package provides integration with the thunar
-  file manager (without it, items like "copy to VM/open in disposable" will not
-  be shown in thunar).
-- `qubes-core-agent-dom0-updates`: Script required to handle `dom0` updates.
-  Any template on which the qube responsible for 'dom0' updates (e.g.
-  `sys-firewall`) is based must contain this package.
-- `qubes-menus`: Defines menu layout.
-- `qubes-desktop-linux-common`: Contains icons and scripts to improve desktop
-  experience.
-
-Also, there are packages to provide additional services:
-
-- `qubes-gpg-split`: For implementing split GPG.
-- `qubes-pdf-converter`: For implementing safe conversion of PDFs.
-- `qubes-img-converter`: For implementing safe conversion of images.
-- `qubes-snapd-helper`: If you want to use snaps in qubes.
-- `qubes-mgmt-salt-vm-connector`: If you want to use salt management on the
-  template and qubes.
-
-Documentation on all of these can be found in the [docs](/doc/).
-
-You could, of course, use `qubes-vm-recommended` to automatically install many
-of these, but in that case you are well on the way to a standard Debian
-template.
diff --git a/user/templates/templates.md b/user/templates/templates.md
index d12e5585..b363e04d 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -78,8 +78,6 @@ developers do not test them.
 * [Whonix](/doc/templates/whonix/)
 * [Ubuntu](/doc/templates/ubuntu/)
 * [Arch Linux](/doc/building-archlinux-template/)
-* [CentOS](/doc/templates/centos/)
-* [CentOS Minimal](/doc/templates/minimal/)
 * [Gentoo](/doc/templates/gentoo/)
 * [Gentoo Minimal](/doc/templates/minimal/)
 
diff --git a/user/templates/xfce-templates.md b/user/templates/xfce-templates.md
index 71d9f81b..3fe99de2 100644
--- a/user/templates/xfce-templates.md
+++ b/user/templates/xfce-templates.md
@@ -13,7 +13,7 @@ title: Xfce templates
 ---
 
 If you would like to use Xfce (more lightweight compared to GNOME desktop environment) Linux distribution in your qubes,
-you can install one of the available Xfce templates for [Fedora](/doc/templates/fedora/), [Debian](/doc/templates/debian/), [CentOS](/doc/templates/centos/), or [Gentoo](/doc/templates/gentoo/).
+you can install one of the available Xfce templates for [Fedora](/doc/templates/fedora/), [Debian](/doc/templates/debian/) or [Gentoo](/doc/templates/gentoo/).
 
 ## Installation
 
@@ -30,7 +30,7 @@ You may wish to try again with the testing repository enabled:
 [user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-itl-testing qubes-template-X-xfce
 ```
 
-If you would like to install a community distribution, like CentOS or Gentoo, try the install command by enabling the community repository:
+If you would like to install a community distribution such as Gentoo, try the install command by enabling the community repository:
 
 ```
 [user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-community qubes-template-X-xfce

From f71614efd9a581b6cb8a242a30b4fee567ed05d2 Mon Sep 17 00:00:00 2001
From: 3np <3np@example.com>
Date: Sun, 23 Mar 2025 02:16:21 +0000
Subject: [PATCH 278/332] how-to-install-software: clarify updates-proxy usage

- makes it less likely to get the false impression that
  the updates proxy does not allow arbitrary outbound connections
- add example of how to download software in templates without
  enabling direct networking
---
 user/how-to-guides/how-to-install-software.md | 49 +++++++++++++------
 user/how-to-guides/how-to-update.md           |  2 +-
 user/templates/templates.md                   |  2 +-
 3 files changed, 37 insertions(+), 16 deletions(-)

diff --git a/user/how-to-guides/how-to-install-software.md b/user/how-to-guides/how-to-install-software.md
index be3ee664..094f526e 100644
--- a/user/how-to-guides/how-to-install-software.md
+++ b/user/how-to-guides/how-to-install-software.md
@@ -69,17 +69,38 @@ will appear in the Applications Menu. (If you encounter problems, see
 ## Installing software from other sources
 
 **Warning:** This method gives your template direct network access, which is
-[risky](#why-dont-templates-have-network-access). This method is **not**
+[risky](#why-dont-templates-have-normal-network-access). This method is **not**
 recommended for trusted templates. Moreover, depending on how you install this
 software, it may not get updated automatically when you [update Qubes
 normally](/doc/how-to-update/), which means you may have to update it manually
 yourself.
 
 Some software is not available from the default repositories and must be
-downloaded and installed from another source. This method assumes that you're
-trying to follow the instructions to install some piece of software in a normal
-operating system, except that operating system is running as a template in
-Qubes OS.
+downloaded and installed from another source. Depending on the installation method,
+you may either use the updates proxy or direct networking.
+
+### Using the updates proxy
+
+If you are still using the distribution package manager, updates will likely still
+work over the updates proxy without needing to give the TemplateVM direct network access.
+
+If you are using another installation method fetching remote resources, you might still
+be able to use the updates proxy by making the tools aware of the proxy. For many tools,
+it is enough to export the following environment variables in your shell session before
+proceeding:
+
+```sh
+$ export HTTP_PROXY=http://127.0.0.1:8082 http_proxy=$HTTP_PROXY \
+         HTTPS_PROXY=$HTTP_PROXY https_proxy=$HTTPS_PROXY \
+         ALL_PROXY=$HTTP_PROXY all_proxy=$ALL_PROXY \
+         NO_PROXY=127.0.0.1 no_proxy=$NO_PROXY
+```
+
+### Using direct networking
+
+This method assumes that you're trying to follow the instructions to install some piece
+of software in a normal operating system, except that operating system is running as a
+template in Qubes OS.
 
 1. (Recommended) Clone the desired template (since this new template will
    probably be less trusted than the original).
@@ -140,18 +161,18 @@ If things are still not working as expected:
 Please see [How to Update](/doc/how-to-update/).
 
 
-## Why don't templates have network access?
+## Why don't templates have normal network access?
 
 In order to protect you from performing risky activities in templates, they do
 not have normal network access by default. Instead, templates use an [updates
-proxy](#updates-proxy) that allows you to install and update software using
-the distribution package manager without giving the template direct network
-access.**The updates proxy is already setup to work automatically
-out-of-the-box and requires no special action from you.** Most users should
-simply follow the normal instructions for [installing software from default
-repositories](#installing-software-from-default-repositories) and
-[updating](/doc/how-to-update/) software. If your software is not available in
-the default repositories, see [installing software from other
+proxy](#updates-proxy) which allows you to install and update software using
+the distribution package manager over the proxy connection.
+**The updates proxy is already set up to work automatically out-of-the-box and
+requires no special action from you.**
+Most users should simply follow the normal instructions for [installing software
+from default repositories](#installing-software-from-default-repositories)
+and [updating](/doc/how-to-update/) software. If your software is not available
+in the default repositories, see [installing software from other
 sources](#installing-software-from-other-sources).
 
 
diff --git a/user/how-to-guides/how-to-update.md b/user/how-to-guides/how-to-update.md
index 8e865234..5a6a7b4f 100644
--- a/user/how-to-guides/how-to-update.md
+++ b/user/how-to-guides/how-to-update.md
@@ -32,7 +32,7 @@ However, you can also start the tool manually by selecting it in the Application
 
 <div class="alert alert-info" role="alert">
   <i class="fa fa-question-circle"></i>
-  For information about how templates download updates, please see <a href="/doc/how-to-install-software/#why-dont-templates-have-network-access">Why don't templates have network access?</a> and the <a href="/doc/how-to-install-software/#updates-proxy">Updates proxy</a>.
+  For information about how templates download updates, please see <a href="/doc/how-to-install-software/#why-dont-templates-have-normal-network-access">Why don't templates have normal network access?</a> and the <a href="/doc/how-to-install-software/#updates-proxy">Updates proxy</a>.
 </div>
 
 By default, most qubes that are connected to the internet will periodically check for updates for their parent templates. You can check the date of the last update check in the "last checked" column. If updates are available for any qube, you will receive a notification as described above, and in the "Updates available" column you will see "YES" for that qube(s). If the update check did not find any new updates, "NO" will appear in the column. Respectively, for qubes that are no longer supported, "OBSOLETE" will be displayed. However, if you have any templates that do *not* have any online child qubes, you will *not* receive update notifications for them. By default, after a week, if updates for a given qube have not been checked, the value in the "Updates available" column will be set to "MAYBE". 
diff --git a/user/templates/templates.md b/user/templates/templates.md
index d12e5585..20328164 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -140,7 +140,7 @@ After installing a fresh template, we recommend performing the following steps:
 
 For information about how templates access the network, please see [Why don’t
 templates have network
-access?](/doc/how-to-install-software/#why-dont-templates-have-network-access)
+access?](/doc/how-to-install-software/#why-dont-templates-have-normal-network-access)
 and the [Updates proxy](/doc/how-to-install-software/#updates-proxy).
 
 ## Updating

From bf56b4dcd3ec89ee61ada87025d217d620e743e6 Mon Sep 17 00:00:00 2001
From: Andreas Glashauser <ag@andreasglashauser.com>
Date: Sun, 23 Mar 2025 12:16:10 +0100
Subject: [PATCH 279/332] Clarify CentOS template's EOL status

---
 user/templates/templates.md      | 3 +++
 user/templates/xfce-templates.md | 4 +++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/user/templates/templates.md b/user/templates/templates.md
index b363e04d..a79b98c3 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -80,6 +80,9 @@ developers do not test them.
 * [Arch Linux](/doc/building-archlinux-template/)
 * [Gentoo](/doc/templates/gentoo/)
 * [Gentoo Minimal](/doc/templates/minimal/)
+* [CentOS*](/doc/templates/centos)
+
+*\* The CentOS version used by this template reached End-of-Life in June 2024 and is no longer receiving updates. A proposal to create a new CentOS 10 template was [declined](https://github.com/QubesOS/qubes-issues/issues/9716).*
 
 ## Windows
 
diff --git a/user/templates/xfce-templates.md b/user/templates/xfce-templates.md
index 3fe99de2..6dac4e66 100644
--- a/user/templates/xfce-templates.md
+++ b/user/templates/xfce-templates.md
@@ -13,7 +13,9 @@ title: Xfce templates
 ---
 
 If you would like to use Xfce (more lightweight compared to GNOME desktop environment) Linux distribution in your qubes,
-you can install one of the available Xfce templates for [Fedora](/doc/templates/fedora/), [Debian](/doc/templates/debian/) or [Gentoo](/doc/templates/gentoo/).
+you can install one of the available Xfce templates for [Fedora](/doc/templates/fedora/), [Debian](/doc/templates/debian/), [Gentoo](/doc/templates/gentoo/) or [CentOS*](/doc/templates/centos/).
+
+*\* The CentOS version used by this template reached End-of-Life in June 2024 and is no longer receiving updates. A proposal to create a new CentOS 10 template was [declined](https://github.com/QubesOS/qubes-issues/issues/9716).*
 
 ## Installation
 

From b04977a7026720cc8796e68f082d8808e1c00db6 Mon Sep 17 00:00:00 2001
From: Andreas Glashauser <ag@andreasglashauser.com>
Date: Sun, 23 Mar 2025 19:35:10 +0100
Subject: [PATCH 280/332] Reword CentOS EOL notice for clarity, add link to
 more info

---
 user/templates/templates.md      | 6 +++++-
 user/templates/xfce-templates.md | 6 +++++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/user/templates/templates.md b/user/templates/templates.md
index a79b98c3..87c665e3 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -82,7 +82,11 @@ developers do not test them.
 * [Gentoo Minimal](/doc/templates/minimal/)
 * [CentOS*](/doc/templates/centos)
 
-*\* The CentOS version used by this template reached End-of-Life in June 2024 and is no longer receiving updates. A proposal to create a new CentOS 10 template was [declined](https://github.com/QubesOS/qubes-issues/issues/9716).*
+*\* The CentOS version used by this template reached 
+[End-of-Life in June 2024](https://en.wikipedia.org/wiki/CentOS_Stream#Release_history) 
+and is no longer receiving updates. Due to a lack of specific interest 
+at this time a proposal to create a new CentOS 10 template was 
+[declined](https://github.com/QubesOS/qubes-issues/issues/9716).*
 
 ## Windows
 
diff --git a/user/templates/xfce-templates.md b/user/templates/xfce-templates.md
index 6dac4e66..4a50577b 100644
--- a/user/templates/xfce-templates.md
+++ b/user/templates/xfce-templates.md
@@ -15,7 +15,11 @@ title: Xfce templates
 If you would like to use Xfce (more lightweight compared to GNOME desktop environment) Linux distribution in your qubes,
 you can install one of the available Xfce templates for [Fedora](/doc/templates/fedora/), [Debian](/doc/templates/debian/), [Gentoo](/doc/templates/gentoo/) or [CentOS*](/doc/templates/centos/).
 
-*\* The CentOS version used by this template reached End-of-Life in June 2024 and is no longer receiving updates. A proposal to create a new CentOS 10 template was [declined](https://github.com/QubesOS/qubes-issues/issues/9716).*
+*\* The CentOS version used by this template reached 
+[End-of-Life in June 2024](https://en.wikipedia.org/wiki/CentOS_Stream#Release_history) 
+and is no longer receiving updates. Due to a lack of specific interest 
+at this time a proposal to create a new CentOS 10 template was 
+[declined](https://github.com/QubesOS/qubes-issues/issues/9716).*
 
 ## Installation
 

From b55f8f092cb1ab13513bfb6eebfb465eddbf986c Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Sun, 23 Mar 2025 16:49:48 -0700
Subject: [PATCH 281/332] Revamp certified hardware documentation

- Replace list of certified models with table
- Create page for each certified model
- Organize certified hardware files in subdirectory
- Update certification details of individual model pages
- Add warnings for X230- and T430-based models
  (QubesOS/qubes-issues#9782)
---
 .../certified-hardware.md                     | 78 +++---------------
 .../dasharo-fidelisguard-z690.md              | 38 +++++++++
 .../insurgo-privacybeast-x230.md              | 26 ++++++
 .../certified-hardware/nitropad-t430.md       | 30 +++++++
 .../certified-hardware/nitropad-v56.md        | 82 +++++++++++++++++++
 .../certified-hardware/nitropad-x230.md       | 25 ++++++
 .../certified-hardware/nitropc-pro-2.md       | 47 +++++++++++
 .../certified-hardware/nitropc-pro.md         | 47 +++++++++++
 .../novacustom-nv41-series.md                 | 42 ++++++++++
 .../novacustom-v54-series.md                  | 69 ++++++++++++++++
 .../novacustom-v56-series.md                  | 69 ++++++++++++++++
 .../certified-hardware/starlabs-starbook.md   | 35 ++++++++
 12 files changed, 523 insertions(+), 65 deletions(-)
 rename user/hardware/{ => certified-hardware}/certified-hardware.md (71%)
 create mode 100644 user/hardware/certified-hardware/dasharo-fidelisguard-z690.md
 create mode 100644 user/hardware/certified-hardware/insurgo-privacybeast-x230.md
 create mode 100644 user/hardware/certified-hardware/nitropad-t430.md
 create mode 100644 user/hardware/certified-hardware/nitropad-v56.md
 create mode 100644 user/hardware/certified-hardware/nitropad-x230.md
 create mode 100644 user/hardware/certified-hardware/nitropc-pro-2.md
 create mode 100644 user/hardware/certified-hardware/nitropc-pro.md
 create mode 100644 user/hardware/certified-hardware/novacustom-nv41-series.md
 create mode 100644 user/hardware/certified-hardware/novacustom-v54-series.md
 create mode 100644 user/hardware/certified-hardware/novacustom-v56-series.md
 create mode 100644 user/hardware/certified-hardware/starlabs-starbook.md

diff --git a/user/hardware/certified-hardware.md b/user/hardware/certified-hardware/certified-hardware.md
similarity index 71%
rename from user/hardware/certified-hardware.md
rename to user/hardware/certified-hardware/certified-hardware.md
index 31a53e7e..a98835a8 100644
--- a/user/hardware/certified-hardware.md
+++ b/user/hardware/certified-hardware/certified-hardware.md
@@ -25,71 +25,19 @@ Qubes-certified computers are certified for a [major release](/doc/version-schem
 
 The current Qubes-certified models are listed below in reverse chronological order of certification.
 
-### NovaCustom V54 Series 14.0 inch coreboot laptop
-
-[![Photo of the NovaCustom V54 Series 14.0 inch coreboot laptop](/attachment/site/novacustom-v54-series.png)](https://novacustom.com/product/v54-series/)
-
-The [NovaCustom V54 Series 14.0 inch coreboot laptop](https://novacustom.com/product/v54-series/) is certified for Qubes OS Release 4.
-
-### NitroPad V56
-
-[![Photo of the NitroPad V56](/attachment/site/nitropad-v56.png)](https://shop.nitrokey.com/shop/nitropad-v56-684)
-
-The [NitroPad V56](https://shop.nitrokey.com/shop/nitropad-v56-684) is certified for Qubes OS Release 4.
-
-### NovaCustom V56 Series 16.0 inch coreboot laptop
-
-[![Photo of the NovaCustom V56 Series 16.0 inch coreboot laptop](/attachment/site/novacustom-v56-series.png)](https://novacustom.com/product/v56-series/)
-
-The [NovaCustom V56 Series 16.0 inch coreboot laptop](https://novacustom.com/product/v56-series/) is certified for Qubes OS Release 4.
-
-### NitroPC Pro 2
-
-[![Photo of the NitroPC Pro 2](/attachment/posts/nitropc-pro.jpg)](https://shop.nitrokey.com/shop/nitropc-pro-2-523)
-
-The [NitroPC Pro 2](https://shop.nitrokey.com/shop/nitropc-pro-2-523) is a desktop based on the MSI PRO Z790-P DDR5 motherboard. It is certified for Qubes OS Release 4.
-
-### Star Labs StarBook
-
-[![Photo of the Star Labs StarBook](/attachment/site/starlabs-starbook.png)](https://starlabs.systems/pages/starbook)
-
-The [Star Labs StarBook](https://starlabs.systems/pages/starbook) is a 14-inch laptop. It is certified for Qubes OS Release 4.
-
-### NitroPC Pro
-
-[![Photo of the NitroPC Pro](/attachment/posts/nitropc-pro.jpg)](https://shop.nitrokey.com/shop/product/nitropc-pro-523)
-
-The [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523) is a desktop based on the MSI PRO Z690-A DDR5 motherboard. It is certified for Qubes OS Release 4.
-
-### NovaCustom NV41 Series
-
-[![Photo of the NovaCustom NV41 Series](/attachment/site/novacustom-nv41-series.png)](https://novacustom.com/product/nv41-series/)
-
-The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is a 14-inch custom laptop. It is certified for Qubes OS Release 4.
-
-### Dasharo FidelisGuard Z690
-
-[![Photo of the Dasharo FidelisGuard Z690](/attachment/site/dasharo-fidelisguard-z690.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
-
-The [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is a desktop based on the MSI PRO Z690-A DDR4 motherboard. It is certified for Qubes OS Release 4.
-
-### NitroPad T430
-
-[![Photo of the NitroPad T430](/attachment/site/nitropad-t430.jpg)](https://shop.nitrokey.com/shop/product/nitropad-t430-119)
-
-The [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119) is a laptop based on the ThinkPad T430. It is certified for Qubes OS Release 4.
-
-### NitroPad X230
-
-[![Photo of the NitroPad X230](/attachment/site/nitropad-x230.jpg)](https://shop.nitrokey.com/shop/product/nitropad-x230-67)
-
-The [NitroPad X230](https://shop.nitrokey.com/shop/product/nitropad-x230-67) is a laptop based on the ThinkPad X230. It is certified for Qubes OS Release 4.
-
-### Insurgo PrivacyBeast X230
-
-[![Photo of the Insurgo PrivacyBeast X230](/attachment/site/insurgo-privacybeast-x230.png)](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/)
-
-The [Insurgo PrivacyBeast X230](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/) is a laptop based on the ThinkPad X230. It is certified for Qubes OS Release 4.
+| Brand                                  | Model                                                                                                                  | Certification details                                                       |
+| -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
+| [NovaCustom](https://novacustom.com/)  | [V54 Series](https://novacustom.com/product/v54-series/)                                                               | [Certification details](/doc/certified-hardware/novacustom-v54-series/)     |
+| [Nitrokey](https://www.nitrokey.com/)  | [NitroPad V56](https://shop.nitrokey.com/shop/nitropad-v56-684)                                                        | [Certification details](/doc/certified-hardware/nitropad-v56/)              |
+| [NovaCustom](https://novacustom.com/)  | [V56 Series](https://novacustom.com/product/v56-series/)                                                               | [Certification details](/doc/certified-hardware/novacustom-v56-series/)     |
+| [Nitrokey](https://www.nitrokey.com/)  | [NitroPC Pro 2](https://shop.nitrokey.com/shop/nitropc-pro-2-523)                                                      | [Certification details](/doc/certified-hardware/nitropc-pro-2/)             |
+| [Star Labs](https://starlabs.systems/) | [StarBook](https://starlabs.systems/pages/starbook)                                                                    | [Certification details](/doc/certified-hardware/starlabs-starbook/)         |
+| [Nitrokey](https://www.nitrokey.com/)  | [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523)                                                  | [Certification details](/doc/certified-hardware/nitropc-pro/)               |
+| [NovaCustom](https://novacustom.com/)  | [NV41 Series](https://novacustom.com/product/nv41-series/)                                                             | [Certification details](/doc/certified-hardware/novacustom-nv41-series/)    |
+| [3mdeb](https://3mdeb.com/)            | [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) | [Certification details](/doc/certified-hardware/dasharo-fidelisguard-z690/) |
+| [Nitrokey](https://www.nitrokey.com/)  | [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119)                                              | [Certification details](/doc/certified-hardware/nitropad-t430/)             |
+| [Nitrokey](https://www.nitrokey.com/)  | [NitroPad X230](https://shop.nitrokey.com/shop/product/nitropad-x230-67)                                               | [Certification details](/doc/certified-hardware/nitropad-x230/)             |
+| [Insurgo](https://insurgo.ca/)         | [PrivacyBeast X230](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/)         | [Certification details](/doc/certified-hardware/insurgo-privacybeast-x230/) |
 
 ## Become hardware certified
 
diff --git a/user/hardware/certified-hardware/dasharo-fidelisguard-z690.md b/user/hardware/certified-hardware/dasharo-fidelisguard-z690.md
new file mode 100644
index 00000000..88a10507
--- /dev/null
+++ b/user/hardware/certified-hardware/dasharo-fidelisguard-z690.md
@@ -0,0 +1,38 @@
+---
+lang: en
+layout: doc
+permalink: /doc/certified-hardware/dasharo-fidelisguard-z690/
+title: Dasharo FidelisGuard Z690
+image: /attachment/posts/dasharo-fidelisguard-z690_2.jpg
+---
+
+The [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
+
+[![Photo of MSI PRO Z690-A DDR4 motherboard](/attachment/posts/dasharo-fidelisguard-z690_1.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
+
+The [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is a full desktop PC build that brings the [Dasharo](https://dasharo.com/) open-source firmware distribution to the MSI PRO Z690-A DDR4 motherboard with Qubes OS preinstalled. The full configuration includes:
+
+| Part         | Model Name                                                     |
+|------------- | -------------------------------------------------------------- |
+| CPU	         | Intel Core i5-12600K, 3.7GHz                                   |
+| Cooling	     | Noctua CPU NH-U12S Redux                                       |
+| RAM	         | Kingston Fury Beast, DDR4, 4x8GB (32 GB Total), 3600 MHz, CL17 |
+| Power Supply | Seasonic Focus PX 750W 80 Plus Platinum                        |
+| Storage      | SSD Intel 670p 512 GB M.2 2280 PCI-E x4 Gen3 NVMe              |
+| Enclosure	   | SilentiumPC Armis AR1                                          |
+
+[![Photo of Dasharo FidelisGuard Z690 with open case](/attachment/posts/dasharo-fidelisguard-z690_2.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
+
+This computer comes with a "Dasharo Supporters Entrance Subscription," which includes the following:
+
+- Full access to [Dasharo Tools Suite (DTS)](https://docs.dasharo.com/dasharo-tools-suite/overview/)
+- The latest Dasharo releases issued by the Dasharo Team
+- Special Dasharo updates for supporters
+- Dasharo Premier Support through an invite-only Matrix channel
+- Influence on the Dasharo feature roadmap
+
+[![Photo of Dasharo FidelisGuard Z690 with open case](/attachment/posts/dasharo-fidelisguard-z690_3.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
+
+For further details, please see the [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) product page.
+
+[![Photo of the outside of the Dasharo FidelisGuard Z690](/attachment/posts/dasharo-fidelisguard-z690_4.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
diff --git a/user/hardware/certified-hardware/insurgo-privacybeast-x230.md b/user/hardware/certified-hardware/insurgo-privacybeast-x230.md
new file mode 100644
index 00000000..0e1a0f67
--- /dev/null
+++ b/user/hardware/certified-hardware/insurgo-privacybeast-x230.md
@@ -0,0 +1,26 @@
+---
+lang: en
+layout: doc
+permalink: /doc/certified-hardware/insurgo-privacybeast-x230/
+title: Insurgo PrivacyBeast X230
+image: /attachment/site/insurgo-privacybeast-x230.png
+---
+
+<div class="alert alert-danger" role="alert">
+  <i class="fa fa-exclamation-triangle"></i>
+  <b>Warning:</b> The CPU in this computer no longer receives microcode updates from Intel. Without microcode updates, Qubes OS cannot ensure that this computer is secure against CPU vulnerabilities. While this computer remains certified for Qubes OS Release 4, we recommend that prospective buyers consider a newer Qubes-certified computer instead.
+</div>
+
+The [Insurgo PrivacyBeast X230](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
+
+[![Photo of the Insurgo PrivacyBeast X230](/attachment/site/insurgo-privacybeast-x230.png)](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/)
+
+The [Insurgo PrivacyBeast X230](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/) is a custom refurbished [ThinkPad X230](https://www.thinkwiki.org/wiki/Category:X230) that includes the following features:
+
+- [coreboot](https://www.coreboot.org/) initialization for the x230 is binary-blob-free, including native graphic initialization. Built with the [Heads](https://github.com/osresearch/heads/) payload, it delivers an [Anti Evil Maid (AEM)](/doc/anti-evil-maid/)-like solution built into the firmware. (Even though our [requirements](/doc/certified-hardware/#hardware-certification-requirements) provide an exception for CPU-vendor-provided blobs for silicon and memory initialization, Insurgo exceeds our requirements by insisting that these be absent from its machines.)
+
+- [Intel ME](https://libreboot.org/faq.html#intelme) is neutered through the AltMeDisable bit, while all modules other than ROMP and BUP, which are required to initialize main CPU, have been [deleted](https://github.com/osresearch/heads-wiki/blob/master/Clean-the-ME-firmware.md#how-to-disabledeactive-most-of-it).
+
+- A re-ownership process that allows it to ship pre-installed with Qubes OS, including full-disk encryption already in place, but where the final disk encryption key is regenerated only when the machine is first powered on by the user, so that the OEM doesn't know it.
+
+- [Heads](https://github.com/osresearch/heads/) provisioned pre-delivery to protect against malicious [interdiction](https://en.wikipedia.org/wiki/Interdiction).
diff --git a/user/hardware/certified-hardware/nitropad-t430.md b/user/hardware/certified-hardware/nitropad-t430.md
new file mode 100644
index 00000000..54b5ed38
--- /dev/null
+++ b/user/hardware/certified-hardware/nitropad-t430.md
@@ -0,0 +1,30 @@
+---
+lang: en
+layout: doc
+permalink: /doc/certified-hardware/nitropad-t430/
+title: NitroPad T430
+image: /attachment/site/nitropad-t430.jpg
+---
+
+<div class="alert alert-danger" role="alert">
+  <i class="fa fa-exclamation-triangle"></i>
+  <b>Warning:</b> The CPU in this computer no longer receives microcode updates from Intel. Without microcode updates, Qubes OS cannot ensure that this computer is secure against CPU vulnerabilities. While this computer remains certified for Qubes OS Release 4, we recommend that prospective buyers consider a newer Qubes-certified computer instead.
+</div>
+
+<div class="alert alert-warning" role="alert">
+  <i class="fa fa-exclamation-circle"></i>
+  <b>Note:</b> Please be advised that the i7-3632QM option is <b>not</b> compatible with Qubes OS, as it does not support VT-d. The option specifically tested by the Qubes team is the i5-3320M.
+</div>
+
+The [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
+
+[![Photo of the NitroPad T430](/attachment/site/nitropad-t430.jpg)](https://shop.nitrokey.com/shop/product/nitropad-t430-119)
+
+Key features of the [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119) include:
+
+- Tamper detection through measured boot with [coreboot](https://www.coreboot.org/), [Heads](https://github.com/osresearch/heads/), and Nitrokey USB hardware, including support for [Anti Evil Maid (AEM)](/doc/anti-evil-maid/)
+- Deactivated [Intel Management Engine](https://libreboot.org/faq.html#intelme)
+- User-replaceable cryptographic keys
+- Included Nitrokey USB key
+- Professional ThinkPad hardware based on the [ThinkPad T430](https://www.thinkwiki.org/wiki/Category:T430)
+- Security-conscious shipping to mitigate against third-party [interdiction](https://en.wikipedia.org/wiki/Interdiction)
diff --git a/user/hardware/certified-hardware/nitropad-v56.md b/user/hardware/certified-hardware/nitropad-v56.md
new file mode 100644
index 00000000..262a7df7
--- /dev/null
+++ b/user/hardware/certified-hardware/nitropad-v56.md
@@ -0,0 +1,82 @@
+---
+lang: en
+layout: doc
+permalink: /doc/certified-hardware/nitropad-v56/
+title: NitroPad V56
+image: /attachment/site/nitropad-v56.png
+---
+
+The [NitroPad V56](https://shop.nitrokey.com/shop/nitropad-v56-684) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
+
+[![Photo of the NitroPad V56](/attachment/site/nitropad-v56.png)](https://shop.nitrokey.com/shop/nitropad-v56-684)
+
+## Qubes-certified options
+
+The configuration options required for Qubes certification are detailed below.
+
+### Processor and graphics card
+
+- Certified: Intel Core Ultra 5 Processor 125H, Intel Arc iGPU with AI Boost
+- Certified: Intel Core Ultra 7 Processor 155H, Intel Arc iGPU with AI Boost
+- The Nvidia GPU options are not currently certified.
+
+### Memory (RAM) DDR5, 5600 MHz
+
+- Certified: All options 16 GB (2x8 GB) and higher
+
+
+### 1st Hard Disk SSD NVMe PCIe 4.0 x4
+
+- Certified: Any of the available options in this section
+
+### 2nd Hard Disk SSD NVMe PCIe 4.0 x4
+
+- Certified: Any of the available options in this section
+
+### Keyboard
+
+- Certified: Any of the available options in this section
+
+### Wireless interfaces
+
+- Certified: Wi-Fi 6E + Bluetooth 5.3, Intel AX-210/211 (non vPro) WLAN module 2.4 Gbps, 802.11ax
+- Certified: Wi-Fi 7 + Bluetooth 5.42, Intel BE200 (non vPro) WLAN module 5.8 Gbps, 802.11be
+- Certified: No wireless
+
+### Webcam and microphone
+
+- Certified: Any of the available options in this section
+
+### Type
+
+- Certified: Any of the available options in this section
+
+### Firmware
+
+- Certified: Dasharo TianoCore UEFI without Measured boot, without Nitrokey
+- The option "Dasharo HEADS with Measured Boot, requires Nitrokey!" is not yet certified.
+
+### Operating system
+
+- Certified: Qubes OS 4.2.3 or newer (within Release 4).
+- Releases older than 4.2.3 are not certified.
+- You may choose either to have Nitrokey preinstall Qubes OS for you, or you may choose to install Qubes OS yourself. This choice does not affect certification.
+
+### Nitrokey
+
+- Certified: None -- for TianoCore only!
+- The Nitrokey options are currently not applicable to Qubes hardware certification. (See the Firmware section above.)
+
+### Shipment of Nitrokey
+
+- This section does not affect Qubes hardware certification.
+
+### Tamper-evident packaging
+
+- This section does not affect Qubes hardware certification.
+
+## Disclaimers
+
+- In order for Wi-Fi to function properly, `sys-net` must currently be based on a Fedora template. The firmware package in Debian templates is currently too old for the certified Wi-Fi cards.
+- Currently requires `kernel-latest`: If you install Qubes OS yourself, you must select the `Install Qubes OS RX using kernel-latest` option on the GRUB menu when booting the installer. This non-default kernel option is currently required for the NitroPad V56 to function properly.
+- Due to a [known bug](https://github.com/Dasharo/dasharo-issues/issues/976), the bottom-right USB-C port is currently limited to USB 2.0 speeds.
diff --git a/user/hardware/certified-hardware/nitropad-x230.md b/user/hardware/certified-hardware/nitropad-x230.md
new file mode 100644
index 00000000..01db07f8
--- /dev/null
+++ b/user/hardware/certified-hardware/nitropad-x230.md
@@ -0,0 +1,25 @@
+---
+lang: en
+layout: doc
+permalink: /doc/certified-hardware/nitropad-x230/
+title: NitroPad X230
+image: /attachment/site/nitropad-x230.jpg
+---
+
+<div class="alert alert-danger" role="alert">
+  <i class="fa fa-exclamation-triangle"></i>
+  <b>Warning:</b> The CPU in this computer no longer receives microcode updates from Intel. Without microcode updates, Qubes OS cannot ensure that this computer is secure against CPU vulnerabilities. While this computer remains certified for Qubes OS Release 4, we recommend that prospective buyers consider a newer Qubes-certified computer instead.
+</div>
+
+The [NitroPad X230](https://shop.nitrokey.com/shop/product/nitropad-x230-67) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
+
+[![Photo of the NitroPad X230](/attachment/site/nitropad-x230.jpg)](https://shop.nitrokey.com/shop/product/nitropad-x230-67)
+
+The [NitroPad X230](https://shop.nitrokey.com/shop/product/nitropad-x230-67) offers users unprecedented control over the security of their hardware. Key features include:
+
+- Tamper detection through measured boot with [coreboot](https://www.coreboot.org/), [Heads](https://github.com/osresearch/heads/), and Nitrokey USB hardware, including support for [Anti Evil Maid (AEM)](/doc/anti-evil-maid/)
+- Deactivated [Intel Management Engine](https://libreboot.org/faq.html#intelme)
+- User-replaceable cryptographic keys
+- Included Nitrokey USB key
+- Professional ThinkPad hardware based on the [ThinkPad X230](https://www.thinkwiki.org/wiki/Category:X230)
+- Security-conscious shipping to mitigate against third-party [interdiction](https://en.wikipedia.org/wiki/Interdiction)
diff --git a/user/hardware/certified-hardware/nitropc-pro-2.md b/user/hardware/certified-hardware/nitropc-pro-2.md
new file mode 100644
index 00000000..5ee72bb4
--- /dev/null
+++ b/user/hardware/certified-hardware/nitropc-pro-2.md
@@ -0,0 +1,47 @@
+---
+lang: en
+layout: doc
+permalink: /doc/certified-hardware/nitropc-pro-2/
+title: NitroPC Pro 2
+image: /attachment/posts/nitropc-pro.jpg
+---
+
+<div class="alert alert-warning" role="alert">
+  <i class="fa fa-exclamation-circle"></i>
+  <b>Note:</b> When configuring your NitroPC Pro 2 on the Nitrokey website, there is an option for a discrete graphics card (e.g., Nvidia GeForce RTX 4070 or 4090) in addition to integrated graphics (e.g., Intel UHD 770, which is always included because it is physically built into the CPU). NitroPC Pro 2 configurations that include discrete graphics cards are <em>not</em> Qubes-certified. The only NitroPC Pro 2 configurations that are Qubes-certified are those that contain <em>only</em> integrated graphics.
+</div>
+
+<div class="alert alert-warning" role="alert">
+  <i class="fa fa-exclamation-circle"></i>
+  <b>Note:</b> Only the "Dasharo TianoCore UEFI without Measured Boot, without Nitrokey" firmware option is certified. The "HEADS with Measured Boot, requires Nitrokey!" firmware option is <em>not</em> certified.
+</div>
+
+The [NitroPC Pro 2](https://shop.nitrokey.com/shop/nitropc-pro-2-523) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
+
+[![Photo of NitroPC Pro 2](/attachment/posts/nitropc-pro.jpg)](https://shop.nitrokey.com/shop/nitropc-pro-2-523)
+
+Here's a summary of the main component options available for this mid-tower desktop PC:
+
+| Component                    | Options                                                  |
+|----------------------------- | -------------------------------------------------------- |
+| Motherboard                  | MSI PRO Z790-P DDR5 (Wi-Fi optional)                     |
+| Processor                    | 14th Generation Intel Core i5-14600K or i9-14900K        |
+| Memory                       | 16 GB to 128 GB DDR5                                     |
+| NVMe storage (optional)      | Up to two NVMe PCIe 4.0 x4 SSDs, up to 2 TB each         |
+| SATA storage (optional)      | Up to two SATA SSDs, up to 7.68 TB each                  |
+| Wireless (optional)          | Wi-Fi 6E, 2400 Mbps, 802.11/a/b/g/n/ac/ax, Bluetooth 5.2 |
+| Operating system (optional)  | Qubes OS 4.2 or Ubuntu 22.04 LTS                         |
+
+Of special note for Qubes users, the NitroPC Pro 2 features a combined PS/2 port that supports both a PS/2 keyboard and a PS/2 mouse simultaneously with a Y-cable (not included). This allows for full control of dom0 without the need for USB keyboard or mouse passthrough. Nitrokey also offers a special tamper-evident shipping method for an additional fee. With this option, the case screws will be individually sealed and photographed, and the NitroPC Pro 2 will be packed inside a sealed bag. Photographs of the seals will be sent to you by email, which you can use to determine whether the case was opened during transit.
+
+The NitroPC Pro 2 also comes with a "Dasharo Entry Subscription," which includes the following:
+
+- Accesses to the latest firmware releases
+- Exclusive newsletter
+- Special updates, including early access to updates enhancing privacy, security, performance, and compatibility
+- Early access to new firmware releases for [newly-supported desktop platforms](https://docs.dasharo.com/variants/overview/#desktop) (please see the [roadmap](https://github.com/Dasharo/presentations/blob/main/dasharo_roadmap.md#dasharo-desktop-roadmap))
+- Access to the Dasharo Premier Support invite-only live chat channel on the Matrix network, allowing direct access to the Dasharo Team and fellow subscribers with personalized and priority assistance
+- Insider's view and influence on the Dasharo feature roadmap for a real impact on Dasharo development
+- [Dasharo Tools Suite Entry Subscription](https://docs.dasharo.com/osf-trivia-list/dts/#what-is-dasharo-tools-suite-supporters-entrance) keys
+
+For further product details, please see the official [NitroPC Pro 2](https://shop.nitrokey.com/shop/nitropc-pro-2-523) page.
diff --git a/user/hardware/certified-hardware/nitropc-pro.md b/user/hardware/certified-hardware/nitropc-pro.md
new file mode 100644
index 00000000..e05f34fd
--- /dev/null
+++ b/user/hardware/certified-hardware/nitropc-pro.md
@@ -0,0 +1,47 @@
+---
+lang: en
+layout: doc
+permalink: /doc/certified-hardware/nitropc-pro/
+title: NitroPC Pro
+image: /attachment/posts/nitropc-pro.jpg
+---
+
+<div class="alert alert-warning" role="alert">
+  <i class="fa fa-exclamation-circle"></i>
+  <b>Note:</b> When configuring your NitroPC Pro 2 on the Nitrokey website, there is an option for a discrete graphics card (e.g., Nvidia GeForce RTX 4070 or 4090) in addition to integrated graphics (e.g., Intel UHD 770, which is always included because it is physically built into the CPU). NitroPC Pro 2 configurations that include discrete graphics cards are <em>not</em> Qubes-certified. The only NitroPC Pro 2 configurations that are Qubes-certified are those that contain <em>only</em> integrated graphics.
+</div>
+
+<div class="alert alert-warning" role="alert">
+  <i class="fa fa-exclamation-circle"></i>
+  <b>Note:</b> Only the "Dasharo TianoCore UEFI without Measured Boot, without Nitrokey" firmware option is certified. The "HEADS with Measured Boot, requires Nitrokey!" firmware option is <em>not</em> certified.
+</div>
+
+The [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
+
+[![Photo of NitroPC Pro](/attachment/posts/nitropc-pro.jpg)](https://shop.nitrokey.com/shop/product/nitropc-pro-523)
+
+Here's a summary of the main component options available for this mid-tower desktop PC:
+
+| Component                    | Options                                                  |
+|----------------------------- | -------------------------------------------------------- |
+| Motherboard                  | MSI PRO Z690-A DDR5 (Wi-Fi optional)                     |
+| Processor                    | 12th Generation Intel Core i5-12600K or i9-12900K        |
+| Memory                       | 16 GB to 128 GB DDR5                                     |
+| NVMe storage (optional)      | Up to two NVMe PCIe 4.0 x4 SSDs, up to 2 TB each         |
+| SATA storage (optional)      | Up to two SATA SSDs, up to 7.68 TB each                  |
+| Wireless (optional)          | Wi-Fi 6E, 2400 Mbps, 802.11/a/b/g/n/ac/ax, Bluetooth 5.2 |
+| Operating system (optional)  | Qubes OS 4.1 or Ubuntu 22.04 LTS                         |
+
+Of special note for Qubes users, the NitroPC Pro features a combined PS/2 port that supports both a PS/2 keyboard and a PS/2 mouse simultaneously with a Y-cable (not included). This allows for full control of dom0 without the need for USB keyboard or mouse passthrough. Nitrokey also offers a special tamper-evident shipping method for an additional fee. With this option, the case screws will be individually sealed and photographed, and the NitroPC Pro will be packed inside a sealed bag. Photographs of the seals will be sent to you by email, which you can use to determine whether the case was opened during transit.
+
+The NitroPC Pro also comes with a "Dasharo Entry Subscription," which includes the following:
+
+- Accesses to the latest firmware releases
+- Exclusive newsletter
+- Special firmware updates, including early access to updates enhancing privacy, security, performance, and compatibility
+- Early access to new firmware releases for [newly-supported desktop platforms](https://docs.dasharo.com/variants/overview/#desktop) (please see the [roadmap](https://github.com/Dasharo/presentations/blob/main/dug2_dasharo_roadmap.md#dasharo-desktop-roadmap))
+- Access to the Dasharo Premier Support invite-only live chat channel on the Matrix network, allowing direct access to the Dasharo Team and fellow subscribers with personalized and priority assistance
+- Insider's view and influence on the Dasharo feature roadmap for a real impact on Dasharo development
+- [Dasharo Tools Suite Entry Subscription](https://docs.dasharo.com/osf-trivia-list/dts/#what-is-dasharo-tools-suite-supporters-entrance) keys
+
+For further product details, please see the official [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523) page.
diff --git a/user/hardware/certified-hardware/novacustom-nv41-series.md b/user/hardware/certified-hardware/novacustom-nv41-series.md
new file mode 100644
index 00000000..9592fcd5
--- /dev/null
+++ b/user/hardware/certified-hardware/novacustom-nv41-series.md
@@ -0,0 +1,42 @@
+---
+lang: en
+layout: doc
+permalink: /doc/certified-hardware/novacustom-nv41-series/
+title: NovaCustom NV41 Series
+image: /attachment/site/novacustom-nv41-series.png
+---
+
+The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
+
+[![Photo of the NovaCustom NV41 Series](/attachment/site/novacustom-nv41-series.png)](https://novacustom.com/product/nv41-series/)
+
+## Qubes-certified configurations
+
+The following configuration options are certified for Qubes OS Release 4:
+
+Processor:
+- Intel Core i5-1240P processor
+- Intel Core i7-1260P processor
+
+Memory:
+- 2 x 16 GB Kingston DDR4 SODIMM 3200 MHz (32 GB total)
+- 1 x 32 GB Kingston DDR4 SODIMM 3200 MHz (32 GB total)
+- 2 x 32 GB Kingston DDR4 SODIMM 3200 MHz (64 GB total)
+
+M.2 storage chip:
+- Samsung 980 SSD (all capacities)
+- Samsung 980 Pro SSD (all capacities)
+
+Wi-Fi and Bluetooth:
+- Intel AX-200/201 Wi-Fi module 2976 Mbps, 802.11ax/Wi-Fi 6 + Bluetooth 5.2
+- Killer (Intel) Wireless-AX 1675x M.2 Wi-Fi module 802.11ax/Wi-Fi 6E + Bluetooth 5.3
+- Blob-free: Qualcomm Atheros QCNFA222 Wi-Fi 802.11a/b/g/n + Bluetooth 4.0
+- No Wi-Fi/Bluetooth chip
+
+### Notes on Wi-Fi and Bluetooth options
+
+- When viewed in a Linux environment with `lspci`, the "Killer (Intel) Wireless-AX 1675x M.2 Wi-Fi module 802.11ax/Wi-Fi 6E + Bluetooth 5.3" device displays the model number "AX210." However, according to its [Intel Ark entry](https://ark.intel.com/content/www/us/en/ark/products/211485/intel-killer-wifi-6e-ax1675-xw.html) (in the "Product Brief" file), they are actually the same Wi-Fi module.
+
+- Similarly, when viewed in a Linux environment with `lspci`, the "Blob-free: Qualcomm Atheros QCNFA222 Wi-Fi 802.11a/b/g/n + Bluetooth 4.0" device displays the model number "AR9462," which seems to be just the Wi-Fi chip model number, whereas "QCNFA222" seems to be the model number of the whole device (which include Bluetooth). Meanwhile, the Bluetooth device presents itself as "IMC Networks Device 3487."
+
+- The term "blob-free" is used in different ways. In practice, being "blob-free" generally does *not* mean that the device does not use any closed-source firmware "blobs." Rather, it means that the device comes with firmware *preinstalled* so that it does not have to be loaded from the operating system. In theory, the preinstalled firmware could be open-source, but as far as we know, that is not the case with this particular Atheros Wi-Fi/Bluetooth module. (Qualcomm has published firmware source code in the past, but only for other device models, as far as we are aware.) Meanwhile, the Free Software Foundation (FSF) [considers](https://www.gnu.org/philosophy/free-hardware-designs.en.html#boundary) unmodifiable preinstalled firmware to be part of the hardware, hence they regard such hardware as "blob-free" from a software perspective. While common usage of the term "blob-free" often follows the FSF's interpretation, it is worthwhile for Qubes users who are concerned about closed-source firmware to understand the nuance.
diff --git a/user/hardware/certified-hardware/novacustom-v54-series.md b/user/hardware/certified-hardware/novacustom-v54-series.md
new file mode 100644
index 00000000..44db3f56
--- /dev/null
+++ b/user/hardware/certified-hardware/novacustom-v54-series.md
@@ -0,0 +1,69 @@
+---
+lang: en
+layout: doc
+permalink: /doc/certified-hardware/novacustom-v54-series/
+title: NovaCustom V54 Series
+image: /attachment/site/novacustom-v54-series.png
+---
+
+The [NovaCustom V54 Series 14.0 inch coreboot laptop](https://novacustom.com/product/v54-series/) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
+
+[![Photo of the NovaCustom V54 Series 14.0 inch coreboot laptop](/attachment/site/novacustom-v54-series.png)](https://novacustom.com/product/v54-series/)
+
+## Qubes-certified options
+
+The configuration options required for Qubes certification are detailed below.
+
+### Screen size
+
+- Certified: 14 inch
+
+**Note:** The 14-inch model (V540TU) and the 16-inch model (V560TU) are two separate products. [The 16-inch model is also certified.](/doc/certified-hardware/novacustom-v56-series/)
+
+### Screen resolution
+
+- Certified: Full HD+ (1920 x 1200)
+- Certified: 2.8K (2880 x 1800)
+
+### Processor and graphics
+
+- Certified: Intel Core Ultra 5 Processor 125H, Intel Arc iGPU with AI Boost
+- Certified: Intel Core Ultra 7 Processor 155H, Intel Arc iGPU with AI Boost
+- The Nvidia discrete GPU options are not currently certified.
+
+### Memory
+
+- Certified: Any configuration with at least 16 GB of memory
+
+### Storage
+
+- Certified: All of the available options in these sections
+
+### Personalization
+
+- This section is merely cosmetic and therefore does not affect certification.
+
+### Firmware options
+
+- Qubes OS does not currently support UEFI secure boot.
+- The option to be kept up to date with firmware updates is merely an email notification service and therefore does not affect certification.
+- The coreboot+Heads option is not currently certified. This option is a separate firmware variant. As such, it requires a separate certification process, which we expect to occur in the future.
+- Disabling Intel Management Engine (HAP disabling) does not affect certification.
+
+### Operating system
+
+- Certified: Qubes OS 4.2.4 or newer (within Release 4).
+- Releases older than 4.2.4 are not certified.
+- You may choose either to have NovaCustom preinstall Qubes OS for you, or you may choose to install Qubes OS yourself. This choice does not affect certification.
+
+### Wi-Fi and Bluetooth
+
+- Certified: Intel AX-210/211 (non vPro) Wi-Fi module 2.4 Gbps, 802.11AX/Wi-Fi6E + Bluetooth 5.3
+- Certified: Intel BE200 (non vPro) Wi-Fi module 5.8 Gbps, 802.11BE/Wi-Fi7 + Bluetooth 5.42
+- Certified: No Wi-Fi chip -- no Bluetooth and Wi-Fi connection possible (only with USB adapter)
+
+## Disclaimers
+
+- In order for Wi-Fi to function properly, `sys-net` must currently be based on a Fedora template. The firmware package in Debian templates is currently too old for the certified Wi-Fi cards.
+- Currently requires `kernel-latest`: If you install Qubes OS yourself, you must select the `Install Qubes OS RX using kernel-latest` option on the GRUB menu when booting the installer. This non-default kernel option is currently required for the NovaCustom V54 Series to function properly.
+- Due to a [known bug](https://github.com/Dasharo/dasharo-issues/issues/976), the bottom-right USB-C port is currently limited to USB 2.0 speeds.
diff --git a/user/hardware/certified-hardware/novacustom-v56-series.md b/user/hardware/certified-hardware/novacustom-v56-series.md
new file mode 100644
index 00000000..01eba16b
--- /dev/null
+++ b/user/hardware/certified-hardware/novacustom-v56-series.md
@@ -0,0 +1,69 @@
+---
+lang: en
+layout: doc
+permalink: /doc/certified-hardware/novacustom-v56-series/
+title: NovaCustom V56 Series
+image: /attachment/site/novacustom-v56-series.png
+---
+
+The [NovaCustom V56 Series 16.0 inch coreboot laptop](https://novacustom.com/product/v56-series/) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
+
+[![Photo of the NovaCustom V56 Series 16.0 inch coreboot laptop](/attachment/site/novacustom-v56-series.png)](https://novacustom.com/product/v56-series/)
+
+## Qubes-certified options
+
+The configuration options required for Qubes certification are detailed below.
+
+### Screen size
+
+- Certified: 16 inch
+
+**Note:** The 16-inch model (V560TU) and the 14-inch model (V540TU) are two separate products. [The 14-inch model is also certified.](/doc/certified-hardware/novacustom-v54-series/)
+
+### Screen resolution
+
+- Certified: Full HD+ (1920 x 1200)
+- Certified: Q-HD+ (2560 x 1600)
+
+### Processor and graphics
+
+- Certified: Intel Core Ultra 5 Processor 125H + Intel Arc iGPU with AI Boost
+- Certified: Intel Core Ultra 7 Processor 155H + Intel Arc iGPU with AI Boost
+- The Nvidia discrete GPU options are not currently certified.
+
+### Memory
+
+- Certified: Any configuration with at least 16 GB of memory
+
+### Storage
+
+- Certified: Any of the available options in this section
+
+### Personalization
+
+- This section is merely cosmetic and therefore does not affect certification.
+
+### Firmware options
+
+- Qubes OS does not currently support UEFI secure boot.
+- Keeping up-to-date with firmware updates is merely an email notification service and therefore does not affect certification.
+- The coreboot+Heads option is not currently certified. This option is a separate firmware variant. As such, it requires a separate certification process, which we expect to occur in the future.
+- Disabling Intel Management Engine (HAP disabling) does not affect certification.
+
+### Operating system
+
+- Certified: Qubes OS 4.2.3 or newer (within Release 4).
+- Releases older than 4.2.3 are not certified.
+- You may choose either to have NovaCustom preinstall Qubes OS for you, or you may choose to install Qubes OS yourself. This choice does not affect certification.
+
+### Wi-Fi and Bluetooth
+
+- Certified: Intel AX-210/211 (non vPro) Wi-Fi module 2.4 Gbps, 802.11AX/Wi-Fi6E + Bluetooth 5.3
+- Certified: Intel BE200 (non vPro) Wi-Fi module 5.8 Gbps, 802.11BE/Wi-Fi7 + Bluetooth 5.42
+- Certified: No Wi-Fi chip - no Bluetooth and Wi-Fi connection possible (only with USB adapter)
+
+## Disclaimers
+
+- In order for Wi-Fi to function properly, `sys-net` must currently be based on a Fedora template. The firmware package in Debian templates is currently too old for the certified Wi-Fi cards.
+- Currently requires `kernel-latest`: If you install Qubes OS yourself, you must select the `Install Qubes OS RX using kernel-latest` option on the GRUB menu when booting the installer. This non-default kernel option is currently required for the NovaCustom V56 Series to function properly.
+- Due to a [known bug](https://github.com/Dasharo/dasharo-issues/issues/976), the bottom-right USB-C port is currently limited to USB 2.0 speeds.
diff --git a/user/hardware/certified-hardware/starlabs-starbook.md b/user/hardware/certified-hardware/starlabs-starbook.md
new file mode 100644
index 00000000..2fb27477
--- /dev/null
+++ b/user/hardware/certified-hardware/starlabs-starbook.md
@@ -0,0 +1,35 @@
+---
+lang: en
+layout: doc
+permalink: /doc/certified-hardware/starlabs-starbook/
+title: Star Labs StarBook
+image: /attachment/site/starlabs-starbook.png
+---
+
+The [Star Labs StarBook](https://starlabs.systems/pages/starbook) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
+
+The [Star Labs StarBook](https://starlabs.systems/pages/starbook) is a 14-inch laptop featuring open-source coreboot and EDK II firmware. 
+
+[![Photo of Star Labs StarBook](/attachment/site/starlabs-starbook.png)](https://starlabs.systems/pages/starbook)
+
+The Qubes developers have tested and certified the following StarBook configuration options for Qubes OS Release 4:
+
+| Component        | Qubes-certified options                          |
+| ---------------- | ------------------------------------------------ |
+| Processor        | 13th Generation Intel Core i3-1315U or i7-1360P  |
+| Memory           | 8 GB, 16 GB, 32 GB, or 64 GB RAM                 |
+| Storage          | 512 GB, 1 TB, or 2 TB SSD                        |
+| Graphics         | Intel (integrated graphics)                      |
+| Networking       | Intel Wi-Fi 6 AX210 (no built-in wired Ethernet) |
+| Firmware         | coreboot 8.97 (2023-10-03)                       |
+| Operating system | Qubes OS (pre-installation optional)             |
+
+[![Photo of Star Labs StarBook](/attachment/posts/starlabs-starbook_top.png)](https://starlabs.systems/pages/starbook)
+
+The StarBook features a true matte 14-inch IPS display at 1920x1080 full HD resolution with 400cd/m² of brightness, 178° viewing angles, and a 180° hinge. The backlit keyboard is available in US English, UK English, French, German, Nordic, and Spanish layouts.
+
+[![Photo of Star Labs StarBook](/attachment/posts/starlabs-starbook_side.png)](https://starlabs.systems/pages/starbook)
+
+The StarBook includes four USB ports (1x USB-C with Thunderbolt 4, 2x USB 3.0, and 1x USB 2.0), one HDMI port, a microSD slot, an audio input/output combo jack, and a DC jack for charging. For more information, see the official [Star Labs StarBook](https://starlabs.systems/pages/starbook) page.
+
+[![Photo of Star Labs StarBook](/attachment/posts/starlabs-starbook_back.png)](https://starlabs.systems/pages/starbook)

From e86436d0234228b5dce32b9d35f12045eb634494 Mon Sep 17 00:00:00 2001
From: Francis King <francis.king@burohappold.com>
Date: Mon, 24 Mar 2025 16:08:35 +0000
Subject: [PATCH 282/332] Added  some extra text and an example

In a discussion on Qubes OS forum, it was decided that I should add some extra text about the netmask, and an example  for Network Manager. The purpose being to make the procedure much clearer.

There are two images to go into the text, but I don't understand how to do that yet. I have used '>' at those points. Please advise.

Francis.
---
 user/advanced-topics/standalones-and-hvms.md | 29 +++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/user/advanced-topics/standalones-and-hvms.md b/user/advanced-topics/standalones-and-hvms.md
index 198dab42..6c344b47 100644
--- a/user/advanced-topics/standalones-and-hvms.md
+++ b/user/advanced-topics/standalones-and-hvms.md
@@ -175,11 +175,38 @@ seen, e.g., in the Qube Manager in the qube's properties:
 ![r4.0-manager-networking-config.png](/attachment/doc/r4.0-manager-networking-config.png)
 
 Alternatively, one can use the `qvm-ls -n` command to obtain the same
-information (IP/netmask/gateway).
+information (IP/netmask/gateway). The netmask required is that for your own network, 
+so for example, if your IPv4 network has a subnet mask of /24 then the actual netmask to 
+use is 255.255.255.0 - even if the Qube Manager suggests 255.255.255.255  
 
 The DNS IP addresses are `10.139.1.1` and `10.139.1.2`. There is [opt-in
 support](/doc/networking/#ipv6) for IPv6 forwarding.
 
+### An example of setting up a network - Network Manager on KDE
+
+Every guest operating system has its own way of handling networking, and the user is 
+referred to the documentation that comes with that operating system. However, 
+Network Manager is widely used on Linux systems, and so hopefully a worked example will 
+prove useful. The worked example is for a HVM running EndeavourOS. 
+
+> Image of Qubes Manager - is this what it's called??
+
+In this example, Network Manager on KDE, the network had the following values:
+
+1. IPv4 networking
+2. IP address 10.137.0.17
+3. Netmask 255.255.255.255 (but in the network the netmask is actually 255.255.255.0)
+4. Gateway 10.138.24.248
+5. Virtual DNS 10.139.1.1 and 10.139.1.2
+
+> Image of Network Manager, annotated by numbers for reference below
+
+The network was set up by entering Network Manager, tab Wi-Fi & Networking, clicking on the Wired Ethernet
+item, and selecting tab IPv4 (1). The Manual method is selected (2), which reveals areas for data entry. The DNS 
+Servers takes a comma-separated list, here 10.139.1.1,10.1.139.2 (3). At the bottom of the tab (4), click on '+ Add', 
+and enter the IP address of 10.137.0.17 under column 'Address', the Netmask of 25.255.255.0  (to match the network) 
+under column 'Netmask', and the Gateway of 10.138.24.248 under column 'Gateway'. Apply these changes.
+
 ## Using template-based HVMs
 
 Qubes allows HVMs to share a common root filesystem from a select template.

From 1a049515a7601b8d67a29688dce8462fcc774c4c Mon Sep 17 00:00:00 2001
From: Marnix Croes <93143998+MarnixCroes@users.noreply.github.com>
Date: Tue, 25 Mar 2025 12:02:45 -0300
Subject: [PATCH 283/332] add more info about refreshing qubes after restore

---
 user/how-to-guides/how-to-back-up-restore-and-migrate.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/user/how-to-guides/how-to-back-up-restore-and-migrate.md b/user/how-to-guides/how-to-back-up-restore-and-migrate.md
index fe46354d..625f9f20 100644
--- a/user/how-to-guides/how-to-back-up-restore-and-migrate.md
+++ b/user/how-to-guides/how-to-back-up-restore-and-migrate.md
@@ -163,6 +163,9 @@ backup. Once the progress bar has completed, you may click **Finish**.
 In case that applications are not shown, i.e. "No applications found", open the
 settings of the qube -> select `Applications` -> click `Refresh applications`.
 
+When a restored application qube refreshes, the application lists will open the template qubes on which it is based. In that case the template qube should also be restored, if it is missing the default qube will be assigned.
+The updated list of the installed software can be seen on the left and adjusted accordingly to the users needs.
+
 **Note:** When restoring from a dom0 backup, a new directory will be created in
 the current dom0 home directory, and the contents from the backup will be
 placed inside this new directory. This is intentional, as it allows users to

From 8a23c91c601dac0c1a882813592e450690d0c63a Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Tue, 25 Mar 2025 19:09:36 -0400
Subject: [PATCH 284/332] grammar fix

---
 user/how-to-guides/how-to-back-up-restore-and-migrate.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/how-to-guides/how-to-back-up-restore-and-migrate.md b/user/how-to-guides/how-to-back-up-restore-and-migrate.md
index 625f9f20..4e8ab787 100644
--- a/user/how-to-guides/how-to-back-up-restore-and-migrate.md
+++ b/user/how-to-guides/how-to-back-up-restore-and-migrate.md
@@ -164,7 +164,7 @@ In case that applications are not shown, i.e. "No applications found", open the
 settings of the qube -> select `Applications` -> click `Refresh applications`.
 
 When a restored application qube refreshes, the application lists will open the template qubes on which it is based. In that case the template qube should also be restored, if it is missing the default qube will be assigned.
-The updated list of the installed software can be seen on the left and adjusted accordingly to the users needs.
+The updated list of the installed software can be seen on the left and adjusted accordingly to the user's needs.
 
 **Note:** When restoring from a dom0 backup, a new directory will be created in
 the current dom0 home directory, and the contents from the backup will be

From 66c0baff531c2e757df9d0b17bcd6acdcbc5b353 Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Wed, 26 Mar 2025 17:20:33 -0400
Subject: [PATCH 285/332] minor formatting & url fix

---
 user/advanced-topics/secondary-storage.md    | 4 ++--
 user/advanced-topics/standalones-and-hvms.md | 8 +++-----
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/user/advanced-topics/secondary-storage.md b/user/advanced-topics/secondary-storage.md
index 24d97e2c..05b88a7b 100644
--- a/user/advanced-topics/secondary-storage.md
+++ b/user/advanced-topics/secondary-storage.md
@@ -62,7 +62,7 @@ In theory, you can still use file-based disk images ("file" pool driver), but it
 
 ### Example HDD setup
 
-Assuming the secondary hard disk is at /dev/sdb (it will be completely erased), you can set it up for encryption by doing in a dom0 terminal (use the same passphrase as the main Qubes disk to avoid a second password prompt at boot):
+Assuming the secondary hard disk is at `/dev/sdb` (it will be completely erased), you can set it up for encryption by doing in a dom0 terminal (use the same passphrase as the main Qubes disk to avoid a second password prompt at boot):
 
 ```
 sudo cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sdb
@@ -81,7 +81,7 @@ And adding this line (change both "b209..." for your device's UUID from blkid) t
 luks-b20975aa-8318-433d-8508-6c23982c6cde UUID=b20975aa-8318-433d-8508-6c23982c6cde none
 ```
 
-Reboot the computer so the new luks device appears at /dev/mapper/luks-b209... and we can then create its pool, by doing this on a dom0 terminal (substitute the b209... UUIDs with yours):
+Reboot the computer so the new luks device appears at `/dev/mapper/luks-b209...` and we can then create its pool, by doing this on a dom0 terminal (substitute the "b209..." UUIDs with yours):
 
 First create the physical volume
 
diff --git a/user/advanced-topics/standalones-and-hvms.md b/user/advanced-topics/standalones-and-hvms.md
index 35c4f9cf..f8c575b0 100644
--- a/user/advanced-topics/standalones-and-hvms.md
+++ b/user/advanced-topics/standalones-and-hvms.md
@@ -202,7 +202,7 @@ as is, then any HVMs based on it will effectively be disposables. All file
 system changes will be wiped when the HVM is shut down.
 
 Please see [this
-page](https://github.com/Qubes-Community/Contents/blob/master/docs/os/windows/windows-tools.md)
+page](/doc/templates/windows/windows-qubes-4-1/#windows-as-a-template)
 for specific advice on installing and using Windows-based templates.
 
 ## Cloning HVMs
@@ -366,9 +366,7 @@ device again. This is illustrated in the screenshot below:
 
 You can convert any VirtualBox VM to a Qubes HVM using this method.
 
-For example, Microsoft provides [free 90-day evaluation VirtualBox VMs for
-browser
-testing](https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/).
+For example, Microsoft provides [virtual machines containing an evaluation version of Windows](https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/).
 
 About 60 GB of disk space is required for conversion. Use an external hard
 drive if needed. The final `root.img` size is 40 GB.
@@ -447,5 +445,5 @@ qemu-img -h | tail -n1
 
 Other documents related to HVMs:
 
-- [Windows VMs](https://github.com/Qubes-Community/Contents/blob/master/docs/os/windows/windows-vm.md)
+- [Windows VMs](https://forum.qubes-os.org/search?q=windows%20hvm%20%23guides)
 - [Linux HVM Tips](https://forum.qubes-os.org/t/19008)

From 67e3ffccc719946d2dfe61bdcef2d7f878b15f3f Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Wed, 26 Mar 2025 17:25:49 -0400
Subject: [PATCH 286/332] add ref to metadata to be consistent across
 documentation though soon obsolete

---
 user/hardware/certified-hardware/dasharo-fidelisguard-z690.md | 1 +
 user/hardware/certified-hardware/insurgo-privacybeast-x230.md | 1 +
 user/hardware/certified-hardware/nitropad-t430.md             | 1 +
 user/hardware/certified-hardware/nitropad-v56.md              | 1 +
 user/hardware/certified-hardware/nitropad-x230.md             | 1 +
 user/hardware/certified-hardware/nitropc-pro-2.md             | 1 +
 user/hardware/certified-hardware/nitropc-pro.md               | 1 +
 user/hardware/certified-hardware/novacustom-nv41-series.md    | 1 +
 user/hardware/certified-hardware/novacustom-v54-series.md     | 1 +
 user/hardware/certified-hardware/novacustom-v56-series.md     | 1 +
 user/hardware/certified-hardware/starlabs-starbook.md         | 1 +
 11 files changed, 11 insertions(+)

diff --git a/user/hardware/certified-hardware/dasharo-fidelisguard-z690.md b/user/hardware/certified-hardware/dasharo-fidelisguard-z690.md
index 88a10507..16c4a9d5 100644
--- a/user/hardware/certified-hardware/dasharo-fidelisguard-z690.md
+++ b/user/hardware/certified-hardware/dasharo-fidelisguard-z690.md
@@ -4,6 +4,7 @@ layout: doc
 permalink: /doc/certified-hardware/dasharo-fidelisguard-z690/
 title: Dasharo FidelisGuard Z690
 image: /attachment/posts/dasharo-fidelisguard-z690_2.jpg
+ref: 350
 ---
 
 The [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
diff --git a/user/hardware/certified-hardware/insurgo-privacybeast-x230.md b/user/hardware/certified-hardware/insurgo-privacybeast-x230.md
index 0e1a0f67..72044458 100644
--- a/user/hardware/certified-hardware/insurgo-privacybeast-x230.md
+++ b/user/hardware/certified-hardware/insurgo-privacybeast-x230.md
@@ -4,6 +4,7 @@ layout: doc
 permalink: /doc/certified-hardware/insurgo-privacybeast-x230/
 title: Insurgo PrivacyBeast X230
 image: /attachment/site/insurgo-privacybeast-x230.png
+ref: 351
 ---
 
 <div class="alert alert-danger" role="alert">
diff --git a/user/hardware/certified-hardware/nitropad-t430.md b/user/hardware/certified-hardware/nitropad-t430.md
index 54b5ed38..bf80ff8c 100644
--- a/user/hardware/certified-hardware/nitropad-t430.md
+++ b/user/hardware/certified-hardware/nitropad-t430.md
@@ -4,6 +4,7 @@ layout: doc
 permalink: /doc/certified-hardware/nitropad-t430/
 title: NitroPad T430
 image: /attachment/site/nitropad-t430.jpg
+ref: 352
 ---
 
 <div class="alert alert-danger" role="alert">
diff --git a/user/hardware/certified-hardware/nitropad-v56.md b/user/hardware/certified-hardware/nitropad-v56.md
index 262a7df7..13fbccd2 100644
--- a/user/hardware/certified-hardware/nitropad-v56.md
+++ b/user/hardware/certified-hardware/nitropad-v56.md
@@ -4,6 +4,7 @@ layout: doc
 permalink: /doc/certified-hardware/nitropad-v56/
 title: NitroPad V56
 image: /attachment/site/nitropad-v56.png
+ref: 353
 ---
 
 The [NitroPad V56](https://shop.nitrokey.com/shop/nitropad-v56-684) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
diff --git a/user/hardware/certified-hardware/nitropad-x230.md b/user/hardware/certified-hardware/nitropad-x230.md
index 01db07f8..09e45872 100644
--- a/user/hardware/certified-hardware/nitropad-x230.md
+++ b/user/hardware/certified-hardware/nitropad-x230.md
@@ -4,6 +4,7 @@ layout: doc
 permalink: /doc/certified-hardware/nitropad-x230/
 title: NitroPad X230
 image: /attachment/site/nitropad-x230.jpg
+ref: 354
 ---
 
 <div class="alert alert-danger" role="alert">
diff --git a/user/hardware/certified-hardware/nitropc-pro-2.md b/user/hardware/certified-hardware/nitropc-pro-2.md
index 5ee72bb4..a1572692 100644
--- a/user/hardware/certified-hardware/nitropc-pro-2.md
+++ b/user/hardware/certified-hardware/nitropc-pro-2.md
@@ -4,6 +4,7 @@ layout: doc
 permalink: /doc/certified-hardware/nitropc-pro-2/
 title: NitroPC Pro 2
 image: /attachment/posts/nitropc-pro.jpg
+ref: 355
 ---
 
 <div class="alert alert-warning" role="alert">
diff --git a/user/hardware/certified-hardware/nitropc-pro.md b/user/hardware/certified-hardware/nitropc-pro.md
index e05f34fd..91abff8b 100644
--- a/user/hardware/certified-hardware/nitropc-pro.md
+++ b/user/hardware/certified-hardware/nitropc-pro.md
@@ -4,6 +4,7 @@ layout: doc
 permalink: /doc/certified-hardware/nitropc-pro/
 title: NitroPC Pro
 image: /attachment/posts/nitropc-pro.jpg
+ref: 356
 ---
 
 <div class="alert alert-warning" role="alert">
diff --git a/user/hardware/certified-hardware/novacustom-nv41-series.md b/user/hardware/certified-hardware/novacustom-nv41-series.md
index 9592fcd5..ca7b6745 100644
--- a/user/hardware/certified-hardware/novacustom-nv41-series.md
+++ b/user/hardware/certified-hardware/novacustom-nv41-series.md
@@ -4,6 +4,7 @@ layout: doc
 permalink: /doc/certified-hardware/novacustom-nv41-series/
 title: NovaCustom NV41 Series
 image: /attachment/site/novacustom-nv41-series.png
+ref: 357
 ---
 
 The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
diff --git a/user/hardware/certified-hardware/novacustom-v54-series.md b/user/hardware/certified-hardware/novacustom-v54-series.md
index 44db3f56..f4fac073 100644
--- a/user/hardware/certified-hardware/novacustom-v54-series.md
+++ b/user/hardware/certified-hardware/novacustom-v54-series.md
@@ -4,6 +4,7 @@ layout: doc
 permalink: /doc/certified-hardware/novacustom-v54-series/
 title: NovaCustom V54 Series
 image: /attachment/site/novacustom-v54-series.png
+ref: 358
 ---
 
 The [NovaCustom V54 Series 14.0 inch coreboot laptop](https://novacustom.com/product/v54-series/) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
diff --git a/user/hardware/certified-hardware/novacustom-v56-series.md b/user/hardware/certified-hardware/novacustom-v56-series.md
index 01eba16b..e5e5867e 100644
--- a/user/hardware/certified-hardware/novacustom-v56-series.md
+++ b/user/hardware/certified-hardware/novacustom-v56-series.md
@@ -4,6 +4,7 @@ layout: doc
 permalink: /doc/certified-hardware/novacustom-v56-series/
 title: NovaCustom V56 Series
 image: /attachment/site/novacustom-v56-series.png
+ref: 359
 ---
 
 The [NovaCustom V56 Series 16.0 inch coreboot laptop](https://novacustom.com/product/v56-series/) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
diff --git a/user/hardware/certified-hardware/starlabs-starbook.md b/user/hardware/certified-hardware/starlabs-starbook.md
index 2fb27477..3a00ca57 100644
--- a/user/hardware/certified-hardware/starlabs-starbook.md
+++ b/user/hardware/certified-hardware/starlabs-starbook.md
@@ -4,6 +4,7 @@ layout: doc
 permalink: /doc/certified-hardware/starlabs-starbook/
 title: Star Labs StarBook
 image: /attachment/site/starlabs-starbook.png
+ref: 360
 ---
 
 The [Star Labs StarBook](https://starlabs.systems/pages/starbook) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.

From 951baf6ea68a4fa439a7d174fc0cbc0a099dbf4b Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Mon, 31 Mar 2025 02:59:41 -0400
Subject: [PATCH 287/332] minor rewording, formatting

---
 user/advanced-topics/managing-vm-kernels.md            | 10 +++++-----
 .../debian-and-whonix-update-troubleshooting.md        |  6 +++---
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/user/advanced-topics/managing-vm-kernels.md b/user/advanced-topics/managing-vm-kernels.md
index bf0745ec..729bd108 100644
--- a/user/advanced-topics/managing-vm-kernels.md
+++ b/user/advanced-topics/managing-vm-kernels.md
@@ -60,7 +60,7 @@ nopat
 
 ## Installing different kernel using Qubes kernel package
 
-VM kernels are packages by Qubes team in `kernel-qubes-vm` packages.
+VM kernels are packaged by the Qubes team in the `kernel-qubes-vm` packages.
 Generally, the system will keep the three newest available versions.
 You can list them with the `rpm` command:
 
@@ -152,7 +152,7 @@ The newly installed package is set as the default VM kernel.
 ## Installing different VM kernel based on dom0 kernel
 
 It is possible to package a kernel installed in dom0 as a VM kernel.
-This makes it possible to use a VM kernel which is not packaged by Qubes team.
+This makes it possible to use a VM kernel which is not packaged by the Qubes team.
 This includes:
 
  * using a Fedora kernel package
@@ -298,7 +298,7 @@ Install distribution kernel image, kernel headers and the grub.
 sudo apt install linux-image-amd64 linux-headers-amd64 grub2 qubes-kernel-vm-support
 ~~~
 
-If you are doing that on a qube based on "Debian Minimal" template, a grub gui will popup during the installation, asking you where you want to install the grub loader. You must select /dev/xvda (check the box using the space bar, and validate your choice with "Enter".) If this popup does not appear during the installation, you must manually setup `grub2` by running:
+If you are doing that on a qube based on "Debian Minimal" template, a grub gui will popup during the installation, asking you where you want to install the grub loader. You must select `/dev/xvda` (check the box using the space bar, and validate your choice with "Enter".) If this popup does not appear during the installation, you must manually setup `grub2` by running:
 
 ~~~
 sudo grub-install /dev/xvda
@@ -315,8 +315,8 @@ Go to dom0 -> Qubes VM Manger -> right click on the VM -> Qube settings -> Advan
 
 Depends on `Virtualization` mode setting:
 
-* `Virtualization` mode `PV`: Possible, however use of `Virtualization` mode `PV` mode is discouraged for security purposes.
-  * If you require `Virtualization` mode `PV` mode, install `grub2-xen-pvh` in dom0. This can be done by running command `sudo qubes-dom0-update pvgrub2-pvh` in dom0.
+* `Virtualization` mode `PV`: Possible, however use of `Virtualization` mode `PV` is discouraged for security purposes.
+  * If you require `Virtualization` mode `PV`, install `grub2-xen-pvh` in dom0. This can be done by running command `sudo qubes-dom0-update pvgrub2-pvh` in dom0.
 * `Virtualization` mode `PVH`: Possible. Install `grub2-xen-pvh` in dom0.
 * `Virtualization` mode `HVM`: Possible.
 
diff --git a/user/troubleshooting/debian-and-whonix-update-troubleshooting.md b/user/troubleshooting/debian-and-whonix-update-troubleshooting.md
index 06afbca3..36cde215 100644
--- a/user/troubleshooting/debian-and-whonix-update-troubleshooting.md
+++ b/user/troubleshooting/debian-and-whonix-update-troubleshooting.md
@@ -95,11 +95,11 @@ W: A error occurred during the signature verification. The repository is not upd
 
 Even though, `apt-get` will automatically ignore repositories with expired keys or signatures, you will not receive upgrades from that repository. Unless the issue is already known/documented, it should be reported so it can be further investigated.
 
-There are two possible reasons why this could happen, either there is an issue with the repository that the maintainers have to fix, or you are victim of a [Man-in-the-middle_attacks](https://www.whonix.org/wiki/Warning#Man-in-the-middle_attacks). The latter would not be a big issue and might go away after a while automatically or try to [change your Tor circuit](https://www.whonix.org/wiki/Arm#Arm)
+There are two possible reasons why this could happen, either there is an issue with the repository that the maintainers have to fix, or you are victim of a [Man-in-the-middle_attacks](https://www.whonix.org/wiki/Warning#Man-in-the-middle_attacks). The latter would not be a big issue and might go away after a while automatically or try to [change your Tor circuit](https://www.whonix.org/wiki/Arm#Arm).
 
-In past various apt repositories were signed with expired key. If you want to see how the documentation looked at that point, please click on expand on the right.
+In past various apt repositories were signed with expired key: [The Tor Project's apt repository key was expired](https://trac.torproject.org/projects/tor/ticket/12994).
 
-[The Tor Project's apt repository key was expired](https://trac.torproject.org/projects/tor/ticket/12994). You saw the following warning.
+You saw the following warning:
 
 ~~~
 W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://deb.torproject.org stable Release: The following signatures were invalid: KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681

From e529345e72d4732daac512abb470950e38e680e1 Mon Sep 17 00:00:00 2001
From: garindean <31627216+garindean@users.noreply.github.com>
Date: Wed, 2 Apr 2025 01:10:15 -0400
Subject: [PATCH 288/332] Update how-to-organize-your-qubes.md

grammar
---
 user/how-to-guides/how-to-organize-your-qubes.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/how-to-guides/how-to-organize-your-qubes.md b/user/how-to-guides/how-to-organize-your-qubes.md
index 677a3b1b..947312b9 100644
--- a/user/how-to-guides/how-to-organize-your-qubes.md
+++ b/user/how-to-guides/how-to-organize-your-qubes.md
@@ -89,7 +89,7 @@ the other. Alice's setup looks like this:
   [bind-dirs](/doc/bind-dirs/) to make those changes persistent, but sometimes
   she doesn't want to get bogged down doing with all that and figures it
   wouldn't be worth it just for this one qube. She's secretly glad that Qubes
-  OS doesn't judge her this and just gives her the freedom to do things however
+  OS doesn't judge her for this and just gives her the freedom to do things however
   she likes while keeping everything securely compartmentalized. At times like
   these, she takes comfort in knowing that things can be messy and disorganized
   *within* a qube while her overall digital life remains well-organized.

From c4129f8852ed279b73ba76ea8d122570c9f17d94 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Wed, 9 Apr 2025 15:02:04 -0700
Subject: [PATCH 289/332] Fix dead links

---
 .../certified-hardware/certified-hardware.md  | 26 +++++++++----------
 .../dasharo-fidelisguard-z690.md              | 12 ++++-----
 2 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/user/hardware/certified-hardware/certified-hardware.md b/user/hardware/certified-hardware/certified-hardware.md
index a98835a8..3067080b 100644
--- a/user/hardware/certified-hardware/certified-hardware.md
+++ b/user/hardware/certified-hardware/certified-hardware.md
@@ -25,19 +25,19 @@ Qubes-certified computers are certified for a [major release](/doc/version-schem
 
 The current Qubes-certified models are listed below in reverse chronological order of certification.
 
-| Brand                                  | Model                                                                                                                  | Certification details                                                       |
-| -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
-| [NovaCustom](https://novacustom.com/)  | [V54 Series](https://novacustom.com/product/v54-series/)                                                               | [Certification details](/doc/certified-hardware/novacustom-v54-series/)     |
-| [Nitrokey](https://www.nitrokey.com/)  | [NitroPad V56](https://shop.nitrokey.com/shop/nitropad-v56-684)                                                        | [Certification details](/doc/certified-hardware/nitropad-v56/)              |
-| [NovaCustom](https://novacustom.com/)  | [V56 Series](https://novacustom.com/product/v56-series/)                                                               | [Certification details](/doc/certified-hardware/novacustom-v56-series/)     |
-| [Nitrokey](https://www.nitrokey.com/)  | [NitroPC Pro 2](https://shop.nitrokey.com/shop/nitropc-pro-2-523)                                                      | [Certification details](/doc/certified-hardware/nitropc-pro-2/)             |
-| [Star Labs](https://starlabs.systems/) | [StarBook](https://starlabs.systems/pages/starbook)                                                                    | [Certification details](/doc/certified-hardware/starlabs-starbook/)         |
-| [Nitrokey](https://www.nitrokey.com/)  | [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523)                                                  | [Certification details](/doc/certified-hardware/nitropc-pro/)               |
-| [NovaCustom](https://novacustom.com/)  | [NV41 Series](https://novacustom.com/product/nv41-series/)                                                             | [Certification details](/doc/certified-hardware/novacustom-nv41-series/)    |
-| [3mdeb](https://3mdeb.com/)            | [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) | [Certification details](/doc/certified-hardware/dasharo-fidelisguard-z690/) |
-| [Nitrokey](https://www.nitrokey.com/)  | [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119)                                              | [Certification details](/doc/certified-hardware/nitropad-t430/)             |
-| [Nitrokey](https://www.nitrokey.com/)  | [NitroPad X230](https://shop.nitrokey.com/shop/product/nitropad-x230-67)                                               | [Certification details](/doc/certified-hardware/nitropad-x230/)             |
-| [Insurgo](https://insurgo.ca/)         | [PrivacyBeast X230](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/)         | [Certification details](/doc/certified-hardware/insurgo-privacybeast-x230/) |
+| Brand                                  | Model                                                                                                                                                                  | Certification details                                                       |
+| -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
+| [NovaCustom](https://novacustom.com/)  | [V54 Series](https://novacustom.com/product/v54-series/)                                                                                                               | [Certification details](/doc/certified-hardware/novacustom-v54-series/)     |
+| [Nitrokey](https://www.nitrokey.com/)  | [NitroPad V56](https://shop.nitrokey.com/shop/nitropad-v56-684)                                                                                                        | [Certification details](/doc/certified-hardware/nitropad-v56/)              |
+| [NovaCustom](https://novacustom.com/)  | [V56 Series](https://novacustom.com/product/v56-series/)                                                                                                               | [Certification details](/doc/certified-hardware/novacustom-v56-series/)     |
+| [Nitrokey](https://www.nitrokey.com/)  | [NitroPC Pro 2](https://shop.nitrokey.com/shop/nitropc-pro-2-523)                                                                                                      | [Certification details](/doc/certified-hardware/nitropc-pro-2/)             |
+| [Star Labs](https://starlabs.systems/) | [StarBook](https://starlabs.systems/pages/starbook)                                                                                                                    | [Certification details](/doc/certified-hardware/starlabs-starbook/)         |
+| [Nitrokey](https://www.nitrokey.com/)  | [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523)                                                                                                  | [Certification details](/doc/certified-hardware/nitropc-pro/)               |
+| [NovaCustom](https://novacustom.com/)  | [NV41 Series](https://novacustom.com/product/nv41-series/)                                                                                                             | [Certification details](/doc/certified-hardware/novacustom-nv41-series/)    |
+| [3mdeb](https://3mdeb.com/)            | [Dasharo FidelisGuard Z690](https://web.archive.org/web/20240917145232/https://shop.3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) | [Certification details](/doc/certified-hardware/dasharo-fidelisguard-z690/) |
+| [Nitrokey](https://www.nitrokey.com/)  | [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119)                                                                                              | [Certification details](/doc/certified-hardware/nitropad-t430/)             |
+| [Nitrokey](https://www.nitrokey.com/)  | [NitroPad X230](https://shop.nitrokey.com/shop/product/nitropad-x230-67)                                                                                               | [Certification details](/doc/certified-hardware/nitropad-x230/)             |
+| [Insurgo](https://insurgo.ca/)         | [PrivacyBeast X230](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/)                                                         | [Certification details](/doc/certified-hardware/insurgo-privacybeast-x230/) |
 
 ## Become hardware certified
 
diff --git a/user/hardware/certified-hardware/dasharo-fidelisguard-z690.md b/user/hardware/certified-hardware/dasharo-fidelisguard-z690.md
index 88a10507..6c85d154 100644
--- a/user/hardware/certified-hardware/dasharo-fidelisguard-z690.md
+++ b/user/hardware/certified-hardware/dasharo-fidelisguard-z690.md
@@ -6,11 +6,11 @@ title: Dasharo FidelisGuard Z690
 image: /attachment/posts/dasharo-fidelisguard-z690_2.jpg
 ---
 
-The [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
+The [Dasharo FidelisGuard Z690](https://web.archive.org/web/20240917145232/https://shop.3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
 
 [![Photo of MSI PRO Z690-A DDR4 motherboard](/attachment/posts/dasharo-fidelisguard-z690_1.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
 
-The [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is a full desktop PC build that brings the [Dasharo](https://dasharo.com/) open-source firmware distribution to the MSI PRO Z690-A DDR4 motherboard with Qubes OS preinstalled. The full configuration includes:
+The [Dasharo FidelisGuard Z690](https://web.archive.org/web/20240917145232/https://shop.3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is a full desktop PC build that brings the [Dasharo](https://dasharo.com/) open-source firmware distribution to the MSI PRO Z690-A DDR4 motherboard with Qubes OS preinstalled. The full configuration includes:
 
 | Part         | Model Name                                                     |
 |------------- | -------------------------------------------------------------- |
@@ -21,7 +21,7 @@ The [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dash
 | Storage      | SSD Intel 670p 512 GB M.2 2280 PCI-E x4 Gen3 NVMe              |
 | Enclosure	   | SilentiumPC Armis AR1                                          |
 
-[![Photo of Dasharo FidelisGuard Z690 with open case](/attachment/posts/dasharo-fidelisguard-z690_2.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
+[![Photo of Dasharo FidelisGuard Z690 with open case](/attachment/posts/dasharo-fidelisguard-z690_2.jpg)](https://web.archive.org/web/20240917145232/https://shop.3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
 
 This computer comes with a "Dasharo Supporters Entrance Subscription," which includes the following:
 
@@ -31,8 +31,8 @@ This computer comes with a "Dasharo Supporters Entrance Subscription," which inc
 - Dasharo Premier Support through an invite-only Matrix channel
 - Influence on the Dasharo feature roadmap
 
-[![Photo of Dasharo FidelisGuard Z690 with open case](/attachment/posts/dasharo-fidelisguard-z690_3.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
+[![Photo of Dasharo FidelisGuard Z690 with open case](/attachment/posts/dasharo-fidelisguard-z690_3.jpg)](https://web.archive.org/web/20240917145232/https://shop.3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
 
-For further details, please see the [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) product page.
+For further details, please see the [Dasharo FidelisGuard Z690](https://web.archive.org/web/20240917145232/https://shop.3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) product page.
 
-[![Photo of the outside of the Dasharo FidelisGuard Z690](/attachment/posts/dasharo-fidelisguard-z690_4.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
+[![Photo of the outside of the Dasharo FidelisGuard Z690](/attachment/posts/dasharo-fidelisguard-z690_4.jpg)](https://web.archive.org/web/20240917145232/https://shop.3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)

From 187db01576953444c708b5e3cea3edb2b88ddaa3 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Wed, 9 Apr 2025 15:43:48 -0700
Subject: [PATCH 290/332] Fix dead link

---
 user/hardware/certified-hardware/dasharo-fidelisguard-z690.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/hardware/certified-hardware/dasharo-fidelisguard-z690.md b/user/hardware/certified-hardware/dasharo-fidelisguard-z690.md
index 6c85d154..0ded8346 100644
--- a/user/hardware/certified-hardware/dasharo-fidelisguard-z690.md
+++ b/user/hardware/certified-hardware/dasharo-fidelisguard-z690.md
@@ -8,7 +8,7 @@ image: /attachment/posts/dasharo-fidelisguard-z690_2.jpg
 
 The [Dasharo FidelisGuard Z690](https://web.archive.org/web/20240917145232/https://shop.3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
 
-[![Photo of MSI PRO Z690-A DDR4 motherboard](/attachment/posts/dasharo-fidelisguard-z690_1.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
+[![Photo of MSI PRO Z690-A DDR4 motherboard](/attachment/posts/dasharo-fidelisguard-z690_1.jpg)](https://web.archive.org/web/20240917145232/https://shop.3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
 
 The [Dasharo FidelisGuard Z690](https://web.archive.org/web/20240917145232/https://shop.3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) is a full desktop PC build that brings the [Dasharo](https://dasharo.com/) open-source firmware distribution to the MSI PRO Z690-A DDR4 motherboard with Qubes OS preinstalled. The full configuration includes:
 

From 674f9b6dd20e8290ae9aa6031c1b615a47010238 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Thu, 10 Apr 2025 13:37:18 +0000
Subject: [PATCH 291/332] Fix dead link to Micah's video

---
 introduction/video-tours.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/introduction/video-tours.md b/introduction/video-tours.md
index 575ba8af..94739397 100644
--- a/introduction/video-tours.md
+++ b/introduction/video-tours.md
@@ -22,7 +22,7 @@ Watch all the talks from Qubes OS Summit 2022, which took place September 9-11,
 
 ## Micah Lee presents "Qubes OS: The Operating System That Can Protect You Even If You Get Hacked"
 
-[Micah Lee](https://micahflee.com/), a long-time Qubes [advocate](/endorsements/), presented [Qubes OS: The Operating System That Can Protect You Even If You Get Hacked](https://www.hope.net/schedule.html#-qubes-os-the-operating-system-that-can-protect-you-even-if-you-get-hacked-) at the [Circle of HOPE](https://www.hope.net/index.html) conference, which took place July 20-22, 2018 in New York City.
+[Micah Lee](https://micahflee.com/), a long-time Qubes [advocate](/endorsements/), presented [Qubes OS: The Operating System That Can Protect You Even If You Get Hacked](https://archive.org/details/QubesOSTheOperatingSystemThatCanProtectYouEvenIfYouGetHackedTalkByMicahLee) at the Circle of HOPE conference, which took place July 20-22, 2018 in New York City.
 
 <div class="video more-bottom">
   <iframe class="responsive" referrerpolicy="no-referrer" scrolling="no" allowfullscreen src="https://livestream.com/accounts/9197973/events/8286152/videos/178431606/player?autoPlay=false"></iframe>

From 81e4abc4160d56179f3229f2d7067b8907c207a4 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sun, 13 Apr 2025 12:55:19 +0000
Subject: [PATCH 292/332] Minor changes to workflow.md using Builder v2

---
 developer/building/development-workflow.md | 29 +++++++++++-----------
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/developer/building/development-workflow.md b/developer/building/development-workflow.md
index e4967756..f125533f 100644
--- a/developer/building/development-workflow.md
+++ b/developer/building/development-workflow.md
@@ -12,17 +12,17 @@ title: Development workflow
 
 A workflow for developing Qubes OS+
 
-First things first, setup [QubesBuilder](/doc/qubes-builder-v2/). This guide
+To begin, setup [QubesBuilder](/doc/qubes-builder-v2/). This guide
 assumes you're using qubes-builder v2 to build Qubes.
 
 ## Repositories and committing Code
 
-Qubes is split into a bunch of git repos. These are all contained in the
+Qubes source code is split into many git repos. These are all contained in the
 `artifacts/sources` directory under qubes-builder. Subdirectories there are
 separate components, stored in separate git repositories.
 
 The best way to write and contribute code is to create a git repo somewhere
-(e.g., github) for the repo you are interested in editing (e.g.,
+(e.g., GitHub) for the repo you are interested in editing (e.g.,
 `qubes-manager`, `core-agent-linux`, etc). To integrate your repo with the rest
 of Qubes, cd to the repo directory and add your repository as a remote in git
 
@@ -30,18 +30,17 @@ of Qubes, cd to the repo directory and add your repository as a remote in git
 
 ~~~
 $ cd qubes-builder/artifacts/sources/qubes-manager
-$ git remote add abel git@github.com:abeluck/qubes-manager.git
+$ git remote add abel git@GitHub.com:abeluck/qubes-manager.git
 ~~~
 
 You can then proceed to easily develop in your own branches, pull in new
-commits from the dev branches, merge them, and eventually push to your own repo
-on github.
+commits from the dev branches, merge them, and eventually push to your own repo.
 
 When you are ready to submit your changes to Qubes to be merged, push your
 changes, then create a signed git tag (using `git tag -s`). Finally, send a
-letter to the Qubes listserv describing the changes and including the link to
-your repository. You can also create pull request on github. Don't forget to
-include your public PGP key you use to sign your tags.
+letter to the Qubes listserv describing the changes, and including a link to
+your repository. If you are using GitHub you can instead create a pull request.
+Don't forget to include the public PGP key you use to sign your tags.
 
 ### Kernel-specific notes
 
@@ -117,7 +116,7 @@ vi series.conf
 
 #### Building RPMs
 
-Now it is a good moment to make sure you have changed kernel release name in
+Now is a good moment to make sure you have changed the kernel release name in
 rel file. For example, if you change it to '1debug201211116c' the
 resulting RPMs will be named
 'kernel-3.4.18-1debug20121116c.pvops.qubes.x86\_64.rpm'. This will help
@@ -284,12 +283,12 @@ if [ "$1" = "tb" ]; then
     exit $?
 fi
 
-git remote add $1 git@github.com:$1/qubes-`basename $PWD`
+git remote add $1 git@GitHub.com:$1/qubes-`basename $PWD`
 ~~~
 
 It should be executed from component top level directory. This script takes one
 argument - remote name. If it is `tb`, then it creates qrexec-based git remote
-to `testbuilder` VM. Otherwise it creates remote pointing at github account of
+to `testbuilder` VM. Otherwise it creates remote pointing at GitHub account of
 the same name. In any case it points at repository matching current directory
 name.
 
@@ -308,7 +307,7 @@ current and current-testing).
 
 ### RPM packages - yum repo
 
-In source VM, grab [linux-yum](https://github.com/QubesOS/qubes-linux-yum) repository (below is assumed you've made it in
+In source VM, grab [linux-yum](https://GitHub.com/QubesOS/qubes-linux-yum) repository (below is assumed you've made it in
 `~/repo-yum-upload` directory) and replace `update_repo.sh` script with:
 
 ~~~
@@ -324,7 +323,7 @@ find -type f -name '*.rpm' -delete
 qrexec-client-vm $VMNAME local.UpdateYum
 ~~~
 
-In target VM, setup actual yum repository (also based on [linux-yum](https://github.com/QubesOS/qubes-linux-yum), this time
+In target VM, setup actual yum repository (also based on [linux-yum](https://GitHub.com/QubesOS/qubes-linux-yum), this time
 without modifications). You will also need to setup some gpg key for signing
 packages (it is possible to force yum to install unsigned packages, but it
 isn't possible for `qubes-dom0-update` tool). Fill `~/.rpmmacros` with
@@ -404,7 +403,7 @@ Remember to also import gpg public key using `rpm --import`.
 
 Steps are mostly the same as in the case of yum repo. The only details that differ:
 
-- use [linux-deb](https://github.com/QubesOS/qubes-linux-deb) instead of [linux-yum](https://github.com/QubesOS/qubes-linux-yum) as a base - both in source and target VM
+- use [linux-deb](https://GitHub.com/QubesOS/qubes-linux-deb) instead of [linux-yum](https://GitHub.com/QubesOS/qubes-linux-yum) as a base - both in source and target VM
 - use different `update_repo.sh` script in source VM (below)
 - use `local.UpdateApt` qrexec service in target VM (code below)
 - in target VM additionally place `update-local-repo.sh` script in repository dir (code below)

From 63ad8ab1c1f094ae2cabbc55f5282952cbda887f Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sun, 13 Apr 2025 12:57:18 +0000
Subject: [PATCH 293/332] Minor changes to description of qubes-builder-v2

---
 developer/building/qubes-builder-v2.md | 52 +++++++++++++-------------
 1 file changed, 27 insertions(+), 25 deletions(-)

diff --git a/developer/building/qubes-builder-v2.md b/developer/building/qubes-builder-v2.md
index 79d85e21..1210910b 100644
--- a/developer/building/qubes-builder-v2.md
+++ b/developer/building/qubes-builder-v2.md
@@ -10,8 +10,8 @@ ref: 311
 title: Qubes builder v2
 ---
 
-This is a brief introduction of using Qubes Builder v2 to work with Qubes OS
-sources. It will walk you through installing and configuring Builder v2 and
+This is a brief introduction to using Qubes Builder v2 to work with Qubes OS
+sources. It will walk you through installing and configuring Builder v2, and
 using it to fetch and build Qubes OS packages.
 
 For details and customization, use [Qubes OS v2 builder documentation](https://github.com/QubesOS/qubes-builderv2/).
@@ -30,25 +30,17 @@ uploading stages are executed locally outside a cage.
 
 # Setup
 
-This is a simple setup for using a docker executor (a good default choice,
-if you don't know which executor to use, use docker).
+This is a simple setup using a docker executor. This is a good default choice;
+if you don't know which executor to use, use docker.
 
-1. First, decide what qube are you going to use for working with Qubes
+1. First, decide what qube you are going to use when working with Qubes
    Builder v2. It can be an AppVM or a Standalone qube, with some steps
    different between the two.
 
-2. Then, clone the qubes-builder v2 repository into a location of your
-   choice:
-    ```shell
-    git clone https://github.com/QubesOS/qubes-builderv2
-    cd qubes-builderv2/
-    ```
+2. Installing dependencies
 
-3. Installing dependencies
-
-   Dependencies need to be installed for the qube you want to be developing
-   using Qubes Builder v2 - either in its template, or in the qube itself,
-   if it's a standalone.
+   If you want to use an app qube for developing, install dependencies in the template.
+   If you are using a standalone, install them in the qube itself.
     Dependencies are specified in `dependencies-*.
    txt` files in the main builder directory, and you can install them easily
    in the following ways:
@@ -64,7 +56,16 @@ if you don't know which executor to use, use docker).
     $ test -f /usr/share/qubes/marker-vm && sudo apt install qubes-gpg-split
    ```
 
-4. If you haven't used docker in the current qube, you need also to set up
+    If you have installed dependencies in the template, close it, and
+    (re)start the development qube.
+
+3. Clone the qubes-builder v2 repository into a location of your choice:
+    ```shell
+    git clone https://github.com/QubesOS/qubes-builderv2
+    cd qubes-builderv2/
+    ```
+
+4. If you haven't previously used docker in the current qube, you need to set up
    some permissions. In particular, the user has to be added to the `docker`
    group:
     ```shell
@@ -77,8 +78,8 @@ if you don't know which executor to use, use docker).
    $ tools/generate-container-image.sh docker
     ```
 
-   In an AppVM, as `/var/lib/docker` is not persistent by default, you also
-   need to use bind-dirs to avoid repeating this step after reboot, adding
+   In an app qube, as `/var/lib/docker` is not persistent by default, you also
+   need to use [bind-dirs](/doc/bind-dirs/) to avoid repeating this step after reboot, adding
    the following to the `/rw/config/qubes-bind-dirs.d/docker.conf` file in
    this qube:
 
@@ -148,13 +149,14 @@ using Fedora 37, `vm-fc40` would be a qube using Fedora 40 etc.), use:
 $ ./qb -c core-admin-client -d host-fc37 package fetch prep build
 ```
 
-If you want to fetch entire Qubes OS sources (caution: some repositories might
-have additional requirements; you can disable repositories that are not
-needed in the `example-configs/*.yml` file you are using by commenting them
-out. In particular, `python-fido2`, `lvm` and `windows`-related repositories
-have
-special requirements), use the following:
+If you want to fetch the entire Qubes OS source use the following:
 
 ```shell
 $ ./qb package fetch
 ```
+
+**caution**: some repositories might have additional requirements. You can
+disable repositories that are not needed in the `example-configs/*.yml`
+file you are using by commenting them out. In particular, `python-fido2`,
+`lvm` and `windows`-related repositories have special requirements.
+

From b9bec14ae44273d6fcac0f0294ca038122aa2d43 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sun, 13 Apr 2025 14:37:15 +0000
Subject: [PATCH 294/332] Update firewall page to make sure sys-net rules are
 correctly specified

---
 user/security-in-qubes/firewall.md | 35 ++++++++++++++++++------------
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index 1289db7a..5af06ec4 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -269,7 +269,8 @@ As an example we can take the use case of qube QubeDest running a web server lis
 
 **1. Identify the IP addresses you will need to use for sys-net, sys-firewall and the destination qube.**
 
-You can get this information using various methods, but only the first one can be used for `sys-net` outside world IP:
+You can get this information using various methods.
+Only the first method can be used for `sys-net` to find the external IP:
 
 - by running this command in each qube: `ip -4 -br a | grep UP`
 - using `qvm-ls -n`
@@ -284,7 +285,12 @@ Note the IP addresses you will need, they will be required in the next steps.
 
 For the following example, we assume that the physical interface ens6 in sys-net is on the local network 192.168.x.y with the IP 192.168.x.n, and that the IP address of sys-firewall is 10.137.1.z.
 
-In the sys-net VM's Terminal, the first step is to define an ntables chain that will receive DNAT rules to relay the network traffic on a given port to the qube NetVM, we recommend to define a new chain for each destination qube to ease rules management:
+When writing rules in sys-net, you can use `iif` or `iifname`.
+`iif` is faster, but can change where interfaces are dynamically created and destroyed, eg. ppp0.
+In that case use `iifname`, like this `iifname ens6`.
+`iifname` can also match wildcards - `iifname "eth*"`
+
+In the sys-net VM's Terminal, the first step is to define an nftables chain that will receive DNAT rules to relay the network traffic on a given port to the qube NetVM, we recommend to define a new chain for each destination qube to ease rules management:
 
 ```
 nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
@@ -292,25 +298,24 @@ nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority fi
 
 > Note: the name `custom-dnat-qubeDST` is arbitrary
 
-> Note: while we use a DNAT chain for a single qube, it's totally possible to have a single DNAT chain for multiple qubes
+> Note: while we use a DNAT chain for a single qube, it's possible to have a single DNAT chain for multiple qubes
 
 Second step, code a natting firewall rule to route traffic on the outside interface for the service to the sys-firewall VM
 
 ```
-nft add rule qubes custom-dnat-qubeDEST iifgroup 1 ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
+nft add rule qubes custom-dnat-qubeDEST iifname ens6 ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
 ```
 
 Third step, code the appropriate new filtering firewall rule to allow new connections for the service
 
 ```
-nft add rule qubes custom-forward iifgroup 1 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
+nft add rule qubes custom-forward iifname ens6 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
 ```
 
 > Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
+> If you want to expose the service on multiple interfaces, repeat steps 2 and 3 above, for each interface. Alternatively, you can leave out the interface completely.
 
-> If you want to expose the service on multiple interfaces, repeat the steps 2 and 3 described above, for each interface. Alternatively, you can leave out the interface completely.
-
-Verify the rules on sys-net firewall correctly match the packets you want by looking at its counters, check for the counter lines in the chains `custom-forward` and `custom-dnat-qubeDEST`:
+Verify the rules on the sys-net firewall correctly match the packets you want by looking at the counters: check for the counter lines in the chains `custom-forward` and `custom-dnat-qubeDEST`:
 
 ```
 nft list table ip qubes
@@ -320,12 +325,12 @@ In this example, we can see 7 packets in the forward rule, and 3 packets in the
 
 ```
 chain custom-forward {
-  iifgroup 1 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter packets 7 bytes 448 accept
+  iifname ens6 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter packets 7 bytes 448 accept
 }
 
 chain custom-dnat-qubeDEST {
   type nat hook prerouting priority filter + 1; policy accept;
-  iifgroup 1 ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter packets 3 bytes 192 dnat to 10.138.33.59
+  iifname ens6 ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter packets 3 bytes 192 dnat to 10.138.33.59
 }
 ```
 
@@ -351,18 +356,20 @@ Content of `/rw/config/qubes-firewall-user-script` in `sys-net`:
 if nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
 then
   # create the dnat rule
-  nft add rule qubes custom-dnat-qubeDEST iifgroup 1 saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
+  nft add rule qubes custom-dnat-qubeDEST iifname ens6 saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
 
   # allow forwarded traffic
-  nft add rule qubes custom-forward iifgroup 1 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
+  nft add rule qubes custom-forward iifname ens6 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
 fi
 ~~~
 
 **3. Route packets from the FirewallVM to the VM**
 
-For the following example, we use the fact that the physical interface of sys-firewall, facing sys-net, is eth0. Furthermore, we assume that the target VM running the web server has the IP address 10.137.0.xx and that the IP address of sys-firewall is 10.137.1.z.
+For the following example, we use the fact that the interface of sys-firewall facing sys-net, is eth0.
+This is allocated to iifgroup 1.
+Furthermore, we assume that the IP address of sys-firewall is 10.137.1.z, and the target VM running the web server has the IP address 10.137.0.xx.
 
-In the sys-firewall VM's Terminal, add a DNAT chain that will contain routing rules:
+In the sys-firewall Terminal, add a DNAT chain that will contain routing rules:
 
 ```
 nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'

From c6b0237db645672220e1629775dea7a4aa3909da Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sat, 19 Apr 2025 14:03:45 +0000
Subject: [PATCH 295/332] Update networking page to make it clear that the ipv6
 feature only affects qubes-configured networking

---
 developer/system/networking.md | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/developer/system/networking.md b/developer/system/networking.md
index 76a88de4..c67fdfe3 100644
--- a/developer/system/networking.md
+++ b/developer/system/networking.md
@@ -62,9 +62,12 @@ Such configuration can be expressed by enabling `ipv6` feature only on some subs
 
 ![ipv6-2](/attachment/doc/ipv6-2.png)
 
-Besides enabling IPv6 forwarding, standard Qubes firewall can be used to limit what network resources are available to each qube. Currently only `qvm-firewall` command support adding IPv6 rules, GUI firewall editor will have this ability later.
+Besides enabling IPv6 forwarding, the standard Qubes firewall can be used to limit what network resources are available to each qube. Currently only the `qvm-firewall` command supports adding IPv6 rules, the GUI firewall editor will have this ability later.
+
+**Note:** Setting or unsetting the `ipv6` feature only affects qubes-configured networking. It does not affect e.g. external interfaces. If you want to restrict IPv6 on these interfaces change the settings in Network Manager. Alternatively, disable IPv6 support using methods appropriate to the underlying template.
 
 ### Limitations
 
 Currently only IPv4 DNS servers are configured, regardless of `ipv6` feature state. It is done this way to avoid reconfiguring all connected qubes whenever IPv6 DNS becomes available or not. Configuring qubes to always use IPv6 DNS and only fallback to IPv4 may result in relatively long timeouts and poor usability.
 But note that DNS using IPv4 does not prevent to return IPv6 addresses. In practice this is only a problem for IPv6-only networks.
+

From 5cb2a1e404bd415f35727b1cced9659f3226bb68 Mon Sep 17 00:00:00 2001
From: "Dr. Gerhard Weck" <GerhardWeck@online.de>
Date: Fri, 25 Apr 2025 13:56:11 +0200
Subject: [PATCH 296/332] Describe installation changes for Windows 11

---
 user/templates/windows/windows-qubes-4-1.md | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/user/templates/windows/windows-qubes-4-1.md b/user/templates/windows/windows-qubes-4-1.md
index 4d38a4bb..829a1087 100644
--- a/user/templates/windows/windows-qubes-4-1.md
+++ b/user/templates/windows/windows-qubes-4-1.md
@@ -146,18 +146,17 @@ These parameters are set for the following reasons:
   - Install on first disk.
   - **For Windows 11 only**: Windows 11 requires TPM 2.0, which currently is not supported from Xen. In Order to install Windows 11 under Qubes, the check for TPM in the Windows installer has to be disabled:
  
-    -  When you start setup without having a TPM, you get an error message like *This PC does not fulfil the minimum requirements for Windows 11*.
-    -  Typing Shift-F10 then opens a console window.
+    -  When the window allowing you to select a Windows version is displayed, **do not select a version and close this window**, but instead type Shift-F10 to open a console window.
     -  Here you type `regedit` to start the registry editor.
     -  There you position to the key `HKEY_LOCAL_MACHINE\SYSTEM\Setup`.
     -  Now create the key `LabConfig`.
     -  Position to this key and create 3 DWORD values called `BypassTPMCheck`, `BypassSecureBootCheck` and `BypassRAMCheck` and set each value to `1`.
     -  Close the registry editor and console windows.
-    -  In the setup window, hit the left arrow in the left upper corner. You will then return into the setup, which will continue normally and install Windows 11 without TPM 2.0.
+    -  You will then return to the setup, which will continue normally and install Windows 11 without TPM 2.0.
    
-    :warning: **Caution:** This temporary patch may cease to work if it so pleases Microsoft some time.
+    :warning: **Caution:** This temporary patch may cease to work if it so pleases Microsoft sometime. With version 24H2 it is still working.
     
-    The installation of Windows 11 may require an internet connection to grab a Microsoft ID. This is currently true only for the home addition, but will probably extend to the Pro edition, too. A workaround to bypass the internet connection requirements of the Windows 11 setup has been published that currently works for version 21H2 but may be blocked some time in the future by Microsoft:
+    The installation of Windows 11 may require an internet connection to grab a Microsoft ID. Previously, this was true only for the home edition, but since version 24H2, it extends to the Pro edition, too. A workaround to bypass the internet connection requirements of the Windows 11 setup has been published that works for version 21H2 but may be blocked for newer versions:
     
     - When you reach the “Let’s Connect You To A Network” page, type Shift-F10 to open a console window.
     - Here you type `taskmgr` to start the Task Manager window so you can see all running processes.
@@ -173,6 +172,15 @@ These parameters are set for the following reasons:
     - Enter the username you want to use and click `Next`.
     - Enter a password and click `Next`. You can leave the field blank but it's not recommended.
 
+    For version 24H2, the following actions allow you to install Windows 11 with a local account, if the VM is defined, at least temporarily, without a netVM:
+     - After some reboots, the VM will show a window allowing the selection of an installation country. In this window, type  Shift-F10 to open a console window.
+     - In this window, type `oobe\bypassnro`. The VM will then reboot and return to the country selection window. The network connection window will now show an option "I don't have internet", allowing you to define a local account.
+
+    In new preview builds of Windows (26120 and beyond, and eventually the next release version), the `oobe\bypassnro` command has been erased and no longer works. Instead, there's a new command called start `ms-chx:localonly` that does something similar. In this case, proceed as follows:
+     - Follow the Windows 11 install process until you get to the Sign in screen. Here, type  Shift-F10 to open a console window.
+     - Enter start `ms-cxh:localonly` at the command prompt.
+     - A "Create a user for this PC" dialog window appears, allowing you to define a local account.
+
 - On systems shipped with a Windows license, the product key may be read from flash via root in dom0:
 
     `strings < /sys/firmware/acpi/tables/MSDM`

From 5bd45751f962ce485cacb3bf376991dc2e27b398 Mon Sep 17 00:00:00 2001
From: PixelPilot <161360836+PixelPil0t1@users.noreply.github.com>
Date: Sun, 27 Apr 2025 09:06:44 +0200
Subject: [PATCH 297/332] Update release-notes.md

---
 developer/releases/4_0/release-notes.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/developer/releases/4_0/release-notes.md b/developer/releases/4_0/release-notes.md
index b80a1959..ca97ac0d 100644
--- a/developer/releases/4_0/release-notes.md
+++ b/developer/releases/4_0/release-notes.md
@@ -9,7 +9,7 @@ title: Qubes R4.0 release notes
 New features since 3.2
 ----------------------
 
-* Core management scripts rewrite with better structure and extensibility, [API documentation](https://dev.qubes-os.org/projects/qubes-core-admin/en/latest/)
+* Core management scripts rewrite with better structure and extensibility, [API documentation](https://dev.qubes-os.org/en/latest/index.html)
 * [Admin API](/news/2017/06/27/qubes-admin-api/) allowing strictly controlled managing from non-dom0
 * All `qvm-*` command-line tools rewritten, some options have changed
 * Renaming VM directly is prohibited, there is GUI to clone under new name and remove old VM

From bd8a41941247969c2251b72d068bde25c0fef15c Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Tue, 29 Apr 2025 12:35:08 +0000
Subject: [PATCH 298/332] Slight change to comment on use of color. Fix minor
 spelling mistake.

---
 introduction/getting-started.md | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/introduction/getting-started.md b/introduction/getting-started.md
index 4a02083c..34ed98a2 100644
--- a/introduction/getting-started.md
+++ b/introduction/getting-started.md
@@ -67,8 +67,9 @@ in dom0. (That's what your app qubes are for!) In short, be very careful when in
 ### Color & Security
 
 You'll choose a **color** for each of your qubes out of a predefined set of
-colors. The color of the frame of each window on your desktop will correspond to the color of that cube. 
-These colored frames help you keep track of which qube you're currently using and how trustworthy it is. This is especially helpful
+colors. The color of the frame of each window on your desktop will correspond to the color of that qube. 
+These colored frames help you keep track of which qube you're currently using.
+You may use them to show how trustworthy it is. This is especially helpful
 when you have the same program running in multiple qubes at the same time. For
 example, if you're logged in to your bank account in one qube while doing some
 random web surfing in a different qube, you wouldn't want to accidentally enter

From 7870666de371d924021449f8886e1e99d4b110b2 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Wed, 30 Apr 2025 11:42:31 +0000
Subject: [PATCH 299/332] Clarified that main method relates to finding
 controller for attached device. Moved QubeManager method to separate section

---
 user/how-to-guides/how-to-use-usb-devices.md | 45 ++++++++++----------
 1 file changed, 22 insertions(+), 23 deletions(-)

diff --git a/user/how-to-guides/how-to-use-usb-devices.md b/user/how-to-guides/how-to-use-usb-devices.md
index f845f89e..58d704ce 100644
--- a/user/how-to-guides/how-to-use-usb-devices.md
+++ b/user/how-to-guides/how-to-use-usb-devices.md
@@ -13,7 +13,7 @@ title: How to use USB devices
 
 If you are looking to handle USB *storage* devices (thumbdrives or USB-drives), please have a look at the [block device](/doc/how-to-use-block-storage-devices/) page.
 
-**Note:** Attaching USB devices to VMs requires a [USB qube](/doc/usb-qubes/).
+**Note:** Attaching USB devices to qubes requires a [USB qube](/doc/usb-qubes/).
 
 **Important security warning:** USB passthrough comes with many security implications.
 Please make sure you carefully read and understand the **[security considerations](/doc/device-handling-security/#usb-security)**.
@@ -36,7 +36,7 @@ Click the device-manager-icon: ![device manager icon](/attachment/doc/media-remo
 A list of available devices appears.
 USB-devices have a USB-icon to their right: ![usb icon](/attachment/doc/generic-usb.png)
 
-Hover on one device to display a list of VMs you may attach it to.
+Hover on one device to display a list of qubes you may attach it to.
 
 Click one of those.
 The USB device will be attached to it.
@@ -44,7 +44,7 @@ You're done.
 
 After you finished using the USB-device, you can detach it the same way by clicking on the Devices Widget.
 You will see an entry in bold for your device such as **`sys-usb:2-5 - 058f_USB_2.0_Camera`**.
-Hover on the attached device to display a list of running VMs.
+Hover on the attached device to display a list of running qubes
 The one to which your device is connected will have an eject button ![eject icon](/attachment/doc/media-eject.png) next to it.
 Click that and your device will be detached.
 
@@ -74,7 +74,7 @@ sys-usb:2-1     03f0:0641 PixArt_Optical_Mouse
 ```
 
 Now, you can use your USB device (camera in this case) in the `work` qube.
-If you see the error `ERROR: qubes-usb-proxy not installed in the VM` instead, please refer to the [Installation Section](#installation-of-qubes-usb-proxy).
+If you see the error `ERROR: qubes-usb-proxy not installed in the qube` instead, please refer to the [Installation Section](#installation-of-qubes-usb-proxy).
 
 When you finish, detach the device.
 
@@ -100,7 +100,7 @@ To use this feature, the `qubes-usb-proxy` package needs to be installed in the
 This section exists for reference or in case something broke and you need to reinstall `qubes-usb-proxy`.
 Under normal conditions, `qubes-usb-proxy` should already be installed and good to go.
 
-If you receive this error: `ERROR: qubes-usb-proxy not installed in the VM`, you can install the `qubes-usb-proxy` with the package manager in the VM you want to attach the USB device to.
+If you receive this error: `ERROR: qubes-usb-proxy not installed in the qube`, you can install the `qubes-usb-proxy` with the package manager in the qube you want to attach the USB device to.
 
 - Fedora: 
   ```
@@ -121,12 +121,9 @@ Mouse and keyboard setup are part of [setting up a USB qube](/doc/usb-qubes/).
 
 Some USB devices are not compatible with the USB pass-through method Qubes employs.
 In situations like these, you can try to pass through the entire USB controller to a qube as PCI device.
-However, with this approach one cannot attach single USB devices but has to attach the whole USB controller with whatever USB devices are connected to it.
-
-You can find your controller and its BDF address using either of two methods described below. Using the command-line tools lsusb and readlink or by using the Qube Manager GUI. It is possible that on some system configurations the readlink method produces output which is different from the example below, while the Qube Manager method allows one to easily determine the correct controller and BDF address.
-
-#### Method 1: Using lsusb and readlink
+However, with this approach you cannot attach single *USB devices* but have to attach the whole *USB controller* with whatever USB devices are connected to it.
 
+You can find your controller and its BDF address using the method described below, using the command-line tools `lsusb` and `readlink`.
 If you have multiple USB controllers, you must first figure out which PCI device is the right controller.
 
 First, find out which USB bus the device is connected to (note that these steps need to be run from a terminal inside your USB qube):
@@ -145,7 +142,7 @@ Bus 003 Device 003: ID 413c:818d Dell Computer Corp.
 (In this case, the device isn't fully identified)
 
 The device is connected to USB bus \#3.
-Check which other devices are connected to the same bus, since *all* of them will be attach to the same VM.
+Check which other devices are connected to the same bus, since *all* of them will be attached to the target qube.
 
 To find the right controller, follow the usb bus:
 
@@ -158,27 +155,29 @@ This should output something like:
 ```
 ../../../devices/pci-0/pci0000:00/0000:00:1a.0/usb3
 ```
-
-If the output format does not match this example, or you are unsure if it contains the correct BDF address, you can try finding the address using method 2 using the Qube Manager instead.
-
-Now you see the path and the text between `/pci0000:00/0000:` and `/usb3` i.e. `00:1a.0` is the BDF address. Strip the address and pass it to the [`qvm-pci` tool](/doc/how-to-use-pci-devices/) to attach the controller to the targetVM.
-
-For example, On R 4.0 the command would look something like
-
+Now you see the path: the text between `/pci0000:00/0000:` and `/usb3` i.e. `00:1a.0` is the BDF address. Strip the address and pass it to the [`qvm-pci` tool](/doc/how-to-use-pci-devices/) to attach the controller to the target qube, like this:
 ```
 qvm-pci attach --persistent personal dom0:00_1a.0
 ```
 
-#### Method 2: Using the Qube Manager
+It is possible that on some system configurations the readlink method produces output which is different from the example above,
+For example, you might see output like this:
+```
+../../../devices/pci0000:00/0000:00:1c.0/0000:01:00.0/usb1
+```
+In this case, there is a PCI bridge, and the BDF address of the controller is the *last* item, 01:00.0
 
-Open the Qube Manager, then right click on one of the VMs and open the settings. Go to the tab "Devices".
+If the output format does not match this example, or you are unsure if it contains the correct BDF address, you can try finding the address using method 2 using the Qube Manager instead.
 
+#### Identifying controllers using the Qube Manager
+Using Qube Manager you can quickly determine the controllers on your system and their BDF addresses.
+
+Open the Qube Manager, then right click on one of the qubes and open the settings. Go to the tab "Devices".
 Here you should see your available devices along with their BDF addresses. Look for the lines containing "USB controller".
-
 They should look something like: `01:00.0 USB controller: Name of manufacturer`
 
 The first part is the BDF address, in this example: `01:00.0`
 
-If, for example, you have 2 USB controllers in your system because you added one you should see 2 such lines and you can probably guess which controller is the one on the mainboard and which one you added. For example, if you have a mainboard with an Intel chipset, it is possible that all of the mainboard devices show as "Intel Corporation" while the added controller shows another name of manufacturer.
+If, for example, you have 2 USB controllers in your system because you added one you should see 2 such lines and you can probably guess which controller is the one on the mainboard and which one you added. For example, if you have a mainboard with an Intel chipset, it is possible that all of the mainboard devices show as "Intel Corporation", while the added controller shows another manufacturer's name.
 
-Now you should be able to tell which is the correct BDF address of the mainboard USB controller or the added USB controller.
+Now you should be able to tell which is the BDF address of the mainboard USB controller or the added USB controller.

From 4a91a742fec5baacf6e338e96631d934759e2f7c Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Wed, 30 Apr 2025 12:05:15 +0000
Subject: [PATCH 300/332] Minor changes to How to use USB devices page.

---
 user/how-to-guides/how-to-use-usb-devices.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/user/how-to-guides/how-to-use-usb-devices.md b/user/how-to-guides/how-to-use-usb-devices.md
index cdcb7f54..b47c4c14 100644
--- a/user/how-to-guides/how-to-use-usb-devices.md
+++ b/user/how-to-guides/how-to-use-usb-devices.md
@@ -167,10 +167,10 @@ For example, you might see output like this:
 ```
 In this case, there is a PCI bridge, and the BDF address of the controller is the *last* item, 01:00.0
 
-If the output format does not match this example, or you are unsure if it contains the correct BDF address, you can try finding the address using method 2 using the Qube Manager instead.
+If the output format does not match this example, or you are unsure if it contains the correct BDF address, you can try finding the address using using the Qube Manager instead.
 
-#### Identifying controllers using the Qube Manager
-Using Qube Manager you can quickly determine the controllers on your system and their BDF addresses.
+### Identifying controllers using the Qube Manager
+Using Qube Manager you can quickly determine the controllers on your system and their BDF addresses, but not which controller a particular device is attached to.
 
 Open the Qube Manager, then right click on one of the qubes and open the settings. Go to the tab "Devices".
 Here you should see your available devices along with their BDF addresses. Look for the lines containing "USB controller".

From ef37a8c68b16f8b560e47341471ba6e68c9e0ba6 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Wed, 30 Apr 2025 13:15:08 +0000
Subject: [PATCH 301/332] Update page on standalones with informatin about
 virtualization modes. Closes
 https://github.com/QubesOS/qubes-issues/issues/7517

---
 user/advanced-topics/standalones-and-hvms.md | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/user/advanced-topics/standalones-and-hvms.md b/user/advanced-topics/standalones-and-hvms.md
index 198dab42..2eae8b0c 100644
--- a/user/advanced-topics/standalones-and-hvms.md
+++ b/user/advanced-topics/standalones-and-hvms.md
@@ -50,6 +50,21 @@ is about the virtualization mode. In practice, however, it is most common for
 standalones to be HVMs and for HVMs to be standalones. Hence, this page covers
 both topics.
 
+## Understanding Virtualization Modes
+
+PVH has both better performance and better security than either PV or HVM:
+
+PVH has less attack surface than PV, as it relies on Second Level Address Translation (SLAT) hardware. Guests modify their own page tables natively, without hypervisor involvement. Xen does not need to perform complex checks to ensure that a guest cannot obtain write access to its own page tables, as is necessary for PV. Flaws in these checks have been a source of no fewer than four guest ⇒ host escapes: XSA-148, XSA-182, XSA-212, and XSA-213.
+
+PVH also has less attack surface than HVM, as it does not require QEMU to provide device emulation services. While QEMU is confined in a stubdomain, and again in a seccomp based sandbox, the stubdomain has significant attack surface against the hypervisor. Not only does it have the full attack surface of a PV domain, it also has access to additional hypercalls that allow it to control the guest it is providing emulation services for. XSA-109 was a vulnerability in one of these hypercalls.
+
+PVH has better performance than HVM, as the stubdomain iin HVM consumes resources (both memory and a small amount of CPU). There is little difference in the I/O path at runtime, as both PVH and HVM guests usually use paravirtualized I/O protocols.
+
+Surprisingly, PVH often has better performance than PV. This is because PVH does not require hypercalls for page table updates, which are expensive. SLAT does raise the cost of TLB misses, but this is somewhat mitigated by a second-level TLB in recent hardware.
+
+
+
+
 ## Creating a standalone
 
 You can create a standalone in the Qube Manager by selecting the "Type" of

From 55441615bfc082426c4f3b57e45c106afbedbd7e Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Fri, 2 May 2025 00:24:26 +0000
Subject: [PATCH 302/332] Fix reference to /var/logs/syslog, and add
 journalctl. Update link from Qubes-Community to Forum guides. Minor changes.

---
 user/troubleshooting/vpn-troubleshooting.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/user/troubleshooting/vpn-troubleshooting.md b/user/troubleshooting/vpn-troubleshooting.md
index 4671066c..dbf2ccd4 100644
--- a/user/troubleshooting/vpn-troubleshooting.md
+++ b/user/troubleshooting/vpn-troubleshooting.md
@@ -30,11 +30,11 @@ After suspend/resume, OpenVPN may not automatically reconnect. In order to get i
 
 After setting up OpenVPN and restarting the VM, you may be repeatedly getting the popup "Ready to start link", but the VPN isn't connected.
 
-To figure out the root of the problem, check the VPN logs in `/var/logs/syslog`. The log may reveal issues like missing OpenVPN libraries, which you can then install.
+To figure out the root of the problem, check the VPN logs in `/var/log/syslog` or use `journalctl`. The logs may reveal issues like missing OpenVPN libraries, which you can then install.
 
 ## `notify-send` induced failure
-[Some VPN guides](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md) use complex scripts that by themselves include call of `notify-send`, yet some images may not contain this tool or may not have it working properly.
-For instance calling `notify-send` on `fedora-36` template VM gives:
+[Some VPN guides](https://forum.qubes-os.org/t/configuring-a-proxyvm-vpn-gateway/19061) use complex scripts that include a call to `notify-send`, yet some images may not contain this tool or may not have it working properly.
+For instance calling `notify-send` on a `fedora-36` template VM gives:
 ```
 Failed to execute child process “dbus-launch” (No such file or directory)
 ```
@@ -43,8 +43,8 @@ To check this tool is working properly run:
 ```bash
 sudo notify-send "$(hostname): Test notify-send OK" --icon=network-idle
 ```
-You should see `info` message appear on the top of your screen.
-If that is the case then, `notify-send` is not the issue.
+You should see the `info` message appear on the top of your screen.
+If that is the case then `notify-send` is not the issue.
 If it is not, and you have an error of some sort you can:
-1. Remove all calls of `notify-send` from scripts you are using to start VPN
-2. Use other template VM that have `notify-send` working or find proper guide and make your current template VM run `notify-send` work properly.
+1. Remove all calls to `notify-send` from scripts you are using to start VPN
+2. Use another template qube that has a working `notify-send` or find proper guide and make your current template run `notify-send` work properly.

From 0c4d924d2152cc0179e75557bb5739c2c48929a3 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Fri, 2 May 2025 15:00:25 +0000
Subject: [PATCH 303/332] Update release notes link to head API

---
 developer/releases/4_0/release-notes.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/developer/releases/4_0/release-notes.md b/developer/releases/4_0/release-notes.md
index ca97ac0d..56b99d64 100644
--- a/developer/releases/4_0/release-notes.md
+++ b/developer/releases/4_0/release-notes.md
@@ -9,7 +9,7 @@ title: Qubes R4.0 release notes
 New features since 3.2
 ----------------------
 
-* Core management scripts rewrite with better structure and extensibility, [API documentation](https://dev.qubes-os.org/en/latest/index.html)
+* Core management scripts rewrite with better structure and extensibility, [API documentation](https://dev.qubes-os.org/projects/core-admin/en/latest/index.html)
 * [Admin API](/news/2017/06/27/qubes-admin-api/) allowing strictly controlled managing from non-dom0
 * All `qvm-*` command-line tools rewritten, some options have changed
 * Renaming VM directly is prohibited, there is GUI to clone under new name and remove old VM

From 690d2898862903c6151031d27ec135c77e2fb658 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sun, 4 May 2025 12:16:00 +0000
Subject: [PATCH 304/332] Update Debian page to make it clear that the Debian
 template from 4.2.4 cannot be used for salting other qubes.

---
 user/templates/debian/debian.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/user/templates/debian/debian.md b/user/templates/debian/debian.md
index 9fa94cdf..c070791d 100644
--- a/user/templates/debian/debian.md
+++ b/user/templates/debian/debian.md
@@ -60,7 +60,9 @@ This section contains notes about specific Debian releases.
 
 ### Debian 12
 
-If you want to use a Debian 12 template for salting Qubes, you **must** stop the salt-common and salt-ssh packages from being upgraded.
+The Debian-12 templates that ship with release 4.2.4 cannot be used for salting Fedora templates. You must change the template used by `default-mgmt-dvm` to a Fedora template. You can do this in the Qubes Template Switcher tool, or at the command line using `qvm-prefs default-mgmt-dvm template`.
+
+If you have a Debian template from an earlier release that you want to use for salting Qubes, you **must** stop the salt-common and salt-ssh packages from being upgraded.
 Do this by marking these packages on hold *before* updating the template.
 
 ```

From b7dd717ee7ac19df7a510451a1e72c5d7aa38c7d Mon Sep 17 00:00:00 2001
From: Woolfgm <160153877+Dahka2321@users.noreply.github.com>
Date: Sun, 11 May 2025 13:01:27 +0200
Subject: [PATCH 305/332] Update insurgo-privacybeast-x230.md

---
 user/hardware/certified-hardware/insurgo-privacybeast-x230.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/hardware/certified-hardware/insurgo-privacybeast-x230.md b/user/hardware/certified-hardware/insurgo-privacybeast-x230.md
index 0e1a0f67..1826f7a3 100644
--- a/user/hardware/certified-hardware/insurgo-privacybeast-x230.md
+++ b/user/hardware/certified-hardware/insurgo-privacybeast-x230.md
@@ -19,7 +19,7 @@ The [Insurgo PrivacyBeast X230](https://insurgo.ca/produit/qubesos-certified-pri
 
 - [coreboot](https://www.coreboot.org/) initialization for the x230 is binary-blob-free, including native graphic initialization. Built with the [Heads](https://github.com/osresearch/heads/) payload, it delivers an [Anti Evil Maid (AEM)](/doc/anti-evil-maid/)-like solution built into the firmware. (Even though our [requirements](/doc/certified-hardware/#hardware-certification-requirements) provide an exception for CPU-vendor-provided blobs for silicon and memory initialization, Insurgo exceeds our requirements by insisting that these be absent from its machines.)
 
-- [Intel ME](https://libreboot.org/faq.html#intelme) is neutered through the AltMeDisable bit, while all modules other than ROMP and BUP, which are required to initialize main CPU, have been [deleted](https://github.com/osresearch/heads-wiki/blob/master/Clean-the-ME-firmware.md#how-to-disabledeactive-most-of-it).
+- [Intel ME](https://libreboot.org/faq.html#intelme) is neutered through the AltMeDisable bit, while all modules other than ROMP and BUP, which are required to initialize main CPU, have been [deleted](https://github.com/linuxboot/heads-wiki/blob/master/Installing-and-Configuring/Flashing-Guides/Clean-the-ME-firmware.md#how-to-disabledeactive-most-of-it).
 
 - A re-ownership process that allows it to ship pre-installed with Qubes OS, including full-disk encryption already in place, but where the final disk encryption key is regenerated only when the machine is first powered on by the user, so that the OEM doesn't know it.
 

From fa23b34a246fee969841be607bb42d660a583e3c Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sun, 11 May 2025 11:46:13 +0000
Subject: [PATCH 306/332] Revert "Update documentation on split-gpg2"

This reverts commit 0062dfaa37923d87449073daa9f59775e4f78514, reversing
changes made to 7167897d71f4b84abf52798605bd98396d1628d4.

Retain documentation on split-gpg and add page on split-gpg-v2 as well,
until latter page is fully functional.
---
 user/security-in-qubes/split-gpg.md | 408 ++++++++++++++++++++++------
 1 file changed, 322 insertions(+), 86 deletions(-)

diff --git a/user/security-in-qubes/split-gpg.md b/user/security-in-qubes/split-gpg.md
index f31d1552..637b068f 100644
--- a/user/security-in-qubes/split-gpg.md
+++ b/user/security-in-qubes/split-gpg.md
@@ -37,123 +37,359 @@ Unfortunately this problem of signing reliability is not solvable by Split GPG.)
 With Qubes Split GPG this problem is drastically minimized, because each time the key is to be used the user is asked for consent (with a definable time out, 5 minutes by default), plus is always notified each time the key is used via a tray notification from the domain where GPG backend is running.
 This way it would be easy to spot unexpected requests to decrypt documents.
 
-## Configuration
+[![r2-split-gpg-1.png](/attachment/doc/r2-split-gpg-1.png)](/attachment/doc/r2-split-gpg-1.png)
+[![r2-split-gpg-3.png](/attachment/doc/r2-split-gpg-3.png)](/attachment/doc/r2-split-gpg-3.png)
 
-Create/Edit `/etc/qubes/policy.d/30-user-gpg2.policy` in dom0, and add a line like this:
+## Configuring Split GPG
+
+In dom0, make sure the `qubes-gpg-split-dom0` package is installed.
 
 ```
-qubes.Gpg2 + gpg-client-vm @default allow target=gpg-server-vm
+[user@dom0 ~]$ sudo qubes-dom0-update qubes-gpg-split-dom0
 ```
 
-Import/Generate your secret keys in the server domain.
-For example:
+Make sure you have the `qubes-gpg-split` package installed in the template you will use for the GPG domain.
+
+For Debian or Whonix:
 
 ```
-gpg-server-vm$ gpg --import /path/to/my/secret-keys-export
-gpg-server-vm$ gpg --import-ownertrust /path/to/my/ownertrust-export
-```
-or
-
-```
-gpg-server-vm$ gpg --gen-key
+[user@debian-10 ~]$ sudo apt install qubes-gpg-split
 ```
 
-In dom0 enable the `split-gpg2-client` service in the client domain, for example via the command-line:
-
-```shell
-dom0$ qvm-service <SPLIT_GPG2_CLIENT_DOMAIN_NAME> split-gpg2-client on
-```
-
-To verify if this was done correctly:
-
-```shell
-dom0$ qvm-service <SPLIT_GPG2_CLIENT_DOMAIN_NAME>
-```
-
-Output should be:
-
-```shell
-split-gpg2-client on
-```
-
-Restart the client domain.
-
-Export the **public** part of your keys and import them in the client domain.
-Also import/set proper "ownertrust" values.
-For example:
+For Fedora:
 
 ```
-gpg-server-vm$ gpg --export > public-keys-export
-gpg-server-vm$ gpg --export-ownertrust > ownertrust-export
-gpg-server-vm$ qvm-copy public-keys-export ownertrust-export
-
-gpg-client-vm$ gpg --import ~/QubesIncoming/gpg-server-vm/public-keys-export
-gpg-client-vm$ gpg --import-ownertrust ~/QubesIncoming/gpg-server-vm/ownertrust-export
+[user@fedora-32 ~]$ sudo dnf install qubes-gpg-split
 ```
 
-This should be enough to have it running:
+### Setting up the GPG backend domain
+
+First, create a dedicated app qube for storing your keys (we will be calling it the GPG backend domain).
+It is recommended that this domain be network disconnected (set its netvm to `none`) and only used for this one purpose.
+In later examples this app qube is named `work-gpg`, but of course it might have any other name.
+
+Make sure that gpg is installed there.
+At this stage you can add the private keys you want to store there, or you can now set up Split GPG and add the keys later.
+To check which private keys are in your GPG keyring, use:
+
+```shell_session
+[user@work-gpg ~]$ gpg -K
+/home/user/.gnupg/secring.gpg
+-----------------------------
+sec   4096R/3F48CB21 2012-11-15
+uid                  Qubes OS Security Team <security@qubes-os.org>
+ssb   4096R/30498E2A 2012-11-15
+(...)
 ```
-gpg-client-vm$ gpg -K
+
+This is pretty much all that is required.
+However, you might want to modify the default timeout: this tells the backend for how long the user's approval for key access should be valid.
+(The default is 5 minutes.) You can change this via the `QUBES_GPG_AUTOACCEPT` environment variable.
+You can override it e.g. in `~/.profile`:
+
+```shell_session
+[user@work-gpg ~]$ echo "export QUBES_GPG_AUTOACCEPT=86400" >> ~/.profile
+```
+
+Please note that previously, this parameter was set in ~/.bash_profile.
+This will no longer work.
+If you have the parameter set in ~/.bash_profile you *must* update your configuration.
+
+Please be aware of the caveat regarding passphrase-protected keys in the [Current limitations](#current-limitations) section.
+
+### Configuring the client apps to use Split GPG backend
+
+Normally it should be enough to set the `QUBES_GPG_DOMAIN` to the GPG backend domain name and use `qubes-gpg-client` in place of `gpg`, e.g.:
+
+```shell_session
+[user@work-email ~]$ export QUBES_GPG_DOMAIN=work-gpg
+[user@work-email ~]$ gpg -K
+[user@work-email ~]$ qubes-gpg-client -K
+/home/user/.gnupg/secring.gpg
+-----------------------------
+sec   4096R/3F48CB21 2012-11-15
+uid                  Qubes OS Security Team <security@qubes-os.org>
+ssb   4096R/30498E2A 2012-11-15
+(...)
+
+[user@work-email ~]$ qubes-gpg-client secret_message.txt.asc
+(...)
+```
+
+Note that running normal `gpg -K` in the demo above shows no private keys stored in this app qube.
+
+A note on `gpg` and `gpg2`:
+
+Throughout this guide, we refer to `gpg`, but note that Split GPG uses `gpg2` under the hood for compatibility with programs like Enigmail (which now supports only `gpg2`).
+If you encounter trouble while trying to set up Split GPG, make sure you're using `gpg2` for your configuration and testing, since keyring data may differ between the two installations.
+
+### Advanced Configuration
+
+The `qubes-gpg-client-wrapper` script sets the `QUBES_GPG_DOMAIN` variable automatically based on the content of the file `/rw/config/gpg-split-domain`, which should be set to the name of the GPG backend VM. This file survives the app qube reboot, of course.
+
+```shell_session
+[user@work-email ~]$ sudo bash
+[root@work-email ~]$ echo "work-gpg" > /rw/config/gpg-split-domain
+```
+
+Split GPG's default qrexec policy requires the user to enter the name of the app qube containing GPG keys on each invocation. To improve usability for applications like Thunderbird with Enigmail, in `dom0` place the following line at the top of the file `/etc/qubes-rpc/policy/qubes.Gpg`:
+
+```
+work-email  work-gpg  allow
+```
+
+where `work-email` is the Thunderbird + Enigmail app qube and `work-gpg` contains your GPG keys.
+
+You may also edit the qrexec policy file for Split GPG in order to tell Qubes your default gpg vm (qrexec prompts will appear with the gpg vm preselected as the target, instead of the user needing to type a name in manually). To do this, append `default_target=<vmname>` to `ask` in `/etc/qubes-rpc/policy/qubes.Gpg`. For the examples given on this page:
+
+```
+@anyvm  @anyvm  ask default_target=work-gpg
+```
+
+Note that, because this makes it easier to accept Split GPG's qrexec authorization prompts, it may decrease security if the user is not careful in reviewing presented prompts. This may also be inadvisable if there are multiple app qubes with Split GPG set up.
+
+## Using Thunderbird
+
+### Thunderbird 78 and higher
+
+Starting with version 78, Thunderbird has a built-in PGP feature and no longer requires the Enigmail extension. For users coming from the Enigmail extension, the built-in functionality is more limited currently, including that **public keys must live in your `work-email` qube with Thunderbird rather than your offline `work-gpg` qube**.
+
+In `work-email`, use the Thunderbird config editor (found at the bottom of preferences/options), and search for `mail.openpgp.allow_external_gnupg`. Switch the value to true. Still in config editor, search for `mail.openpgp.alternative_gpg_path`. Set its value to `/usr/bin/qubes-gpg-client-wrapper`. Restart Thunderbird after this change.
+
+[![tb78-1.png](/attachment/doc/tb78-1.png)](/attachment/doc/tb78-1.png)
+[![tb78-2.png](/attachment/doc/tb78-2.png)](/attachment/doc/tb78-2.png)
+[![tb78-3.png](/attachment/doc/tb78-3.png)](/attachment/doc/tb78-3.png)
+
+You need to obtain your key ID which should be **exactly 16 characters**. Enter the command `qubes-gpg-client-wrapper -K --keyid-format long`:
+
+```
+[user@work-email ~]$ qubes-gpg-client-wrapper -K --keyid-format long
 /home/user/.gnupg/pubring.kbx
 -----------------------------
-sec#  rsa2048 2019-12-18 [SC] [expires: 2021-12-17]
-      50C2035AF57B98CD6E4010F1B808E4BB07BA9EFB
-uid           [ultimate] test
-ssb#  rsa2048 2019-12-18 [E]
+sec   rsa2048/777402E6D301615C 2020-09-05 [SC] [expires: 2022-09-05]
+      F7D2D4E922DFB7B2589AF3E9777402E6D301615C
+uid                 [ultimate] Qubes test <user@localhost>
+ssb   rsa2048/370CE932085BA13B 2020-09-05 [E] [expires: 2022-09-05]
 ```
 
-If you want change some server option copy `/usr/share/doc/split-gpg2/examples/qubes-split-gpg2.conf.example` to `~/.config/qubes-split-gpg2/qubes-split-gpg2.conf` and change it as desired, it will take precedence over other loaded files, such as the drop-in configuration files with the suffix `.conf` in `~/.config/qubes-split-gpg2/conf.d/`.
+```
+[user@work-email ~]$ qubes-gpg-client-wrapper --armor --export 777402E6D301615C > 777402E6D301615C.asc
+```
 
-If you have a passphrase on your keys and `gpg-agent` only shows the "keygrip" (something like the fingerprint of the private key) when asking for the passphrase, then make sure that you have imported the public key part in the server domain.
+Open the Account Settings and open the *End-to-End Encryption* tab of the respective email account. Click the *Add Key* button. You'll be offered the choice *Use your external key through GnuPG*. Select it and click Continue.
 
-## Subkeys vs primary keys
+[![tb78-4.png](/attachment/doc/tb78-4.png)](/attachment/doc/tb78-4.png)
+[![tb78-5.png](/attachment/doc/tb78-5.png)](/attachment/doc/tb78-5.png)
 
-split-gpg2 only knows a hash of the data being signed.
-Therefore, it cannot differentiate between e.g. signatures of a piece of data or signatures of another key.
-This means that a client can use split-gpg2 to sign other keys, which split-gpg1 did not allow.
+The key ID reference you would need here is `777402E6D301615C`. Now paste or type the ID of the secret key that you would like to use. Be careful to enter it correctly, because your input isn't verified. Confirm to save this key ID. Now you can select the key ID to use.
 
-To prevent this, split-gpg2 creates a new GnuPG home directory and imports the secret subkeys (**not** the primary key!) to it.
-Clients will be able to use the secret parts of the subkeys, but not of the primary key.
-If your primary key is able to sign data and certify other keys, and your only subkey can only perform encryption, this means that all signing will fail.
-To make signing work again, generate a subkey that is capable of signing but **not** certification.
-split-gpg2 does not generate this key for you, so you need to generate it yourself.
-If you want to generate a key in software, use the `addkey` command of `gpg2 --edit-key`.
-If you want to generate a key on a smartcard or other hardware token, use `addcardkey` instead.
+[![tb78-6.png](/attachment/doc/tb78-6.png)](/attachment/doc/tb78-6.png)
+[![tb78-7.png](/attachment/doc/tb78-7.png)](/attachment/doc/tb78-7.png)
 
-## Advanced usage
+This key ID will be used to digitally sign or send an encrypted message with your account. For this to work, Thunderbird needs a copy of your public key. At this time, Thunderbird doesn't fetch the public key from `/usr/bin/qubes-gpg-client-wrapper`, you must manually import it. Export the key as follow (assuming the key ID would be `777402E6D301615C`):
 
-There are a few option not described in this README.
-See the comments in the example (config and the source code)[https://github.com/QubesOS/qubes-app-linux-split-gpg2/blob/main/qubes-split-gpg2.conf.example].
+[![tb78-8.png](/attachment/doc/tb78-8.png)](/attachment/doc/tb78-8.png)
+[![tb78-9.png](/attachment/doc/tb78-9.png)](/attachment/doc/tb78-9.png)
 
-Similar to a smartcard, split-gpg2 only tries to protect the private key.
-For advanced usages, consider if a specialized RPC service would be better.
-It could do things like checking what data is singed, detailed logging, exposing the encrypted content only to a VM without network, etc.
+Use Thunderbird's Tools menu to open *OpenPGP Key Management*. In that window, use the File menu to access the *Import Public Key(s) From File* command. Open the file with your public key. After the import was successful, right click on the imported key in the list and select *Key Properties*. You must mark your own key as *Yes, I've verified in person this key has the correct fingerprint*.
 
-Using split-gpg2 as the "backend" for split-gpg1 is known to work.
+Once this is done, you should be able to send an encrypted and signed email by selecting *Require Encryption* or *Digitally Sign This Message* in the compose menu *Options* or *Security* toolbar button. You can try it by sending an email to yourself.
 
-## Allow key generation
+[![tb78-10.png](/attachment/doc/tb78-10.png)](/attachment/doc/tb78-10.png)
 
-By setting `allow_keygen = yes` in `qubes-split-gpg2.conf` you can allow the client to generate new keys.
-Normal usage should not need this.
+For more details about using smart cards/Split GPG with Thunderbird PGP feature, please see [Thunderbird:OpenPGP:Smartcards](https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards) from which the above documentation is inspired.
 
-**Warning**: This feature is new and not much tested.
-Therefore it's not security supported!
+### Older Thunderbird versions
 
-## Copyright
+For Thunderbird versions below 78, the traditional Enigmail + Split GPG setup is required.
+It is recommended to set up and use `/usr/bin/qubes-gpg-client-wrapper`, as discussed above, in Thunderbird through the Enigmail addon.
 
-Copyright (C) 2014 HW42 <hw42@ipsumj.de>\
-Copyright (C) 2019 Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
+**Warning:** Before adding any account, configuring Enigmail with `/usr/bin/qubes-gpg-client-wrapper` is **required**. By default, Enigmail will generate a default GPG key in `work-email` associated with the newly created Thunderbird account. Generally, it corresponds to the email used in `work-gpg` associated to your private key. In consequence, a new, separate private key will be stored in `work-email` but it _does not_ correspond to your private key in `work-gpg`. Comparing the `fingerprint` or `expiration date` will show that they are not the same private key. In order to prevent Enigmail using this default generated local key in `work-email`, you can safely remove it.
 
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
+On a fresh Enigmail install, your need to change the default `Enigmail Junior Mode`. Go to Thunderbird preferences and then privacy tab. Select `Force using S/MIME and Enigmail`. Then, in the preferences of Enigmail, make it point to `/usr/bin/qubes-gpg-client-wrapper` instead of the standard GnuPG binary:
 
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
+[![tb-enigmail-split-gpg-settings-2.png](/attachment/doc/tb-enigmail-split-gpg-settings-2.png)](/attachment/doc/tb-enigmail-split-gpg-settings-2.png)
 
-You should have received a copy of the GNU General Public License along
-with this program; if not, write to the Free Software Foundation, Inc.,
-51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
\ No newline at end of file
+## Using Keybase with Split GPG
+
+Keybase, a security focused messaging and file-sharing app with GPG integration, can be configured to use Split GPG.
+
+The Keybase service does not preserve/pass the `QUBES_GPG_DOMAIN` environment variable through to underlying GPG processes, so it **must** be configured to use `/usr/bin/qubes-gpg-client-wrapper` (as discussed above) rather than `/usr/bin/qubes-gpg-client`.
+
+The following command will configure Keybase to use `/usr/bin/qubes-gpg-client-wrapper` instead of its built-in GPG client:
+
+```
+$ keybase config set gpg.command /usr/bin/qubes-gpg-client-wrapper
+```
+
+Now that Keybase is configured to use `qubes-gpg-client-wrapper`, you will be able to use `keybase pgp select` to choose a GPG key from your backend GPG app qube and link that key to your Keybase identity.
+
+## Using Git with Split GPG
+
+Git can be configured to utilize Split GPG, something useful if you would like to contribute to the Qubes OS Project as every commit is required to be signed.
+The most basic `~/.gitconfig` file enabling Split GPG looks something like this.
+
+```
+[user]
+	name = <YOUR_NAME>
+	email = <YOUR_EMAIL_ADDRESS>
+	signingKey = <YOUR_KEY_ID>
+
+[gpg]
+	program = qubes-gpg-client-wrapper
+```
+
+Your key id is the public id of your signing key, which can be found by running `qubes-gpg-client --list-keys`.
+In this instance, the key id is E142F75A6B1B610E0E8F874FB45589245791CACB.
+
+```shell_session
+[user@work-email ~]$ qubes-gpg-client --list-keys
+/home/user/.gnupg/pubring.kbx
+-----------------------------
+pub   ed25519 2022-08-16 [C]
+      E142F75A6B1B610E0E8F874FB45589245791CACB
+uid           [ultimate] Qubes User <user@example.com>
+sub   ed25519 2022-08-16 [S]
+sub   cv25519 2022-08-16 [E]
+sub   ed25519 2022-08-16 [A]
+```
+
+To sign commits, you now add the "-S" flag to your commit command, which should prompt for Split GPG usage.
+If you would like to automatically sign all commits, you can add the following snippet to `~/.gitconfig`.
+
+```
+[commit]
+	gpgSign = true
+```
+
+Lastly, if you would like to add aliases to sign and verify tags using the conventions the Qubes OS Project recommends, refer to the [code signing documentation](/doc/code-signing/#using-pgp-with-git).
+
+## Importing public keys
+
+Use `qubes-gpg-import-key` in the client app qube to import the key into the GPG backend VM.
+
+```shell_session
+[user@work-email ~]$ export QUBES_GPG_DOMAIN=work-gpg
+[user@work-email ~]$ qubes-gpg-import-key ~/Downloads/marmarek.asc
+```
+
+A safe, unspoofable user consent dialog box is displayed.
+
+[![r2-split-gpg-5.png](/attachment/doc/r2-split-gpg-5.png)](/attachment/doc/r2-split-gpg-5.png)
+
+Selecting "Yes to All" will add a line in the corresponding [RPC Policy](/doc/rpc-policy/) file.
+
+## Advanced: Using Split GPG with Subkeys
+
+Users with particularly high security requirements may wish to use Split GPG with [subkeys](https://wiki.debian.org/Subkeys).
+However, this setup comes at a significant cost: It will be impossible to sign other people's keys with the master secret key without breaking this security model.
+Nonetheless, if signing others' keys is not required, then Split GPG with subkeys offers unparalleled security for one's master secret key.
+
+### Setup Description
+
+In this example, the following keys are stored in the following locations (see below for definitions of these terms):
+
+| PGP Key(s) | VM Name      |
+| ---------- | ------------ |
+| `sec`      | `vault`      |
+| `ssb`      | `work-gpg`   |
+| `pub`      | `work-email` |
+
+* `sec` (master secret key)
+
+   Depending on your needs, you may wish to create this as a **certify-only (C)** key, i.e., a key which is capable only of signing (a.k.a., "certifying") other keys.
+   This key may be created *without* an expiration date.
+   This is for two reasons.
+   First, the master secret key is never to leave the `vault` VM, so it is extremely unlikely ever to be obtained by an adversary (see below).
+   Second, an adversary who *does* manage to obtain the master secret key either possesses the passphrase to unlock the key (if one is used) or does not.
+   An adversary who *does* possess the passphrase can simply use it to legally extend the expiration date of the key (or remove it entirely).
+   An adversary who does *not* possess the passphrase cannot use the key at all.
+   In either case, an expiration date provides no additional benefit.
+
+   By the same token, however, having a passphrase on the key is of little value.
+   An adversary who is capable of stealing the key from your `vault` would almost certainly also be capable of stealing the passphrase as you enter it.
+   An adversary who obtains the passphrase can then use it in order to change or remove the passphrase from the key.
+   Therefore, using a passphrase at all should be considered optional.
+   It is, however, recommended that a **revocation certificate** be created and safely stored in multiple locations so that the master keypair can be revoked in the (exceedingly unlikely) event that it is ever compromised.
+
+* `ssb` (secret subkey)
+
+   Depending on your needs, you may wish to create two different subkeys: one for **signing (S)** and one for **encryption (E)**.
+   You may also wish to give these subkeys reasonable expiration dates (e.g., one year).
+   Once these keys expire, it is up to you whether to *renew* these keys by extending the expiration dates or to create *new* subkeys when the existing set expires.
+
+   On the one hand, an adversary who obtains any existing encryption subkey (for example) will be able to use it in order to decrypt all emails (for example) which were encrypted to that subkey.
+   If the same subkey were to continue to be used--and its expiration date continually extended--only that one key would need to be stolen (e.g., as a result of the `work-gpg` VM being compromised; see below) in order to decrypt *all* of the user's emails.
+   If, on the other hand, each encryption subkey is used for at most approximately one year, then an adversary who obtains the secret subkey will be capable of decrypting at most approximately one year's worth of emails.
+
+   On the other hand, creating a new signing subkey each year without renewing (i.e., extending the expiration dates of) existing signing subkeys would mean that all of your old signatures would eventually read as "EXPIRED" whenever someone attempts to verify them.
+   This can be problematic, since there is no consensus on how expired signatures should be handled.
+   Generally, digital signatures are intended to last forever, so this is a strong reason against regularly retiring one's signing subkeys.
+
+* `pub` (public key)
+
+   This is the complement of the master secret key.
+   It can be uploaded to keyservers (or otherwise publicly distributed) and may be signed by others.
+
+* `vault`
+
+   This is a network-isolated VM.
+   The initial master keypair and subkeys are generated in this VM.
+   The master secret key *never* leaves this VM under *any* circumstances.
+   No files or text is *ever* [copied](/doc/how-to-copy-and-move-files/#security) or [pasted](/doc/how-to-copy-and-paste-text/#security) into this VM under *any* circumstances.
+
+* `work-gpg`
+
+   This is a network-isolated VM.
+   This VM is used *only* as the GPG backend for `work-email`.
+   The secret subkeys (but *not* the master secret key) are [copied](/doc/how-to-copy-and-move-files/#security) from the `vault` VM to this VM.
+   Files from less trusted VMs are *never* [copied](/doc/how-to-copy-and-move-files/#security) into this VM under *any* circumstances.
+
+* `work-email`
+
+   This VM has access to the mail server.
+   It accesses the `work-gpg` VM via the Split GPG protocol.
+   The public key may be stored in this VM so that it can be attached to emails and for other such purposes.
+
+### Security Benefits
+
+In the standard Split GPG setup, there are at least two ways in which the `work-gpg` VM might be compromised.
+First, an attacker who is capable of exploiting a hypothetical bug in `work-email`'s [MUA](https://en.wikipedia.org/wiki/Mail_user_agent) could gain control of the `work-email` VM and send a malformed request which exploits a hypothetical bug in the GPG backend (running in the `work-gpg` VM), giving the attacker control of the `work-gpg` VM.
+Second, a malicious public key file which is imported into the `work-gpg` VM might exploit a hypothetical bug in the GPG backend which is running there, again giving the attacker control of the `work-gpg` VM.
+In either case, such an attacker might then be able to leak both the master secret key and its passphrase (if any is used, it would regularly be input in the work-gpg VM and therefore easily obtained by an attacker who controls this VM) back to the `work-email` VM or to another VM (e.g., the `netvm`, which is always untrusted by default) via the Split GPG protocol or other [covert channels](/doc/data-leaks/).
+Once the master secret key is in the `work-email` VM, the attacker could simply email it to himself (or to the world).
+
+In the alternative setup described in this section (i.e., the subkey setup), even an attacker who manages to gain access to the `work-gpg` VM will not be able to obtain the user's master secret key since it is simply not there.
+Rather, the master secret key remains in the `vault` VM, which is extremely unlikely to be compromised, since nothing is ever copied or transferred into it.
+[^a-note] The attacker might nonetheless be able to leak the secret subkeys from the `work-gpg` VM in the manner described above, but even if this is successful, the secure master secret key can simply be used to revoke the compromised subkeys and to issue new subkeys in their place.
+(This is significantly less devastating than having to create a new *master* keypair.)
+
+[^a-note]: In order to gain access to the `vault` VM, the attacker would require the use of, e.g., a general Xen VM escape exploit or a [signed, compromised package which is already installed in the template](/doc/templates/#trusting-your-templates) upon which the `vault` VM is based.
+
+### Subkey Tutorials and Discussions
+
+(Note: Although the tutorials below were not written with Qubes Split GPG in mind, they can be adapted with a few commonsense adjustments.
+As always, exercise caution and use your good judgment.)
+
+* ["OpenPGP in Qubes OS" on the qubes-users mailing list](https://groups.google.com/d/topic/qubes-users/Kwfuern-R2U/discussion)
+* ["Creating the Perfect GPG Keypair" by Alex Cabal](https://alexcabal.com/creating-the-perfect-gpg-keypair/)
+* ["GPG Offline Master Key w/ smartcard" maintained by Abel Luck](https://gist.github.com/abeluck/3383449)
+* ["Using GnuPG with QubesOS" by Alex](https://apapadop.wordpress.com/2013/08/21/using-gnupg-with-qubesos/)
+
+## Current limitations
+
+* Current implementation requires importing of public keys to the vault domain.
+  This opens up an avenue to attack the gpg running in the backend domain via a hypothetical bug in public key importing code.
+  See ticket [#474](https://github.com/QubesOS/qubes-issues/issues/474) for more details and plans how to get around this problem, as well as the section on [using Split GPG with subkeys](#advanced-using-split-gpg-with-subkeys).
+
+* It doesn't solve the problem of allowing the user to know what is to be signed before the operation gets approved.
+  Perhaps the GPG backend domain could start a disposable and have the to-be-signed document displayed there? To Be Determined.
+
+* The Split GPG client will fail to sign or encrypt if the private key in the GnuPG backend is protected by a passphrase.
+  It will give an `Inappropriate ioctl for device` error.
+  Do not set passphrases for the private keys in the GPG backend domain.
+  Doing so won't provide any extra security anyway, as explained in the introduction and in [using Split GPG with subkeys](#advanced-using-split-gpg-with-subkeys).
+  If you are generating a new key pair, or if you have a private key that already has a passphrase, you can use `gpg2 --edit-key <key_id>` then `passwd` to set an empty passphrase.
+  Note that `pinentry` might show an error when you try to set an empty passphrase, but it will still make the change.
+  (See [this StackExchange answer](https://unix.stackexchange.com/a/379373) for more information.)
+  Note: The error shows only if you **do not** have graphical pinentry installed.

From ec6f975c82711d37be17934fc4c744b38018adec Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sun, 11 May 2025 12:07:51 +0000
Subject: [PATCH 307/332] Add separate page for split-gpg-2

---
 user/security-in-qubes/split-gpg-2.md | 157 ++++++++++++++++++++++++++
 1 file changed, 157 insertions(+)
 create mode 100644 user/security-in-qubes/split-gpg-2.md

diff --git a/user/security-in-qubes/split-gpg-2.md b/user/security-in-qubes/split-gpg-2.md
new file mode 100644
index 00000000..68cdb3aa
--- /dev/null
+++ b/user/security-in-qubes/split-gpg-2.md
@@ -0,0 +1,157 @@
+---
+lang: en
+layout: doc
+permalink: /doc/split-gpg-2/
+redirect_from:
+- /en/doc/split-gpg-2/
+- /doc/SplitGpg-2/
+- /doc/UserDoc/SplitGpg-2/
+- /doc/open-pgp-2/
+- /en/doc/open-pgp-2/
+- /doc/OpenPGP-2/
+- /doc/UserDoc/OpenPGP-2/
+ref: 568
+title: Split GPG-2
+---
+
+Split GPG implements a concept similar to having a smart card with your private GPG keys, except that the role of the "smart card" is played by another Qubes app qube.
+This way one not-so-trusted domain, e.g. the one where Thunderbird is running, can delegate all crypto operations -- such as encryption/decryption and signing -- to another, more trusted, network-isolated domain.
+This way the compromise of your domain where Thunderbird or another client app is running -- arguably a not-so-unthinkable scenario -- does not allow the attacker to automatically also steal all your keys.
+(We should make a rather obvious comment here that the so-often-used passphrases on private keys are pretty meaningless because the attacker can easily set up a simple backdoor which would wait until the user enters the passphrase and steal the key then.)
+
+[![split-gpg-diagram.png](/attachment/doc/split-gpg-diagram.png)](/attachment/doc/split-gpg-diagram.png)
+
+This diagram presents an overview of the Split GPG architecture.
+
+## Advantages of Split GPG vs. traditional GPG with a smart card
+
+It is often thought that the use of smart cards for private key storage guarantees ultimate safety.
+While this might be true (unless the attacker can find a usually-very-expensive-and-requiring-physical-presence way to extract the key from the smart card) but only with regards to the safety of the private key itself.
+However, there is usually nothing that could stop the attacker from requesting the smart card to perform decryption of all the user documents the attacker has found or need to decrypt.
+In other words, while protecting the user's private key is an important task, we should not forget that ultimately it is the user data that are to be protected and that the smart card chip has no way of knowing the requests to decrypt documents are now coming from the attacker's script and not from the user sitting in front of the monitor.
+(Similarly the smart card doesn't make the process of digitally signing a document or a transaction in any way more secure -- the user cannot know what the chip is really signing.
+Unfortunately this problem of signing reliability is not solvable by Split GPG.)
+
+With Qubes Split GPG this problem is drastically minimized, because each time the key is to be used the user is asked for consent (with a definable time out, 5 minutes by default), plus is always notified each time the key is used via a tray notification from the domain where GPG backend is running.
+This way it would be easy to spot unexpected requests to decrypt documents.
+
+## Configuration
+
+Create/Edit `/etc/qubes/policy.d/30-user-gpg2.policy` in dom0, and add a line like this:
+
+```
+qubes.Gpg2 + gpg-client-vm @default allow target=gpg-server-vm
+```
+
+Import/Generate your secret keys in the server domain.
+For example:
+
+```
+gpg-server-vm$ gpg --import /path/to/my/secret-keys-export
+gpg-server-vm$ gpg --import-ownertrust /path/to/my/ownertrust-export
+```
+or
+
+```
+gpg-server-vm$ gpg --gen-key
+```
+
+In dom0 enable the `split-gpg2-client` service in the client domain, for example via the command-line:
+
+```shell
+dom0$ qvm-service <SPLIT_GPG2_CLIENT_DOMAIN_NAME> split-gpg2-client on
+```
+
+To verify if this was done correctly:
+
+```shell
+dom0$ qvm-service <SPLIT_GPG2_CLIENT_DOMAIN_NAME>
+```
+
+Output should be:
+
+```shell
+split-gpg2-client on
+```
+
+Restart the client domain.
+
+Export the **public** part of your keys and import them in the client domain.
+Also import/set proper "ownertrust" values.
+For example:
+
+```
+gpg-server-vm$ gpg --export > public-keys-export
+gpg-server-vm$ gpg --export-ownertrust > ownertrust-export
+gpg-server-vm$ qvm-copy public-keys-export ownertrust-export
+
+gpg-client-vm$ gpg --import ~/QubesIncoming/gpg-server-vm/public-keys-export
+gpg-client-vm$ gpg --import-ownertrust ~/QubesIncoming/gpg-server-vm/ownertrust-export
+```
+
+This should be enough to have it running:
+```
+gpg-client-vm$ gpg -K
+/home/user/.gnupg/pubring.kbx
+-----------------------------
+sec#  rsa2048 2019-12-18 [SC] [expires: 2021-12-17]
+      50C2035AF57B98CD6E4010F1B808E4BB07BA9EFB
+uid           [ultimate] test
+ssb#  rsa2048 2019-12-18 [E]
+```
+
+If you want change some server option copy `/usr/share/doc/split-gpg2/examples/qubes-split-gpg2.conf.example` to `~/.config/qubes-split-gpg2/qubes-split-gpg2.conf` and change it as desired, it will take precedence over other loaded files, such as the drop-in configuration files with the suffix `.conf` in `~/.config/qubes-split-gpg2/conf.d/`.
+
+If you have a passphrase on your keys and `gpg-agent` only shows the "keygrip" (something like the fingerprint of the private key) when asking for the passphrase, then make sure that you have imported the public key part in the server domain.
+
+## Subkeys vs primary keys
+
+split-gpg2 only knows a hash of the data being signed.
+Therefore, it cannot differentiate between e.g. signatures of a piece of data or signatures of another key.
+This means that a client can use split-gpg2 to sign other keys, which split-gpg1 did not allow.
+
+To prevent this, split-gpg2 creates a new GnuPG home directory and imports the secret subkeys (**not** the primary key!) to it.
+Clients will be able to use the secret parts of the subkeys, but not of the primary key.
+If your primary key is able to sign data and certify other keys, and your only subkey can only perform encryption, this means that all signing will fail.
+To make signing work again, generate a subkey that is capable of signing but **not** certification.
+split-gpg2 does not generate this key for you, so you need to generate it yourself.
+If you want to generate a key in software, use the `addkey` command of `gpg2 --edit-key`.
+If you want to generate a key on a smartcard or other hardware token, use `addcardkey` instead.
+
+## Advanced usage
+
+There are a few option not described in this README.
+See the comments in the example (config and the source code)[https://github.com/QubesOS/qubes-app-linux-split-gpg2/blob/main/qubes-split-gpg2.conf.example].
+
+Similar to a smartcard, split-gpg2 only tries to protect the private key.
+For advanced usages, consider if a specialized RPC service would be better.
+It could do things like checking what data is singed, detailed logging, exposing the encrypted content only to a VM without network, etc.
+
+Using split-gpg2 as the "backend" for split-gpg1 is known to work.
+
+## Allow key generation
+
+By setting `allow_keygen = yes` in `qubes-split-gpg2.conf` you can allow the client to generate new keys.
+Normal usage should not need this.
+
+**Warning**: This feature is new and not much tested.
+Therefore it's not security supported!
+
+## Copyright
+
+Copyright (C) 2014 HW42 <hw42@ipsumj.de>\
+Copyright (C) 2019 Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License along
+with this program; if not, write to the Free Software Foundation, Inc.,
+51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

From a5b15bdf5b01682ff8e272162cc7c13d14ed5def Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sun, 11 May 2025 12:30:50 +0000
Subject: [PATCH 308/332] Add link to incomplete page on split-gpg-2 from
 current split-gpg page

---
 user/security-in-qubes/split-gpg.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/user/security-in-qubes/split-gpg.md b/user/security-in-qubes/split-gpg.md
index 637b068f..86966b2f 100644
--- a/user/security-in-qubes/split-gpg.md
+++ b/user/security-in-qubes/split-gpg.md
@@ -16,6 +16,12 @@ ref: 168
 title: Split GPG
 ---
 
+<div class="alert alert-warning" role="alert">
+  <i class="fa fa-exclamation-circle"></i>
+  <b>Note:</b> This information concerns split-gpg. 
+  The implementation has been updated to provide more features in split-gpg-2. Some incomplete information on split-gpg-2 is available <a href="https://www.qubes-os.org/doc/split-gpg-2/">here</a>
+</div>
+
 Split GPG implements a concept similar to having a smart card with your private GPG keys, except that the role of the "smart card" is played by another Qubes app qube.
 This way one not-so-trusted domain, e.g. the one where Thunderbird is running, can delegate all crypto operations -- such as encryption/decryption and signing -- to another, more trusted, network-isolated domain.
 This way the compromise of your domain where Thunderbird or another client app is running -- arguably a not-so-unthinkable scenario -- does not allow the attacker to automatically also steal all your keys.

From 9fede33dcd29058f57bae0a324e46e5a9f4f2a3d Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Tue, 13 May 2025 13:39:41 -0700
Subject: [PATCH 309/332] Remove Fedora 40 from supported templates (EOL)

---
 user/downloading-installing-upgrading/supported-releases.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/downloading-installing-upgrading/supported-releases.md b/user/downloading-installing-upgrading/supported-releases.md
index 30d8d4eb..42740d4c 100644
--- a/user/downloading-installing-upgrading/supported-releases.md
+++ b/user/downloading-installing-upgrading/supported-releases.md
@@ -57,7 +57,7 @@ It is the responsibility of each distribution to clearly notify its users in adv
 
 | Qubes OS    | Fedora | Debian |
 | ----------- | ------ | ------ |
-| Release 4.2 | 40, 41 | 12     |
+| Release 4.2 | 41     | 12     |
 
 ### Note on Debian support
 

From 07b2392c3fffe69b63b4143ac1182ed06934ce9f Mon Sep 17 00:00:00 2001
From: Woolfgm <160153877+Dahka2321@users.noreply.github.com>
Date: Wed, 14 May 2025 11:40:56 +0200
Subject: [PATCH 310/332] Update qrexec-internals.md

---
 developer/services/qrexec-internals.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/developer/services/qrexec-internals.md b/developer/services/qrexec-internals.md
index 8f0a10ac..7e05d278 100644
--- a/developer/services/qrexec-internals.md
+++ b/developer/services/qrexec-internals.md
@@ -253,4 +253,4 @@ There are two endpoints:
 - `policy.Ask` - ask the user about whether to execute a given action
 - `policy.Notify` - notify the user about an action.
 
-See [qrexec-policy-agent.rst](https://github.com/QubesOS/qubes-core-qrexec/blob/master/Documentation/qrexec-policy-agent.rst) for protocol details.
+See [qrexec-policy-agent.md](https://github.com/QubesOS/qubes-core-qrexec/blob/master/doc/qrexec-policy-agent.md) for protocol details.

From 284e6d41f4dd593e76075f5d70432356e25d24df Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Wed, 14 May 2025 19:10:54 -0400
Subject: [PATCH 311/332] format fixes

---
 developer/building/development-workflow.md  | 10 ++---
 developer/building/qubes-builder-v2.md      | 10 +++--
 user/templates/templates.md                 |  2 +-
 user/templates/windows/windows-qubes-4-1.md | 49 ++++++++++-----------
 4 files changed, 37 insertions(+), 34 deletions(-)

diff --git a/developer/building/development-workflow.md b/developer/building/development-workflow.md
index f125533f..5f1581bd 100644
--- a/developer/building/development-workflow.md
+++ b/developer/building/development-workflow.md
@@ -46,7 +46,7 @@ Don't forget to include the public PGP key you use to sign your tags.
 
 #### Prepare fresh version of kernel sources, with Qubes-specific patches applied
 
-In qubes-builder/artifacts/sources/linux-kernel:
+In `qubes-builder/artifacts/sources/linux-kernel`:
 
 ~~~
 make prep
@@ -65,7 +65,7 @@ drwxr-xr-x  6 user user 4096 Nov 21 20:48 kernel-3.4.18/linux-obj
 
 #### Go to the kernel tree and update the version
 
-In qubes-builder/artifacts/sources/linux-kernel:
+In `qubes-builder/artifacts/sources/linux-kernel`:
 
 ~~~
 cd kernel-3.4.18/linux-3.4.18
@@ -73,14 +73,14 @@ cd kernel-3.4.18/linux-3.4.18
 
 #### Changing the config
 
-In kernel-3.4.18/linux-3.4.18:
+In `kernel-3.4.18/linux-3.4.18`:
 
 ~~~
 cp ../../config .config
 make oldconfig
 ~~~
 
-Now change the configuration. For example, in kernel-3.4.18/linux-3.4.18:
+Now change the configuration. For example, in `kernel-3.4.18/linux-3.4.18`:
 
 ~~~
 make menuconfig
@@ -139,7 +139,7 @@ RPMs will appear in
 
 1. `./qb package diff` - show uncommitted changes
 2. ` ./qb repository check-release-status-for-component` and
-`./qb repository check-release-status-for-template`- show version of each
+`./qb repository check-release-status-for-template` - show version of each
    component/template (based on git tags)
 3. `./qb package sign` -  sign built packages
 4. `./qb package publish` and `./qb package upload` - publish signed packages
diff --git a/developer/building/qubes-builder-v2.md b/developer/building/qubes-builder-v2.md
index 1210910b..2ad60e9f 100644
--- a/developer/building/qubes-builder-v2.md
+++ b/developer/building/qubes-builder-v2.md
@@ -39,18 +39,20 @@ if you don't know which executor to use, use docker.
 
 2. Installing dependencies
 
-   If you want to use an app qube for developing, install dependencies in the template.
+   - If you want to use an app qube for developing, install dependencies in the template.
    If you are using a standalone, install them in the qube itself.
     Dependencies are specified in `dependencies-*.
    txt` files in the main builder directory, and you can install them easily
    in the following ways:
    1. for Fedora, use:
+
     ```shell
     $ sudo dnf install $(cat dependencies-fedora.txt)
     $ test -f /usr/share/qubes/marker-vm && sudo dnf install qubes-gpg-split
    ```
    2. for Debian (note: some Debian packages require Debian version 13 or
       later), use:
+
     ```shell
     $ sudo apt install $(cat dependencies-debian.txt)
     $ test -f /usr/share/qubes/marker-vm && sudo apt install qubes-gpg-split
@@ -60,6 +62,7 @@ if you don't know which executor to use, use docker.
     (re)start the development qube.
 
 3. Clone the qubes-builder v2 repository into a location of your choice:
+
     ```shell
     git clone https://github.com/QubesOS/qubes-builderv2
     cd qubes-builderv2/
@@ -68,12 +71,14 @@ if you don't know which executor to use, use docker.
 4. If you haven't previously used docker in the current qube, you need to set up
    some permissions. In particular, the user has to be added to the `docker`
    group:
+
     ```shell
    $ sudo usermod -aG docker user
     ```
     Next, **restart the qube**.
 
 5. Finally, you need to generate a docker image:
+
     ```shell
    $ tools/generate-container-image.sh docker
     ```
@@ -94,7 +99,7 @@ You can use one of the sample files from the `example-configs/` directory; for a
 more readable `builder.yml`, you can also include one of the files from that
 directory in your `builder.yml`. An example `builder.yml` is:
 
-```yaml
+```
 # include configuration relevant for the current release
 include:
 - example-configs/qubes-os-r4.2.yml
@@ -120,7 +125,6 @@ executor:
   type: docker
   options:
     image: "qubes-builder-fedora:latest"
-
 ```
 
 
diff --git a/user/templates/templates.md b/user/templates/templates.md
index 486c428f..c3130e68 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -175,7 +175,7 @@ $ qvm-template list --installed
 
 In either case, issues with template removal may be raised. If an issue is raised, the template will remain installed and a list of concerns displayed. "Global property default_template" requires [switching](#switching) the default_template property to another template. "Template for" can be resolved by [switching](#switching) the dependent qubes' template. Once the issues are addressed, attempt the removal again.
 
-If the template's entry in the Qubes Menu is not removed with its uninstallation, consult the [troubleshooting page](/doc/app-menu-shortcut-troubleshooting/#fixing-shortcuts).
+If the template's entry in the Qubes Menu is not removed with its uninstallation, consult the [troubleshooting page](/doc/app-menu-shortcut-troubleshooting/#what-if-a-removed-application-is-still-in-the-app-menu).
 
 ## Reinstalling
 
diff --git a/user/templates/windows/windows-qubes-4-1.md b/user/templates/windows/windows-qubes-4-1.md
index d17371df..e1a25817 100644
--- a/user/templates/windows/windows-qubes-4-1.md
+++ b/user/templates/windows/windows-qubes-4-1.md
@@ -166,37 +166,36 @@ These parameters are set for the following reasons:
     -  Close the registry editor and console windows.
     -  You will then return to the setup, which will continue normally and install Windows 11 without TPM 2.0.
 
-<div class="alert alert-warning" role="alert">
-  <i class="fa fa-exclamation-triangle"></i>
-  **Caution:** This temporary patch may cease to work if it so pleases Microsoft sometime. With version 24H2 it is still working.
-</div>
+    <div class="alert alert-warning" role="alert">
+      <i class="fa fa-exclamation-circle"></i>
+       <b>Caution:</b> This temporary patch may cease to work if it so pleases Microsoft sometime. With version 24H2 it is still working.
+    </div>
     
-    The installation of Windows 11 may require an internet connection to grab a Microsoft ID. Previously, this was true only for the home edition, but since version 24H2, it extends to the Pro edition, too. A workaround to bypass the internet connection requirements of the Windows 11 setup has been published that works for version 21H2 but may be blocked for newer versions:
+
+    - The installation of Windows 11 may require an internet connection to grab a Microsoft ID. Previously, this was true only for the home edition, but since version 24H2, it extends to the Pro edition, too. A workaround to bypass the internet connection requirements of the Windows 11 setup has been published that works for version 21H2 but may be blocked for newer versions:
     
-    - When you reach the “Let’s Connect You To A Network” page, type Shift-F10 to open a console window.
-    - Here you type `taskmgr` to start the Task Manager window so you can see all running processes.
-    - Expand the Task Manager by clicking the “More Details” button, and then find “Network Connection Flow.”
-    - Select this process and then hit the “End Task” button.
-    - Now you can close these newly opened windows and return to the Windows 11 setup, where you will enter local account information.
+      - When you reach the “Let’s Connect You To A Network” page, type Shift-F10 to open a console window.
+      - Here you type `taskmgr` to start the Task Manager window so you can see all running processes.
+      - Expand the Task Manager by clicking the “More Details” button, and then find “Network Connection Flow.”
+      - Select this process and then hit the “End Task” button.
+      - Now you can close these newly opened windows and return to the Windows 11 setup, where you will enter local account information.
  
-  - For Windows 11 version 22H2, the following sequence of actions to use a local account instead of a Microsoft account has been published:
+    - For Windows 11 version 22H2, the following sequence of actions to use a local account instead of a Microsoft account has been published:
 
-    - Enter `no@thankyou.com` (or some other senseless address) as the email address and click `Next` when Windows 11 setup prompts you to log into your Microsoft account.
-    - Enter any text you want in the password field and click `Sign in`. If this method works, you'll get a message saying "Oops, something went wrong."
-    - Click `Next`. A screen appears saying "Who's going to use this device?" This is the local account creation screen.
-    - Enter the username you want to use and click `Next`.
-    - Enter a password and click `Next`. You can leave the field blank but it's not recommended.
+      - Enter `no@thankyou.com` (or some other senseless address) as the email address and click `Next` when Windows 11 setup prompts you to log into your Microsoft account.
+      - Enter any text you want in the password field and click `Sign in`. If this method works, you'll get a message saying "Oops, something went wrong."
+      - Click `Next`. A screen appears saying "Who's going to use this device?" This is the local account creation screen.
+      - Enter the username you want to use and click `Next`.
+      - Enter a password and click `Next`. You can leave the field blank but it's not recommended.
    
-    For Windows 11 version 24H2, the following sequence of actions to use a local account instead of a Microsoft account has been proved working:
+    - For version 24H2, the following actions allow you to install Windows 11 with a local account, if the VM is defined, at least temporarily, without a netVM:
+      - After some reboots, the VM will show a window allowing the selection of an installation country. In this window, type  Shift-F10 to open a console window.
+      - In this window, type `oobe\bypassnro`. The VM will then reboot and return to the country selection window. The network connection window will now show an option "I don't have internet", allowing you to define a local account.
 
-    For version 24H2, the following actions allow you to install Windows 11 with a local account, if the VM is defined, at least temporarily, without a netVM:
-     - After some reboots, the VM will show a window allowing the selection of an installation country. In this window, type  Shift-F10 to open a console window.
-     - In this window, type `oobe\bypassnro`. The VM will then reboot and return to the country selection window. The network connection window will now show an option "I don't have internet", allowing you to define a local account.
-
-    In new preview builds of Windows (26120 and beyond, and eventually the next release version), the `oobe\bypassnro` command has been erased and no longer works. Instead, there's a new command called start `ms-chx:localonly` that does something similar. In this case, proceed as follows:
-     - Follow the Windows 11 install process until you get to the Sign in screen. Here, type  Shift-F10 to open a console window.
-     - Enter start `ms-cxh:localonly` at the command prompt.
-     - A "Create a user for this PC" dialog window appears, allowing you to define a local account.
+    - In new preview builds of Windows (26120 and beyond, and eventually the next release version), the `oobe\bypassnro` command has been erased and no longer works. Instead, there's a new command called start `ms-chx:localonly` that does something similar. In this case, proceed as follows:
+      - Follow the Windows 11 install process until you get to the Sign in screen. Here, type  Shift-F10 to open a console window.
+      - Enter start `ms-cxh:localonly` at the command prompt.
+      - A "Create a user for this PC" dialog window appears, allowing you to define a local account.
 
 - On systems shipped with a Windows license, the product key may be read from flash via root in dom0:
 

From c6b07c0191194b90a5abbbe977a0c3e1eb02cdf3 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Thu, 15 May 2025 10:29:39 +0000
Subject: [PATCH 312/332] Added Titles to images. Normalised language in
 description of procedure

---
 user/advanced-topics/standalones-and-hvms.md | 49 ++++++++++++++------
 1 file changed, 34 insertions(+), 15 deletions(-)

diff --git a/user/advanced-topics/standalones-and-hvms.md b/user/advanced-topics/standalones-and-hvms.md
index 6c344b47..e76d2f9b 100644
--- a/user/advanced-topics/standalones-and-hvms.md
+++ b/user/advanced-topics/standalones-and-hvms.md
@@ -50,6 +50,21 @@ is about the virtualization mode. In practice, however, it is most common for
 standalones to be HVMs and for HVMs to be standalones. Hence, this page covers
 both topics.
 
+## Understanding Virtualization Modes
+
+PVH has both better performance and better security than either PV or HVM:
+
+PVH has less attack surface than PV, as it relies on Second Level Address Translation (SLAT) hardware. Guests modify their own page tables natively, without hypervisor involvement. Xen does not need to perform complex checks to ensure that a guest cannot obtain write access to its own page tables, as is necessary for PV. Flaws in these checks have been a source of no fewer than four guest ⇒ host escapes: XSA-148, XSA-182, XSA-212, and XSA-213.
+
+PVH also has less attack surface than HVM, as it does not require QEMU to provide device emulation services. While QEMU is confined in a stubdomain, and again in a seccomp based sandbox, the stubdomain has significant attack surface against the hypervisor. Not only does it have the full attack surface of a PV domain, it also has access to additional hypercalls that allow it to control the guest it is providing emulation services for. XSA-109 was a vulnerability in one of these hypercalls.
+
+PVH has better performance than HVM, as the stubdomain iin HVM consumes resources (both memory and a small amount of CPU). There is little difference in the I/O path at runtime, as both PVH and HVM guests usually use paravirtualized I/O protocols.
+
+Surprisingly, PVH often has better performance than PV. This is because PVH does not require hypercalls for page table updates, which are expensive. SLAT does raise the cost of TLB misses, but this is somewhat mitigated by a second-level TLB in recent hardware.
+
+
+
+
 ## Creating a standalone
 
 You can create a standalone in the Qube Manager by selecting the "Type" of
@@ -175,37 +190,41 @@ seen, e.g., in the Qube Manager in the qube's properties:
 ![r4.0-manager-networking-config.png](/attachment/doc/r4.0-manager-networking-config.png)
 
 Alternatively, one can use the `qvm-ls -n` command to obtain the same
-information (IP/netmask/gateway). The netmask required is that for your own network, 
-so for example, if your IPv4 network has a subnet mask of /24 then the actual netmask to 
-use is 255.255.255.0 - even if the Qube Manager suggests 255.255.255.255  
+information (IP/netmask/gateway).
+The Qube Settimgs shows a netmask of 255.255.255.255.
+This is not suitable for most standalones, and you will need to use a different value.
 
-The DNS IP addresses are `10.139.1.1` and `10.139.1.2`. There is [opt-in
-support](/doc/networking/#ipv6) for IPv6 forwarding.
+In Qubes, the IP address is usually in range 10.137.0.0/16, with disposables in range 10.138.0.0/16, and DNS set to `10.139.1.1` and `10.139.1.2`.
+The simplest solution is to set the netmask to 255.0.0.0 - standard for a class A network.
+If you want a more restricted solution you could use 255.252.0.0, or 255.255.255.0
+
+There is [opt-in support](/doc/networking/#ipv6) for IPv6 forwarding.
 
 ### An example of setting up a network - Network Manager on KDE
 
 Every guest operating system has its own way of handling networking, and the user is 
 referred to the documentation that comes with that operating system. However, 
-Network Manager is widely used on Linux systems, and so hopefully a worked example will 
-prove useful. The worked example is for a HVM running EndeavourOS. 
+Network Manager is widely used on Linux systems, and so a worked example will 
+prove useful. This example is for an HVM running EndeavourOS. 
 
-> Image of Qubes Manager - is this what it's called??
+![Image of Qube Settings](/attachment/doc/EndeavourOS_Network.png "Qube Settings")
 
 In this example, Network Manager on KDE, the network had the following values:
 
 1. IPv4 networking
 2. IP address 10.137.0.17
-3. Netmask 255.255.255.255 (but in the network the netmask is actually 255.255.255.0)
+3. Netmask - qube settings showed 255.255.255.255, but we decided to use 255.255.255.0
 4. Gateway 10.138.24.248
 5. Virtual DNS 10.139.1.1 and 10.139.1.2
 
-> Image of Network Manager, annotated by numbers for reference below
+![Image of Network Manager, annotated by numbers for reference below](/attachment/doc/Network Manager.png "Annotated image of KDE Network Manager")
 
-The network was set up by entering Network Manager, tab Wi-Fi & Networking, clicking on the Wired Ethernet
-item, and selecting tab IPv4 (1). The Manual method is selected (2), which reveals areas for data entry. The DNS 
-Servers takes a comma-separated list, here 10.139.1.1,10.1.139.2 (3). At the bottom of the tab (4), click on '+ Add', 
-and enter the IP address of 10.137.0.17 under column 'Address', the Netmask of 25.255.255.0  (to match the network) 
-under column 'Netmask', and the Gateway of 10.138.24.248 under column 'Gateway'. Apply these changes.
+The network was set up by entering Network Manager, selecting the Wi-Fi & Networking tab, clicking on the Wired Ethernet
+item, and selecting tab IPv4 (1).
+The Manual method was selected (2), which revealed areas for data entry.
+The DNS Servers section takes a comma-separated list, here 10.139.1.1,10.1.139.2 (3).
+At the bottom of the tab (4),  the '+ Add' button was selected, and the IP address of 10.137.0.17 entered in the 'Address' column,  the Netmask of 255.255.255.0 entered in the 'Netmask' column, and the Gateway of 10.138.24.248 under 'Gateway'.
+Selecting the "Apply" button stored these changes
 
 ## Using template-based HVMs
 

From 73294eb89d3eeb7f7d891716a8c4cdf8a099c0da Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Thu, 15 May 2025 11:08:21 +0000
Subject: [PATCH 313/332] Minor changes in how-to-install-software

---
 user/how-to-guides/how-to-install-software.md | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/user/how-to-guides/how-to-install-software.md b/user/how-to-guides/how-to-install-software.md
index 094f526e..87f8af4b 100644
--- a/user/how-to-guides/how-to-install-software.md
+++ b/user/how-to-guides/how-to-install-software.md
@@ -68,13 +68,6 @@ will appear in the Applications Menu. (If you encounter problems, see
 
 ## Installing software from other sources
 
-**Warning:** This method gives your template direct network access, which is
-[risky](#why-dont-templates-have-normal-network-access). This method is **not**
-recommended for trusted templates. Moreover, depending on how you install this
-software, it may not get updated automatically when you [update Qubes
-normally](/doc/how-to-update/), which means you may have to update it manually
-yourself.
-
 Some software is not available from the default repositories and must be
 downloaded and installed from another source. Depending on the installation method,
 you may either use the updates proxy or direct networking.
@@ -98,8 +91,15 @@ $ export HTTP_PROXY=http://127.0.0.1:8082 http_proxy=$HTTP_PROXY \
 
 ### Using direct networking
 
-This method assumes that you're trying to follow the instructions to install some piece
-of software in a normal operating system, except that operating system is running as a
+**Warning:** This method gives your template direct network access, which is
+[risky](#why-dont-templates-have-normal-network-access). This method is **not**
+recommended for trusted templates. Moreover, depending on how you install this
+software, it may not get updated automatically when you [update Qubes
+normally](/doc/how-to-update/), which means you may have to update it manually
+yourself.
+
+This method assumes that you are trying to follow instructions to install some piece
+of software in a normal operating system, except *that* operating system is running as a
 template in Qubes OS.
 
 1. (Recommended) Clone the desired template (since this new template will
@@ -166,7 +166,7 @@ Please see [How to Update](/doc/how-to-update/).
 In order to protect you from performing risky activities in templates, they do
 not have normal network access by default. Instead, templates use an [updates
 proxy](#updates-proxy) which allows you to install and update software using
-the distribution package manager over the proxy connection.
+the distribution's package manager over the proxy connection.
 **The updates proxy is already set up to work automatically out-of-the-box and
 requires no special action from you.**
 Most users should simply follow the normal instructions for [installing software
@@ -179,7 +179,7 @@ sources](#installing-software-from-other-sources).
 ## Advanced
 
 The following sections cover advanced topics pertaining to installing and
-updating software in domUs.
+updating software in qubes.
 
 
 ### Testing repositories

From b594557061312229e0d30f81ecd99f5a2efef213 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Thu, 15 May 2025 12:12:18 +0000
Subject: [PATCH 314/332] Minor change to headings on update page.

---
 user/how-to-guides/how-to-update.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/user/how-to-guides/how-to-update.md b/user/how-to-guides/how-to-update.md
index 9c80c0f6..743c7bf1 100644
--- a/user/how-to-guides/how-to-update.md
+++ b/user/how-to-guides/how-to-update.md
@@ -151,7 +151,8 @@ Which one to use depends on the device whose firmware is being updated.
 Firmware updates are important on all systems, but they are especially
 important on AMD client systems.  These do not support loading microcode from
 the OS, so firmware updates are the **only** way to obtain microcode updates.
-## Firmware updates
+
+## Firmware update methods
 
 As of Qubes 4.2, firmware updates can be performed from within Qubes for [fwupd-supported computers](https://fwupd.org/).
 

From caffc06eaf6a87446a5fbad04bf3e2d4124ec9da Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Thu, 15 May 2025 17:06:24 -0700
Subject: [PATCH 315/332] Add Heads certified firmware option for NovaCustom
 V54 & V56

---
 user/hardware/certified-hardware/novacustom-v54-series.md | 3 ++-
 user/hardware/certified-hardware/novacustom-v56-series.md | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/user/hardware/certified-hardware/novacustom-v54-series.md b/user/hardware/certified-hardware/novacustom-v54-series.md
index 44db3f56..448da878 100644
--- a/user/hardware/certified-hardware/novacustom-v54-series.md
+++ b/user/hardware/certified-hardware/novacustom-v54-series.md
@@ -47,7 +47,8 @@ The configuration options required for Qubes certification are detailed below.
 
 - Qubes OS does not currently support UEFI secure boot.
 - The option to be kept up to date with firmware updates is merely an email notification service and therefore does not affect certification.
-- The coreboot+Heads option is not currently certified. This option is a separate firmware variant. As such, it requires a separate certification process, which we expect to occur in the future.
+- Certified: coreboot+EDK-II
+- Certified: coreboot+Heads
 - Disabling Intel Management Engine (HAP disabling) does not affect certification.
 
 ### Operating system
diff --git a/user/hardware/certified-hardware/novacustom-v56-series.md b/user/hardware/certified-hardware/novacustom-v56-series.md
index 01eba16b..d743d7ab 100644
--- a/user/hardware/certified-hardware/novacustom-v56-series.md
+++ b/user/hardware/certified-hardware/novacustom-v56-series.md
@@ -47,7 +47,8 @@ The configuration options required for Qubes certification are detailed below.
 
 - Qubes OS does not currently support UEFI secure boot.
 - Keeping up-to-date with firmware updates is merely an email notification service and therefore does not affect certification.
-- The coreboot+Heads option is not currently certified. This option is a separate firmware variant. As such, it requires a separate certification process, which we expect to occur in the future.
+- Certified: coreboot+EDK-II
+- Certified: coreboot+Heads
 - Disabling Intel Management Engine (HAP disabling) does not affect certification.
 
 ### Operating system

From 0ead1b03a1c87f7d826873b0717aa85fa48790b3 Mon Sep 17 00:00:00 2001
From: Ali Mirjamali <ali@mirjamali.com>
Date: Mon, 17 Feb 2025 11:54:18 +0330
Subject: [PATCH 316/332] Add the new notes API documentation

related: https://github.com/QubesOS/qubes-issues/issues/899
---
 developer/services/admin-api.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/developer/services/admin-api.md b/developer/services/admin-api.md
index 74314ed7..f05ee780 100644
--- a/developer/services/admin-api.md
+++ b/developer/services/admin-api.md
@@ -99,6 +99,8 @@ to set the policy using current mechanism.
 | `admin.vm.feature.CheckWithTemplateAndAdminVM` | vm         | feature      | -                                                                   | value                                               |
 | `admin.vm.feature.Remove`                      | vm         | feature      | -                                                                   | -                                                   |
 | `admin.vm.feature.Set`                         | vm         | feature      | value                                                               | -                                                   |
+| `admin.vm.notes.Get`                           | vm         | -            | -                                                                   | notes                                               |
+| `admin.vm.notes.Set`                           | vm         | -            | notes                                                               | -                                                   |
 | `admin.vm.tag.List`                            | vm         | -            | -                                                                   | `<tag>\n`                                           |
 | `admin.vm.tag.Get`                             | vm         | tag          | -                                                                   | `0` or `1`                                          | retcode? |
 | `admin.vm.tag.Remove`                          | vm         | tag          | -                                                                   | -                                                   |

From 2b028834a600ccd15bc5bf9c74ae0105e03cba54 Mon Sep 17 00:00:00 2001
From: Ali Mirjamali <ali@mirjamali.com>
Date: Sun, 18 May 2025 21:42:07 +0330
Subject: [PATCH 317/332] Fixing existing CI/CD issues

---
 user/hardware/certified-hardware/certified-hardware.md | 2 +-
 user/how-to-guides/how-to-install-software.md          | 4 ++--
 user/how-to-guides/how-to-update.md                    | 5 ++---
 user/templates/templates.md                            | 2 +-
 4 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/user/hardware/certified-hardware/certified-hardware.md b/user/hardware/certified-hardware/certified-hardware.md
index 3067080b..e3465e62 100644
--- a/user/hardware/certified-hardware/certified-hardware.md
+++ b/user/hardware/certified-hardware/certified-hardware.md
@@ -36,7 +36,7 @@ The current Qubes-certified models are listed below in reverse chronological ord
 | [NovaCustom](https://novacustom.com/)  | [NV41 Series](https://novacustom.com/product/nv41-series/)                                                                                                             | [Certification details](/doc/certified-hardware/novacustom-nv41-series/)    |
 | [3mdeb](https://3mdeb.com/)            | [Dasharo FidelisGuard Z690](https://web.archive.org/web/20240917145232/https://shop.3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) | [Certification details](/doc/certified-hardware/dasharo-fidelisguard-z690/) |
 | [Nitrokey](https://www.nitrokey.com/)  | [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119)                                                                                              | [Certification details](/doc/certified-hardware/nitropad-t430/)             |
-| [Nitrokey](https://www.nitrokey.com/)  | [NitroPad X230](https://shop.nitrokey.com/shop/product/nitropad-x230-67)                                                                                               | [Certification details](/doc/certified-hardware/nitropad-x230/)             |
+| [Nitrokey](https://www.nitrokey.com/)  | <a id="nitropad-x230"></a>[NitroPad X230](https://shop.nitrokey.com/shop/product/nitropad-x230-67)                                                                                               | [Certification details](/doc/certified-hardware/nitropad-x230/)             |
 | [Insurgo](https://insurgo.ca/)         | [PrivacyBeast X230](https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/)                                                         | [Certification details](/doc/certified-hardware/insurgo-privacybeast-x230/) |
 
 ## Become hardware certified
diff --git a/user/how-to-guides/how-to-install-software.md b/user/how-to-guides/how-to-install-software.md
index 87f8af4b..0cc90323 100644
--- a/user/how-to-guides/how-to-install-software.md
+++ b/user/how-to-guides/how-to-install-software.md
@@ -164,8 +164,8 @@ Please see [How to Update](/doc/how-to-update/).
 ## Why don't templates have normal network access?
 
 In order to protect you from performing risky activities in templates, they do
-not have normal network access by default. Instead, templates use an [updates
-proxy](#updates-proxy) which allows you to install and update software using
+not have normal network access by default. Instead, templates use an
+[updates-proxy](#updates-proxy)which allows you to install and update software using
 the distribution's package manager over the proxy connection.
 **The updates proxy is already set up to work automatically out-of-the-box and
 requires no special action from you.**
diff --git a/user/how-to-guides/how-to-update.md b/user/how-to-guides/how-to-update.md
index 743c7bf1..5120701f 100644
--- a/user/how-to-guides/how-to-update.md
+++ b/user/how-to-guides/how-to-update.md
@@ -158,7 +158,7 @@ As of Qubes 4.2, firmware updates can be performed from within Qubes for [fwupd-
 
 ### In dom0
 
-First, ensure that your [UpdateVM](/doc/Software/UpdateVM/)
+First, ensure that your UpdateVM
 contains the `fwupd-qubes-vm` package. This package is installed
 by default for qubes with `qubes-vm-recommended` packages.
 
@@ -198,8 +198,7 @@ Repeat the update process for any additional devices on your computer.
 
 Devices that are attached to non-dom0 qubes can be updated via a graphical tool for `fwupd`, or via the `fwupdmgr` commandline tool.
 
-To update the firmware of offline qubes, use the [Updates
-proxy](/doc/how-to/install/software/#updates-proxy).
+To update the firmware of offline qubes, use the [Updates proxy](/doc/how-to-install-software/#updates-proxy).
 
 ### Computers without fwupd support
 
diff --git a/user/templates/templates.md b/user/templates/templates.md
index cafd062a..392f999e 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -172,7 +172,7 @@ $ qvm-template list --installed
 
 In either case, issues with template removal may be raised. If an issue is raised, the template will remain installed and a list of concerns displayed. "Global property default_template" requires [switching](#switching) the default_template property to another template. "Template for" can be resolved by [switching](#switching) the dependent qubes' template. Once the issues are addressed, attempt the removal again.
 
-If the template's entry in the Qubes Menu is not removed with its uninstallation, consult the [troubleshooting page](/doc/app-menu-shortcut-troubleshooting/#fixing-shortcuts).
+If the template's entry in the Qubes Menu is not removed with its uninstallation, consult the [troubleshooting page](/doc/app-menu-shortcut-troubleshooting/#what-if-a-removed-application-is-still-in-the-app-menu).
 
 ## Reinstalling
 

From 9f76056671b3a04f9940ea4bd5fa45f745673492 Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Mon, 19 May 2025 03:10:16 -0400
Subject: [PATCH 318/332] minor format fixes

---
 developer/services/admin-api.md              | 22 ++++++++++----------
 user/advanced-topics/standalones-and-hvms.md |  2 +-
 user/templates/windows/windows-qubes-4-1.md  |  8 +++----
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/developer/services/admin-api.md b/developer/services/admin-api.md
index 8d809480..8ba9d222 100644
--- a/developer/services/admin-api.md
+++ b/developer/services/admin-api.md
@@ -64,7 +64,7 @@ to set the policy using current mechanism.
 | call                                           | dest       | argument     | inside                                                              | return                                              | note |
 |------------------------------------------------|------------|--------------|---------------------------------------------------------------------|-----------------------------------------------------| ---- |
 | `admin.vmclass.List`                           | `dom0`     | -            | -                                                                   | `<class>\n`                                         |
-| `admin.vm.List`                                | `dom0      | <vm>`        | -                                                                   | -                                                   | `<name> class=<class> state=<state>\n`                    |
+| `admin.vm.List`                                | `dom0|<vm>`| -            | -                                                                   | `<name> class=<class> state=<state>\n`              |
 | `admin.vm.Create.<class>`                      | `dom0`     | template     | `name=<name> label=<label>`                                         | -                                                   |
 | `admin.vm.CreateInPool.<class>`                | `dom0`     | template     | `name=<name> label=<label> `<br/>`pool=<pool> pool:<volume>=<pool>` | -                                                   | either use `pool=` to put all volumes there, <br/>or `pool:<volume>=` for individual volumes - both forms are not allowed at the same time
 | `admin.vm.CreateDisposable`                    | template   | -            | -                                                                   | name                                                | Create new DisposableVM, `template` is any AppVM with `dispvm_allowed` set to True, or `dom0` to use default defined in `default_dispvm` property of calling VM; VM created with this call will be automatically removed after its shutdown; the main difference from `admin.vm.Create.DispVM` is automatic (random) name generation.
@@ -75,17 +75,17 @@ to set the policy using current mechanism.
 | `admin.label.Index`                            | `dom0`     | label        | -                                                                   | `<label-index>`                                     |
 | `admin.label.Remove`                           | `dom0`     | label        | -                                                                   | -                                                   |
 | `admin.property.List`                          | `dom0`     | -            | -                                                                   | `<property>\n`                                      |
-| `admin.property.Get`                           | `dom0`     | property     | -                                                                   | `default={True                                      |False} `<br/>`type={str|int|bool|vm|label|list} <value>`   | Type `list` is added in R4.1. Values are of type `str` and each entry is suffixed with newline character.
+| `admin.property.Get`                           | `dom0`     | property     | -                                                                   | `default={True|False} `<br/>`type={str|int|bool|vm|label|list} <value>`   | Type `list` is added in R4.1. Values are of type `str` and each entry is suffixed with newline character.
 | `admin.property.GetAll`                        | `dom0`     | -            | -                                                                   | `<property-name> <full-value-as-in-property.Get>\n` | Get all the properties in one call. Each property is returned on a separate line and use the same value encoding as property.Get method, with an exception that newlines are encoded as literal `\n` and literal `\` are encoded as `\\`.
-| `admin.property.GetDefault`                    | `dom0`     | property     | -                                                                   | `type={str                                          |int|bool|vm|label|list} <value>`               | Type `list` is added in R4.1. Values are of type `str` and each entry is suffixed with newline character.
+| `admin.property.GetDefault`                    | `dom0`     | property     | -                                                                   | `type={str|int|bool|vm|label|list} <value>`         | Type `list` is added in R4.1. Values are of type `str` and each entry is suffixed with newline character.
 | `admin.property.Help`                          | `dom0`     | property     | -                                                                   | `help`                                              |
 | `admin.property.HelpRst`                       | `dom0`     | property     | -                                                                   | `help.rst`                                          |
 | `admin.property.Reset`                         | `dom0`     | property     | -                                                                   | -                                                   |
 | `admin.property.Set`                           | `dom0`     | property     | value                                                               | -                                                   |
 | `admin.vm.property.List`                       | vm         | -            | -                                                                   | `<property>\n`                                      |
-| `admin.vm.property.Get`                        | vm         | property     | -                                                                   | `default={True                                      |False} `<br/>`type={str|int|bool|vm|label|list} <value>`   | Type `list` is added in R4.1. Each list entry is suffixed with a newline character.
+| `admin.vm.property.Get`                        | vm         | property     | -                                                                   | `default={True|False} `<br/>`type={str|int|bool|vm|label|list} <value>`   | Type `list` is added in R4.1. Each list entry is suffixed with a newline character.
 | `admin.vm.property.GetAll`                     | vm         | -            | -                                                                   | `<property-name> <full-value-as-in-property.Get>\n` | Get all the properties in one call. Each property is returned on a separate line and use the same value encoding as property.Get method, with an exception that newlines are encoded as literal `\n` and literal `\` are encoded as `\\`.
-| `admin.vm.property.GetDefault`                 | vm         | property     | -                                                                   | `type={str                                          |int|bool|vm|label|type} <value>`               | Type `list` is added in R4.1. Each list entry is suffixed with a newline character.
+| `admin.vm.property.GetDefault`                 | vm         | property     | -                                                                   | `type={str|int|bool|vm|label|type} <value>`         | Type `list` is added in R4.1. Each list entry is suffixed with a newline character.
 | `admin.vm.property.Help`                       | vm         | property     | -                                                                   | `help`                                              |
 | `admin.vm.property.HelpRst`                    | vm         | property     | -                                                                   | `help.rst`                                          |
 | `admin.vm.property.Reset`                      | vm         | property     | -                                                                   | -                                                   |
@@ -151,8 +151,8 @@ to set the policy using current mechanism.
 | `admin.backup.Execute`                         | `dom0`     | config id    | -                                                                   | -                                                   | config in `/etc/qubes/backup/<id>.conf`, only one backup operation of given `config id` can be running at once |
 | `admin.backup.Info`                            | `dom0`     | config id    | -                                                                   | backup info                                         | info what would be included in the backup
 | `admin.backup.Cancel`                          | `dom0`     | config id    | -                                                                   | -                                                   | cancel running backup operation
-| `admin.Events`                                 | `dom0      | vm`          | -                                                                   | -                                                   | events                                                    |
-| `admin.vm.Stats`                               | `dom0      | vm`          | -                                                                   | -                                                   | `vm-stats` events, see below                              | emit VM statistics (CPU, memory usage) in form of events
+| `admin.Events`                                 | `dom0| vm` | -            | -                                                                   | events                                              |
+| `admin.vm.Stats`                               | `dom0| vm` | -            | -                                                                   | `vm-stats` events, see below                        | emit VM statistics (CPU, memory usage) in form of events
 
 Volume properties:
 
@@ -216,8 +216,8 @@ Server will close the connection.
 Traceback may be empty, can be enabled server-side as part of debug mode.
 Delimiting zero-byte is always present.
 
-Fields are should substituted into `%`-style format string, possibly after
-client-side translation, to form final message to be displayed unto user. Server
+Fields should be fromatted to `%`-style format string, possibly after
+client-side translation, to form final message to be displayed to the user. Server
 does not by itself support translation.
 
 ## Tags
@@ -225,10 +225,10 @@ does not by itself support translation.
 The tags provided can be used to write custom policies. They are not used in
 a&nbsp;default Qubes OS installation. However, they are created anyway.
 
-- `created-by-<vm>` &mdash;&nbsp;Created in an extension to qubesd at the
+- `created-by-<vm>` - Created in an extension to `qubesd` at the
   moment of creation of the VM. Cannot be changed via API, which is also
   enforced by this extension.
-- `managed-by-<vm>` &mdash;&nbsp;Can be used for the same purpose, but it is
+- `managed-by-<vm>` - Can be used for the same purpose, but it is
   not created automatically, nor is it forbidden to set or reset this tag.
 
 ## Backup profile
diff --git a/user/advanced-topics/standalones-and-hvms.md b/user/advanced-topics/standalones-and-hvms.md
index a04855d3..2ca852b2 100644
--- a/user/advanced-topics/standalones-and-hvms.md
+++ b/user/advanced-topics/standalones-and-hvms.md
@@ -218,7 +218,7 @@ In this example, Network Manager on KDE, the network had the following values:
 4. Gateway 10.138.24.248
 5. Virtual DNS 10.139.1.1 and 10.139.1.2
 
-![Image of Network Manager, annotated by numbers for reference below](/attachment/doc/Network Manager.png "Annotated image of KDE Network Manager")
+![Image of Network Manager, annotated by numbers for reference below](/attachment/doc/Network_Manager.png "Annotated image of KDE Network Manager")
 
 The network was set up by entering Network Manager, selecting the Wi-Fi & Networking tab, clicking on the Wired Ethernet
 item, and selecting tab IPv4 (1).
diff --git a/user/templates/windows/windows-qubes-4-1.md b/user/templates/windows/windows-qubes-4-1.md
index e1a25817..b3666607 100644
--- a/user/templates/windows/windows-qubes-4-1.md
+++ b/user/templates/windows/windows-qubes-4-1.md
@@ -166,10 +166,10 @@ These parameters are set for the following reasons:
     -  Close the registry editor and console windows.
     -  You will then return to the setup, which will continue normally and install Windows 11 without TPM 2.0.
 
-    <div class="alert alert-warning" role="alert">
-      <i class="fa fa-exclamation-circle"></i>
-       <b>Caution:</b> This temporary patch may cease to work if it so pleases Microsoft sometime. With version 24H2 it is still working.
-    </div>
+<div class="alert alert-warning" role="alert">
+    <i class="fa fa-exclamation-circle"></i>
+    <b>Caution:</b> This temporary patch may cease to work if it so pleases Microsoft sometime. With version 24H2 it is still working.
+</div>
     
 
     - The installation of Windows 11 may require an internet connection to grab a Microsoft ID. Previously, this was true only for the home edition, but since version 24H2, it extends to the Pro edition, too. A workaround to bypass the internet connection requirements of the Windows 11 setup has been published that works for version 21H2 but may be blocked for newer versions:

From e520e2e5597aa5222b5cd2193998d3dbb7a5991a Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Mon, 19 May 2025 03:46:03 -0400
Subject: [PATCH 319/332] fix for warning display and a url

---
 user/templates/templates.md                 | 2 +-
 user/templates/windows/migrate-to-4-1.md    | 5 ++++-
 user/templates/windows/windows-qubes-4-1.md | 7 +++++--
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/user/templates/templates.md b/user/templates/templates.md
index cafd062a..392f999e 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -172,7 +172,7 @@ $ qvm-template list --installed
 
 In either case, issues with template removal may be raised. If an issue is raised, the template will remain installed and a list of concerns displayed. "Global property default_template" requires [switching](#switching) the default_template property to another template. "Template for" can be resolved by [switching](#switching) the dependent qubes' template. Once the issues are addressed, attempt the removal again.
 
-If the template's entry in the Qubes Menu is not removed with its uninstallation, consult the [troubleshooting page](/doc/app-menu-shortcut-troubleshooting/#fixing-shortcuts).
+If the template's entry in the Qubes Menu is not removed with its uninstallation, consult the [troubleshooting page](/doc/app-menu-shortcut-troubleshooting/#what-if-a-removed-application-is-still-in-the-app-menu).
 
 ## Reinstalling
 
diff --git a/user/templates/windows/migrate-to-4-1.md b/user/templates/windows/migrate-to-4-1.md
index d80f65d5..e5434c98 100644
--- a/user/templates/windows/migrate-to-4-1.md
+++ b/user/templates/windows/migrate-to-4-1.md
@@ -51,4 +51,7 @@ The PV disk drivers used for migration can be removed after successful installat
 
 After successful uninstallation of the PV disk drivers, the disks will appear as QEMU ATA disks.
 
-:warning: **Caution:** This change may lead Windows to declare that the hardware has changed and that in consequence, the activation is no longer valid, possibly complaining that the use of the software is no longer lawful. It should be possible to reactivate the software if a valid product key is provided.
+<div class="alert alert-warning" role="alert">
+    <i class="fa fa-exclamation-circle"></i>
+    <b>Caution:</b> This change may lead Windows to declare that the hardware has changed and that in consequence, the activation is no longer valid, possibly complaining that the use of the software is no longer lawful. It should be possible to reactivate the software if a valid product key is provided.
+</div>
diff --git a/user/templates/windows/windows-qubes-4-1.md b/user/templates/windows/windows-qubes-4-1.md
index 8908dc33..cbd2b3ba 100644
--- a/user/templates/windows/windows-qubes-4-1.md
+++ b/user/templates/windows/windows-qubes-4-1.md
@@ -154,8 +154,11 @@ These parameters are set for the following reasons:
     -  Close the registry editor and console windows.
     -  You will then return to the setup, which will continue normally and install Windows 11 without TPM 2.0.
    
-    :warning: **Caution:** This temporary patch may cease to work if it so pleases Microsoft sometime. With version 24H2 it is still working.
-    
+<div class="alert alert-warning" role="alert">
+    <i class="fa fa-exclamation-circle"></i>
+    <b>Caution:</b> This temporary patch may cease to work if it so pleases Microsoft sometime. With version 24H2 it is still working.
+</div>
+
     The installation of Windows 11 may require an internet connection to grab a Microsoft ID. Previously, this was true only for the home edition, but since version 24H2, it extends to the Pro edition, too. A workaround to bypass the internet connection requirements of the Windows 11 setup has been published that works for version 21H2 but may be blocked for newer versions:
     
     - When you reach the “Let’s Connect You To A Network” page, type Shift-F10 to open a console window.

From d76402c3ddb935baa1f272bcbf44f1bb4f3a44dd Mon Sep 17 00:00:00 2001
From: lafried <lahuk@protonmail.com>
Date: Wed, 21 May 2025 02:11:50 +0100
Subject: [PATCH 320/332] Fix syntax for dnf5 support

---
 user/templates/fedora/fedora-upgrade.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/user/templates/fedora/fedora-upgrade.md b/user/templates/fedora/fedora-upgrade.md
index 2d5dad90..a34bda37 100644
--- a/user/templates/fedora/fedora-upgrade.md
+++ b/user/templates/fedora/fedora-upgrade.md
@@ -47,7 +47,7 @@ If you wish to install a new, unmodified Fedora template instead of upgrading a
 [user@fedora-<new> ~]$ sudo mkfs.ext4 /dev/xvdi
 [user@fedora-<new> ~]$ sudo mount /dev/xvdi /mnt/removable
 [user@fedora-<new> ~]$ sudo dnf clean all
-[user@fedora-<new> ~]$ sudo dnf --releasever=<new> --setopt=cachedir=/mnt/removable --best --allowerasing distro-sync
+[user@fedora-<new> ~]$ sudo dnf --releasever=<new> --setopt=cachedir=/mnt/removable --best distro-sync --allowerasing
 [user@dom0 ~]$ qvm-shutdown fedora-<new>
 [user@dom0 ~]$ sudo losetup -d $dev
 [user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
@@ -116,7 +116,7 @@ The same general procedure may be used to upgrade any template based on the stan
         [user@fedora-<new> ~]$ sudo mkfs.ext4 /dev/xvdi
         [user@fedora-<new> ~]$ sudo mount /dev/xvdi /mnt/removable
         [user@fedora-<new> ~]$ sudo dnf clean all
-        [user@fedora-<new> ~]$ sudo dnf --releasever=<new> --setopt=cachedir=/mnt/removable --best --allowerasing distro-sync
+        [user@fedora-<new> ~]$ sudo dnf --releasever=<new> --setopt=cachedir=/mnt/removable --best distro-sync --allowerasing
         ```
 
        If this attempt is successful, proceed to step 4.
@@ -185,7 +185,7 @@ The same general procedure may be used to upgrade any template based on the stan
 [user@dom0 ~]$ qvm-clone fedora-<old>-minimal fedora-<new>-minimal
 [user@dom0 ~]$ qvm-run -u root -a fedora-<new>-minimal xterm
 [root@fedora-<new>-minimal ~]# dnf clean all
-[user@fedora-<new>-minimal ~]# dnf --releasever=<new> --best --allowerasing distro-sync
+[user@fedora-<new>-minimal ~]# dnf --releasever=<new> --best distro-sync --allowerasing
 [user@fedora-<new>-minimal ~]# fstrim -v /
 [user@dom0 ~]$ qvm-features fedora-<new>-minimal template-name fedora-<new>
 ```

From 34144a1620029ead19314853c6f3897f3ea3dd79 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sol=C3=A8ne=20Rapenne?= <solene@perso.pw>
Date: Sat, 24 May 2025 15:05:14 +0200
Subject: [PATCH 321/332] doc: make clear that sys-gui-gpu is not meant for
 improving performance

---
 user/advanced-topics/gui-domain.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/user/advanced-topics/gui-domain.md b/user/advanced-topics/gui-domain.md
index 6c18d51f..ae2b21b5 100644
--- a/user/advanced-topics/gui-domain.md
+++ b/user/advanced-topics/gui-domain.md
@@ -45,6 +45,8 @@ At this point, you need to shutdown all your running qubes as the `default_guivm
 
 Here, we describe how to setup `sys-gui-gpu` which is a GUI domain with *GPU passthrough* in [GUI domain](/news/2020/03/18/gui-domain/#gpu-passthrough-the-perfect-world-desktop-solution).
 
+> Note: the purpose of `sys-gui-gpu` is to improve Qubes OS security by detaching the GPU from dom0, this is not intended to improve GPU related performance within qubes, and this will not improve performance.
+
 [![sys-gui-gpu](/attachment/posts/guivm-gpu.png)](/attachment/posts/guivm-gpu.png)
 
 In `dom0`, enable the formula for `sys-gui-gpu` with pillar data:

From f72ad83ffbaf24203b5c15856bca051573cbe020 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sun, 25 May 2025 01:05:24 +0000
Subject: [PATCH 322/332] Edit secondary storage page for clarity

---
 .../secondary-storage.md                      | 40 ++++++++++---------
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/user/advanced-configuration/secondary-storage.md b/user/advanced-configuration/secondary-storage.md
index eedf2526..5874e4b3 100644
--- a/user/advanced-configuration/secondary-storage.md
+++ b/user/advanced-configuration/secondary-storage.md
@@ -10,35 +10,38 @@ ref: 187
 title: Secondary Storage
 ---
 
-# Storing AppVMs on Secondary Drives
+# Storing qubes on Secondary Drives
 
 Suppose you have a fast but small primary SSD and a large but slow secondary HDD.
-You want to store a subset of your AppVMs on the HDD.
+You may want to store a subset of your qubes on the HDD.
+Or if you install a second SSD, you may want to use *that* for storage of some qubes.
+This page explains how to use that second drive.
+
 
 ## Instructions
 
 Qubes 4.0 is more flexible than earlier versions about placing different VMs on different disks.
-For example, you can keep templates on one disk and AppVMs on another, without messy symlinks.
+For example, you can keep templates on one disk and qubes on another, without messy symlinks.
 
 You can query qvm-pool to list available storage drivers:
 
 ``` shell_session
 qvm-pool --help-drivers
 ```
-qvm-pool driver explaination:
-```shell_session
+qvm-pool driver explanation:
+```
 <file> refers to using a simple file for image storage and lacks a few features.
 <file-reflink> refers to storing images on a filesystem supporting copy on write.
 <linux-kernel> refers to a directory holding kernel images.
 <lvm_thin> refers to LVM managed pools.
 ```
-In theory, you can still use file-based disk images ("file" pool driver), but it lacks some features such as you won't be able to do backups without shutting down the qube.
+In theory, you can still use file-based disk images ("file" pool driver), but they will lack some features: for example, you won't be able to do backups without shutting down the qube.
 
-Additionnal storage can also be added on a Btrfs filesystem. A unique feature of Btrfs over LVM is that data can be compressed transparently. The subvolume can also be backuped using snapshots for an additionnal layer of protection; Btrfs supports differents level of redundancy; it has parity checksum; it is able to be expanded/shrinked. Starting/stoping a VM has less impact and less chances of causing slowdown of the system as some have noted with LVM. Revelant information for general btrfs configuration will be provided after LVM section.
+Additional storage can also be added on a Btrfs filesystem. A unique feature of Btrfs is that data can be compressed transparently. The subvolume can also be backed up using snapshots for an additional layer of protection; Btrfs supports differents level of redundancy; it has parity checksum; Btrfs volumes can be expanded or shrunk. Starting or stopping a VM has less impact and less chance of causing slowdown of the system as some users have noted with LVM. Relevant information for general btrfs configuration will be provided after the section on LVM storage.
 
 ### LVM storage
 
-These steps assume you have already created a separate [volume group](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/vg_admin#VG_create) and [thin pool](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/thinly_provisioned_volume_creation) (not thin volume) for your HDD.
+These steps assume you have already created a separate [volume group](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/vg_admin#VG_create) and [thin pool](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/thinly_provisioned_volume_creation) (not thin volume) for your second drive..
 See also [this example](https://www.linux.com/blog/how-full-encrypt-your-linux-system-lvm-luks) if you would like to create an encrypted LVM pool (but note you can use a single logical volume if preferred, and to use the `-T` option on `lvcreate` to specify it is thin). You can find the commands for this example applied to Qubes at the bottom of this R4.0 section.
 
 First, collect some information in a dom0 terminal:
@@ -48,9 +51,9 @@ sudo pvs
 sudo lvs
 ```
 
-Take note of the VG and thin pool names for your HDD, then register it with Qubes:
+Take note of the VG and thin pool names for your second drive., then register it with Qubes:
 
-```shell_session
+```
 # <pool_name> is a freely chosen pool name
 # <vg_name> is LVM volume group name
 # <thin_pool_name> is LVM thin pool name
@@ -58,10 +61,10 @@ qvm-pool --add <pool_name> lvm_thin -o volume_group=<vg_name>,thin_pool=<thin_po
 ```
 
 ### BTRFS storage
-Theses steps assume you have already created a separate Btrfs filesystem for your HDD, that it is encrypted with LUKS and it is mounted. It is recommended to use a subvolume as it enables compression and excess storage can be use for other things.
+Theses steps assume you have already created a separate Btrfs filesystem for your second drive., that it is encrypted with LUKS and it is mounted. It is recommended to use a subvolume as it enables compression and excess storage can be use for other things.
 
 
-It is possible to use already available Btrfs storage if it is configured. In dom0, available Btrfs storage can be displayed using:
+It is possible to use an existing Btrfs storage if it is configured. In dom0, available Btrfs storage can be displayed using:
 ```shell_session
 mount -t btrfs
 btrfs show filesystem
@@ -89,20 +92,19 @@ qvm-clone -P <pool_name> <sourceVMname> <cloneVMname>
 qvm-remove <sourceVMname>
 ```
 
-If that was a template, or other qube referenced elsewhere (NetVM or such), you will need to adjust those references manually after moving.
+If that was a template, or other qube referenced elsewhere (netVM or such), you will need to adjust those references manually after moving.
 For example:
 
 ```shell_session
 qvm-prefs <appvmname_based_on_old_template> template <new_template_name>
 ```
 
-#### Example HDD setup
+#### Example setup of second drive. 
 
-Assuming the secondary hard disk is at /dev/sdb (it will be completely erased), you can set it up for encryption by doing in a dom0 terminal (use the same passphrase as the main Qubes disk to avoid a second password prompt at boot):
+Assuming the secondary hard disk is at /dev/sdb , you can encrypt the drive as follows. Note that the drive contents will be completely erased,  In a dom0 terminal run this command - use the same passphrase as the main Qubes disk to avoid a second password prompt at boot:
 
 ```shell_session
 sudo cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sdb
-sudo blkid /dev/sdb
 ```
 
 Note the device's UUID (in this example "b209..."), we will use it as its luks name for auto-mounting at boot, by doing:
@@ -111,13 +113,13 @@ Note the device's UUID (in this example "b209..."), we will use it as its luks n
 sudo nano /etc/crypttab
 ```
 
-And adding this line (change both "b209..." for your device's UUID from blkid) to crypttab:
+And adding this line to crypttab (replacing both "b209..." entries with your device's UUID taken from blkid) :
 
 ```shell_session
 luks-b20975aa-8318-433d-8508-6c23982c6cde UUID=b20975aa-8318-433d-8508-6c23982c6cde none
 ```
 
-Reboot the computer so the new luks device appears at /dev/mapper/luks-b209... and we can then create its pool, by doing this on a dom0 terminal (substitute the b209... UUIDs with yours):
+Reboot the computer so the new luks device appears at /dev/mapper/luks-b209...  You can then create the new pool by running this command in a dom0 terminal (substitute the b209... UUIDs with your UID):
 
 ##### For LVM
 
@@ -180,7 +182,7 @@ Finally we will tell Qubes to add a new pool on the just created Btrfs subvolume
 qvm-pool --add poolhd0_qubes file-reflink -o dir_path=/var/lib/qubes_newpool,revisions_to_keep=2
 ```
 
-By default VMs will be created on the main Qubes disk (i.e. a small SSD), to create them on this secondary HDD do the following on a dom0 terminal:
+By default VMs will be created on the main Qubes disk (i.e. a small SSD), to create them on this secondary drive do the following on a dom0 terminal:
 
 ```shell_session
 qvm-create -P poolhd0_qubes --label red unstrusted-hdd

From 684a7cee24065e0b3a7bbc50e73961076987cd53 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Sun, 25 May 2025 01:17:06 +0000
Subject: [PATCH 323/332] Minor edits to Secondary Storage page

---
 user/advanced-topics/secondary-storage.md | 10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/user/advanced-topics/secondary-storage.md b/user/advanced-topics/secondary-storage.md
index a0ff1598..af4b689c 100644
--- a/user/advanced-topics/secondary-storage.md
+++ b/user/advanced-topics/secondary-storage.md
@@ -110,13 +110,7 @@ sudo blkid /dev/sdb
 
 (The `--sector-size=512` argument can sometimes work around an incompatibility of storage hardware with LVM thin pools on Qubes. If this does not apply to your hardware, the argument will make no difference.)
 
-Note the device's UUID (in this example "b209..."), we will use it as its luks name for auto-mounting at boot, by doing:
-
-```shell_session
-sudo nano /etc/crypttab
-```
-
-And adding this line to crypttab (replacing both "b209..." entries with your device's UUID taken from blkid) :
+Note the device's UUID (in this example "b209..."), we will use it as its luks name for auto-mounting at boot, by editing `/etc/crypttab`, and adding this line to crypttab (replacing both "b209..." entries with your device's UUID taken from blkid) :
 
 ```shell_session
 luks-b20975aa-8318-433d-8508-6c23982c6cde UUID=b20975aa-8318-433d-8508-6c23982c6cde none
@@ -190,11 +184,9 @@ By default VMs will be created on the main Qubes disk (i.e. a small SSD), to cre
 ```shell_session
 qvm-create -P poolhd0_qubes --label red unstrusted-hdd
 ```
-=======
 
 Verify that corresponding lines were added to /etc/fstab and /etc/cryptab to enable auto mounting of the new pool.
 
 
 [Qubes Backup]: /doc/BackupRestore/
 [TemplateVM]: /doc/Templates/
->>>>>>> pr-1130:user/advanced-configuration/secondary-storage.md

From 5b5a4ebd9b8c839f9f1cf373667e4ba67623ab6d Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Tue, 27 May 2025 12:09:11 +0000
Subject: [PATCH 324/332] Update Debian and Fedora template pages.

---
 user/templates/debian/debian.md | 15 ++++++---------
 user/templates/fedora/fedora.md | 10 ++++------
 2 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/user/templates/debian/debian.md b/user/templates/debian/debian.md
index c070791d..622d3e6d 100644
--- a/user/templates/debian/debian.md
+++ b/user/templates/debian/debian.md
@@ -12,19 +12,18 @@ title: Debian templates
 ---
 
 The Debian [template](/doc/templates/) is an officially [supported](/doc/supported-releases/#templates) template in Qubes OS.
-This page is about the standard (or "full") Debian template.
+The Current version is Debian 12 ("bookworm"). It is available in 3 versions - `debian-12`, a standard template; `debian-12-xfce`, a larger template with more installed applications, selected for [Xfce](/doc/templates/xfce/); `debian-12-minimal`.
+This page is about the "full" templates.
 For the minimal version, please see the [Minimal templates](/doc/templates/minimal/) page.
-There is also a [Qubes page on the Debian Wiki](https://wiki.debian.org/Qubes).
 
 ## Installing
 
-To [install](/doc/templates/#installing) a specific Debian template that is not currently installed in your system, use the following command in dom0:
+To [install](/doc/templates/#installing) a specific Debian template that is not currently installed in your system, use the Qubes Template Manager, or use the following command in a dom0 terminal:
 
 ```
-$ sudo qubes-dom0-update qubes-template-debian-XX
+$ qvm-template install XX
 ```
-
-   (Replace `XX` with the Debian version number of the template you wish to install.)
+   (Replace `XX` with the name of the template you wish to install.)
 
 To reinstall a Debian template that is already installed in your system, see [How to Reinstall a template](/doc/reinstall-template/).
 
@@ -100,10 +99,8 @@ Don't forget to make the file executable.
 
 ### Unattended Upgrades
 
-Some users have noticed that on upgrading to Stretch, the `unattended-upgrade` package is installed.
-
+Some users have noticed that on upgrading Debian templates, the `unattended-upgrade` package is installed.
 This package is pulled in as part of a Recommend chain, and can be purged.
-
 The lesson is that you should carefully look at what is being installed to your system, particularly if you run `dist-upgrade`.
 
 ### Package installation errors in Qubes 4.0
diff --git a/user/templates/fedora/fedora.md b/user/templates/fedora/fedora.md
index eefa7fac..baffd3d4 100644
--- a/user/templates/fedora/fedora.md
+++ b/user/templates/fedora/fedora.md
@@ -6,17 +6,15 @@ ref: 136
 title: Fedora templates
 ---
 
-The Fedora [template](/doc/templates/) is the default template in Qubes OS. This page is about the standard (or "full") Fedora template. For the minimal and Xfce versions, please see the [Minimal templates](/doc/templates/minimal/) and [Xfce templates](/doc/templates/xfce/) pages.
+The Fedora [template](/doc/templates/) is the default template in Qubes OS. The current version is Fedora 41. This page is about the standard (or "full") Fedora template. For the minimal and Xfce versions, please see the [Minimal templates](/doc/templates/minimal/) and [Xfce templates](/doc/templates/xfce/) pages.
 
 ## Installing
 
-To [install](/doc/templates/#installing) a specific Fedora template that is not currently installed in your system, use the following command in dom0:
-
+To [install](/doc/templates/#installing) a specific Fedora template that is not currently installed in your system, use the Qubes Template Manager, or use the following command in a dom0 terminal:
 ```
-$ sudo qubes-dom0-update qubes-template-fedora-XX
+$ qvm-template install XX 
 ```
-
-   (Replace `XX` with the Fedora version number of the template you wish to install.)
+   (Replace `XX` with the name of the Fedora template you wish to install.)
 
 To reinstall a Fedora template that is already installed in your system, see [How to Reinstall a template](/doc/reinstall-template/).
 

From 473fb5d3236e20c203e5e274e4979d88b08120bb Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Tue, 27 May 2025 13:04:44 +0000
Subject: [PATCH 325/332] Update Templates page. Includes some changes based on
 #1206

---
 user/templates/templates.md | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/user/templates/templates.md b/user/templates/templates.md
index 392f999e..31ca18f8 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -13,10 +13,15 @@ title: Templates
 
 In [Getting Started](/doc/getting-started/), we covered the distinction
 in Qubes OS between where you *install* your software and where you *run* your
-software. Your software is installed in [templates](/doc/glossary/#template).
-Each template shares its root filesystem (i.e., all of its programs and system
-files) with all the qubes based on it. [App qubes](/doc/glossary/#app-qube) are
-where you run your software and store your data.
+software. Software that you use in most everyday tasks, is installed within [templates](/doc/glossary/#template).
+When using Qubes OS, you normally work in [app qubes](/doc/glossary/#app-qube).
+App qubes are based on a *template* qube (or more simply, just *a template*).
+They inherit most of the ["root filesystem"](https://opensource.com/life/16/10/introduction-linux-filesystems), from the template.
+Changes you make to the root filesystem are not written back to the template: if you install an application in an app qube it will disappear when you shut down the qube. (You may be able to work round this by using Flatpak or snap packages, which install to the user's home directory.)
+The user home directory *is* specific to the app qube, and changes there are kept.
+There is a full explanation of this [below](#inheritance-and-persistence).
+
+If you use a [Standalone](/doc/glossary/#standalone), the **whole filesystem** is specific to the standalone, and every change you make will be kept after shutdown.
 
 The template system has significant benefits:
 
@@ -37,7 +42,7 @@ The template system has significant benefits:
 
 An important side effect of this system is that any software installed in an
 app qube (rather than in the template on which it is based) will disappear
-after the app qube reboots (see [Inheritance and
+when the app qube shuts down (see [Inheritance and
 Persistence](#inheritance-and-persistence)). For this reason, we recommend
 installing most of your software in templates, not app qubes.
 
@@ -61,6 +66,9 @@ exactly the same source code as we publish.
 * [Fedora Xfce](/doc/templates/xfce)
 * [Debian](/doc/templates/debian/)
 * [Debian Minimal](/doc/templates/minimal/)
+* [Debian Xfce](/doc/templates/xfce)
+
+You can see the current supported versions [here](/doc/supported-releases#templates).
 
 ## Community
 
@@ -109,16 +117,16 @@ when you wish to install a fresh template from the Qubes repositories, e.g.:
 * When you suspect your template has been compromised.
 * When you have made modifications to your template that you no longer want.
 
-You can use a command line tool - `qvm-template` - or a GUI - `qvm-template-gui`.
+You can manage your templates using the `Qubes Template Manager`, a GUI tool available from the Qube menu.
+You can also use a command line tool in dom0 - `qvm-template`.
 
 At the command line in dom0, `qvm-template list --available` will show available templates. To install a template, use:
 ```
 $ qvm-template install  <template_name>
 ```
-
 You can also use `qvm-template` to upgrade or reinstall templates.
 
-Repo definitions are stored in `/etc/qubes/repo-templates` and associated keys in `/etc/qubes/repo-templates/keys`.  
+Repository (repo) definitions are stored in dom0 in `/etc/qubes/repo-templates` and associated keys in `/etc/qubes/repo-templates/keys`.
 There are additional repos for testing releases and community templates.
 To temporarily enable any of these repos, use the `--enablerepo=<repo-name>` option. E.g. :
 ```

From 78654bf052904135b14f576deb2421447ec93055 Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Wed, 28 May 2025 09:46:41 -0400
Subject: [PATCH 326/332] added space, fixed links

---
 user/how-to-guides/how-to-install-software.md | 2 +-
 user/templates/debian/debian-upgrade.md       | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/user/how-to-guides/how-to-install-software.md b/user/how-to-guides/how-to-install-software.md
index ab722a21..6dd718ab 100644
--- a/user/how-to-guides/how-to-install-software.md
+++ b/user/how-to-guides/how-to-install-software.md
@@ -165,7 +165,7 @@ Please see [How to Update](/doc/how-to-update/).
 
 In order to protect you from performing risky activities in templates, they do
 not have normal network access by default. Instead, templates use an
-[updates-proxy](#updates-proxy)which allows you to install and update software using
+[updates-proxy](#updates-proxy) which allows you to install and update software using
 the distribution's package manager over the proxy connection.
 **The updates proxy is already set up to work automatically out-of-the-box and
 requires no special action from you.**
diff --git a/user/templates/debian/debian-upgrade.md b/user/templates/debian/debian-upgrade.md
index dd626566..cf4d3ef2 100644
--- a/user/templates/debian/debian-upgrade.md
+++ b/user/templates/debian/debian-upgrade.md
@@ -179,7 +179,7 @@ command is required:
 ### Debian 10 ("Buster")
 
 Please see [Debian's Buster upgrade
-instructions](https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.en.html).
+instructions](https://www.debian.org/releases/buster/amd64/release-notes.en.txt).
 
 ### Debian 9 ("Stretch")
 
@@ -203,12 +203,12 @@ Relevant discussions:
 * [User apt commands blocked on startup](https://github.com/QubesOS/qubes-issues/issues/2621)
 
 Also see [Debian's Stretch upgrade
-instructions](https://www.debian.org/releases/stretch/amd64/release-notes/ch-upgrading.en.html).
+instructions](https://www.debian.org/releases/stretch/amd64/release-notes.en.txt).
 
 ### Debian 8 ("Jessie")
 
 Please see [Debian's Jessie upgrade
-instructions](https://www.debian.org/releases/jessie/amd64/release-notes/ch-upgrading.en.html).
+instructions](https://www.debian.org/releases/jessie/amd64/release-notes.en.txt).
 
 ### End-of-life (EOL) releases
 

From 524928b022a1da0f3bec322671f4725c0d5117f9 Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Tue, 3 Jun 2025 13:51:29 -0400
Subject: [PATCH 327/332] pre-final fixes

---
 developer/services/qrexec-internals.md         |  2 +-
 introduction/faq.md                            |  2 +-
 introduction/getting-started.md                |  2 +-
 user/advanced-topics/salt.md                   |  2 +-
 .../install-security.md                        |  2 +-
 .../upgrade/2.md                               |  8 ++++----
 .../upgrade/2b1.md                             |  4 ++--
 .../upgrade/2b2.md                             |  2 +-
 .../upgrade/3_0.md                             |  2 +-
 .../upgrade/3_2.md                             | 10 +++++-----
 .../certified-hardware/certified-hardware.md   |  2 +-
 .../hardware/certified-hardware/nitropc-pro.md |  4 ++--
 .../novacustom-nv41-series.md                  |  4 ++++
 .../how-to-organize-your-qubes.md              |  2 +-
 user/security-in-qubes/anti-evil-maid.md       |  2 +-
 user/security-in-qubes/firewall.md             |  2 +-
 user/security-in-qubes/firewall_4.1.md         | 13 ++++---------
 user/security-in-qubes/mfa.md                  |  5 +++--
 user/security-in-qubes/split-gpg-2.md          |  2 +-
 user/security-in-qubes/split-gpg.md            | 18 +++++++++---------
 20 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/developer/services/qrexec-internals.md b/developer/services/qrexec-internals.md
index e131b473..1888e0e6 100644
--- a/developer/services/qrexec-internals.md
+++ b/developer/services/qrexec-internals.md
@@ -124,7 +124,7 @@ Details of all possible use cases and the messages involved are described below.
 
   - (If `local_program` is set, `qrexec-client` executes it and uses that child's stdin/stdout in place of its own when exchanging data with `qrexec-agent` later.)
 
-  - `qrexec-client` translates that request into a `MSG_EXEC_CMDLINE` message sent to `qrexec-daemon`, with `connect_domain` set to 0 (connect to **dom0**) and `connect_port also set to 0 (allocate a port).
+  - `qrexec-client` translates that request into a `MSG_EXEC_CMDLINE` message sent to `qrexec-daemon`, with `connect_domain` set to 0 (connect to **dom0**) and `connect_port` also set to 0 (allocate a port).
 
 - **dom0**: `qrexec-daemon` allocates a free port (in this case 513), and sends a `MSG_EXEC_CMDLINE` back to the client with connection parameters (**domX** and 513) and with command field empty.
 
diff --git a/introduction/faq.md b/introduction/faq.md
index de159ce5..49ddeeb1 100644
--- a/introduction/faq.md
+++ b/introduction/faq.md
@@ -190,7 +190,7 @@ By default, Qubes OS uses [LUKS](https://en.wikipedia.org/wiki/Linux_Unified_Key
 
 ### What do all these terms mean?
 
-All Qubes-specific terms are defined in the [glossary](/doc/glossary/)
+All Qubes-specific terms are defined in the [glossary](/doc/glossary/).
 
 ### Does Qubes run every app in a separate VM?
 
diff --git a/introduction/getting-started.md b/introduction/getting-started.md
index 3f02e0fa..3c98450e 100644
--- a/introduction/getting-started.md
+++ b/introduction/getting-started.md
@@ -149,7 +149,7 @@ The default terminal emulator in Qubes is Xfce Terminal.
 Opening a terminal emulator in dom0 can be done in several ways:
 
 - Go to the App Menu, click on the Settings icon, choose Other from the drop-down menu, and select **Xfce Terminal Emulator** at the bottom.
-- Press `Alt`+`F3` and search for `xfce terminal`.
+- Press `Alt` + `F3` and search for `xfce terminal`.
 - Right-click on the desktop and select **Open Terminal Here**.
 
 Various command-line tools are described as part of this guide, and the whole reference can be found [here](/doc/tools/).
diff --git a/user/advanced-topics/salt.md b/user/advanced-topics/salt.md
index 1b0767f7..3e7b1bc3 100644
--- a/user/advanced-topics/salt.md
+++ b/user/advanced-topics/salt.md
@@ -600,8 +600,8 @@ If the log does not contain useful information:
 $ export PATH="/usr/lib/qubes-vm-connector/ssh-wrapper:$PATH"
 $ salt-ssh "$target_vm" $salt_command
 ```
-
   Adjust $target_vm (VM_NAME) and $salt_command (state.apply).
+
 6. Execute them, fix problems, repeat.
 
 ## Known Pitfalls
diff --git a/user/downloading-installing-upgrading/install-security.md b/user/downloading-installing-upgrading/install-security.md
index 6a4920c2..a113fb5e 100644
--- a/user/downloading-installing-upgrading/install-security.md
+++ b/user/downloading-installing-upgrading/install-security.md
@@ -51,7 +51,7 @@ Cons:
   (If the drive is mounted to a compromised machine, the ISO could be maliciously altered after it has been written to the drive.)
 * Untrustworthy firmware.
   (Firmware can be malicious even if the drive is new.
-  Plugging a drive with rewritable firmware into a compromised machine can also [compromise the drive](https://srlabs.de/badusb/).
+  Plugging a drive with rewritable firmware into a compromised machine can also [compromise the drive](https://www.blackhat.com/us-14/briefings.html#badusb-on-accessories-that-turn-evil).
   Installing from a compromised drive could compromise even a brand new Qubes installation.)
 
 ### Optical discs
diff --git a/user/downloading-installing-upgrading/upgrade/2.md b/user/downloading-installing-upgrading/upgrade/2.md
index e46f637c..43ebbd3f 100644
--- a/user/downloading-installing-upgrading/upgrade/2.md
+++ b/user/downloading-installing-upgrading/upgrade/2.md
@@ -34,7 +34,7 @@ Note that dom0 in R2 is based on Fedora 20, in contrast to Fedora 18 in previous
 
 1. Open terminal in Dom0. E.g. Start-\>System Settings-\>Konsole.
 
-1. Install all the updates for Dom0:
+2. Install all the updates for Dom0:
 
     ~~~
     sudo qubes-dom0-update
@@ -42,7 +42,7 @@ Note that dom0 in R2 is based on Fedora 20, in contrast to Fedora 18 in previous
 
 After this step you should have `qubes-release-2-5` in your Dom0. Important: if you happen to have `qubes-release-2-6*` then you should downgrade to `qubes-release-2-5`! The `qubes-release-2-6*` packages have been uploaded to the testing repos and were kept there for a few hours, until we realized they bring incorrect repo definitions and so we removed them and also have changed the update procedure a bit (simplifying it).
 
-1. Upgrade dom0 to R2:
+3. Upgrade dom0 to R2:
 
 Note: be sure that the VM used as a update-downloading-vm (by default its the firewallvm based on the default template) has been updated to the latest Qubes packages, specifically `qubes-core-vm-2.1.33` or later. This doesn't imply that the VM must already be upgraded to fc20 -- for Dom0 upgrade we could still use an fc18-based VM (updatevm) it is only important to install the latest Qubes packages there.
 
@@ -51,7 +51,7 @@ sudo qubes-dom0-update qubes-dom0-dist-upgrade
 sudo qubes-dom0-update
 ~~~
 
-1. If above step completed successfully you should have `qubes-release-2-9` or later. If not, repeat above step with additional `--clean` option.
+4. If above step completed successfully you should have `qubes-release-2-9` or later. If not, repeat above step with additional `--clean` option.
 
 4a. If you chose not to upgrade your fc18 templates, but instead to download our new fc20-based template you should now be able to do that by simply typing:
 
@@ -59,6 +59,6 @@ sudo qubes-dom0-update
 sudo qubes-dom0-update qubes-template-fedora-20-x64
 ~~~
 
-1. Reboot the system.
+5. Reboot the system.
 
 Please note that if you use Anti Evil Maid, then it won't be able to unseal the passphrase this time, because the Xen, kernel, and initramfs binaries have changed. Once the system boots up again, you could reseal your Anti Evil Maid's passphrase to the new configuration. Please consult Anti Evil Maid documentation for explanation on how to do that.
diff --git a/user/downloading-installing-upgrading/upgrade/2b1.md b/user/downloading-installing-upgrading/upgrade/2b1.md
index 0d564fb5..8c1c0fbf 100644
--- a/user/downloading-installing-upgrading/upgrade/2b1.md
+++ b/user/downloading-installing-upgrading/upgrade/2b1.md
@@ -13,7 +13,7 @@ title: Upgrading to R2B1
 
 **Note: Qubes R2 Beta 1 is no longer supported! Please install or upgrade to a newer Qubes R2.**
 
-**Note: This page is kept for historical reasons only! Do not follow the instructions below'''**
+**Note: This page is kept for historical reasons only! Do not follow the instructions below**
 
 Existing users of Qubes R1 (but not R1 betas!) can upgrade their systems to the latest R2 beta release by following the procedure below. As usual, it is advisable to backup the system before proceeding with the upgrade
 
@@ -51,7 +51,7 @@ By default, in Qubes R1, there is only one template, however users are free to c
 - via a legitimate RPM package previously installed (in our case it was the `qubes-upgrade-vm` RPM). Such an RPM must have been signed by one of the keys you decided to trust previously, by default this would be either via the Qubes R1 signing key, or Fedora 17 signing key.
 - via system compromise or via some illegal RPM package (e.g. Fedora released package pretending to bring new Firefox). In that case, however, your VM is already compromised, and it careful checking of the new R2 key would not change this situation to any better one. The game is lost for this VM anyway (and all VMs based on this template).
 
-1. Shut down the VM.
+4. Shut down the VM.
 
 Upgrade Dom0
 ------------
diff --git a/user/downloading-installing-upgrading/upgrade/2b2.md b/user/downloading-installing-upgrading/upgrade/2b2.md
index 29020439..727d6d74 100644
--- a/user/downloading-installing-upgrading/upgrade/2b2.md
+++ b/user/downloading-installing-upgrading/upgrade/2b2.md
@@ -49,7 +49,7 @@ By default, in Qubes R1, there is only one template, however users are free to c
 - via a legitimate RPM package previously installed (in our case it was the `qubes-upgrade-vm` RPM). Such an RPM must have been signed by one of the keys you decided to trust previously, by default this would be either via the Qubes R1 signing key, or Fedora 17 signing key.
 - via system compromise or via some illegal RPM package (e.g. Fedora released package pretending to bring new Firefox). In that case, however, your VM is already compromised, and it careful checking of the new R2 key would not change this situation to any better one. The game is lost for this VM anyway (and all VMs based on this template).
 
-1. Shut down the VM.
+4. Shut down the VM.
 
 Installing new template
 -----------------------
diff --git a/user/downloading-installing-upgrading/upgrade/3_0.md b/user/downloading-installing-upgrading/upgrade/3_0.md
index 24f477d4..0cb815b3 100644
--- a/user/downloading-installing-upgrading/upgrade/3_0.md
+++ b/user/downloading-installing-upgrading/upgrade/3_0.md
@@ -101,7 +101,7 @@ Be sure to do steps described in this section after *all* your template and stan
 
 6. Reboot the system.
     
-    It may happen that the system hang during the reboot. Hard reset the system in such case, all the filesystems are unmounted at this stage.
+    - It may happen that the system hang during the reboot. Hard reset the system in such case, all the filesystems are unmounted at this stage.
 
 Please note that if you use Anti Evil Maid, then it won't be able to unseal the passphrase this time, because the Xen, kernel, and initramfs binaries have changed. Once the system boots up again, you could reseal your Anti Evil Maid's passphrase to the new configuration. Please consult Anti Evil Maid documentation for explanation on how to do that.
 
diff --git a/user/downloading-installing-upgrading/upgrade/3_2.md b/user/downloading-installing-upgrading/upgrade/3_2.md
index ed1e9f9e..53c87a89 100644
--- a/user/downloading-installing-upgrading/upgrade/3_2.md
+++ b/user/downloading-installing-upgrading/upgrade/3_2.md
@@ -29,13 +29,13 @@ by following the procedure below.
     sudo qubes-dom0-update --releasever=3.2 qubes-release
     ```
 
-    If you made any manual changes to repository definitions, new definitions
+    - If you made any manual changes to repository definitions, new definitions
     will be installed as `/etc/yum.repos.d/qubes-dom0.repo.rpmnew` (you'll see
     a message about it during package installation). In such a case, you need
     to manually apply the changes to `/etc/yum.repos.d/qubes-dom0.repo` or
     simply replace it with .rpmnew file.
 
-    If you are using Debian-based VM as UpdateVM (`sys-firewall` by default),
+    - If you are using Debian-based VM as UpdateVM (`sys-firewall` by default),
     you need to download few more packages manually, but **do not install
     them** yet:
 
@@ -60,7 +60,7 @@ by following the procedure below.
     sudo qubes-dom0-update
     ```
 
-    You may wish to disable the screensaver "Lock screen" feature for this step, as
+    - You may wish to disable the screensaver "Lock screen" feature for this step, as
     during the update XScreensaver may encounter an "Authentication failed" issue,
     requiring a hard reboot. Alternatively, you may simply move the mouse regularly.
     
@@ -70,7 +70,7 @@ by following the procedure below.
 
 6. Update configuration files.
 
-    Some of configuration files were saved with `.rpmnew` extension as the
+    - Some of configuration files were saved with `.rpmnew` extension as the
     actual files were modified. During upgrade, you'll see information about
     such cases, like:
 
@@ -78,7 +78,7 @@ by following the procedure below.
     warning: /etc/salt/minion.d/f_defaults.conf created as /etc/salt/minion.d/f_defaults.conf.rpmnew
     ```
 
-    This will happen for every configuration you have modified manually and for
+    - This will happen for every configuration you have modified manually and for
     a few that has been modified by Qubes scripts. If you are not sure what to
     do about them, below is a list of commands to deal with few common cases
     (either keep the old one, or replace with the new one):
diff --git a/user/hardware/certified-hardware/certified-hardware.md b/user/hardware/certified-hardware/certified-hardware.md
index e3465e62..83cc9ba6 100644
--- a/user/hardware/certified-hardware/certified-hardware.md
+++ b/user/hardware/certified-hardware/certified-hardware.md
@@ -32,7 +32,7 @@ The current Qubes-certified models are listed below in reverse chronological ord
 | [NovaCustom](https://novacustom.com/)  | [V56 Series](https://novacustom.com/product/v56-series/)                                                                                                               | [Certification details](/doc/certified-hardware/novacustom-v56-series/)     |
 | [Nitrokey](https://www.nitrokey.com/)  | [NitroPC Pro 2](https://shop.nitrokey.com/shop/nitropc-pro-2-523)                                                                                                      | [Certification details](/doc/certified-hardware/nitropc-pro-2/)             |
 | [Star Labs](https://starlabs.systems/) | [StarBook](https://starlabs.systems/pages/starbook)                                                                                                                    | [Certification details](/doc/certified-hardware/starlabs-starbook/)         |
-| [Nitrokey](https://www.nitrokey.com/)  | [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523)                                                                                                  | [Certification details](/doc/certified-hardware/nitropc-pro/)               |
+| [Nitrokey](https://www.nitrokey.com/)  | [NitroPC Pro](https://web.archive.org/web/20231027112856/https://shop.nitrokey.com/shop/product/nitropc-pro-523)                                                       | [Certification details](/doc/certified-hardware/nitropc-pro/)               |
 | [NovaCustom](https://novacustom.com/)  | [NV41 Series](https://novacustom.com/product/nv41-series/)                                                                                                             | [Certification details](/doc/certified-hardware/novacustom-nv41-series/)    |
 | [3mdeb](https://3mdeb.com/)            | [Dasharo FidelisGuard Z690](https://web.archive.org/web/20240917145232/https://shop.3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) | [Certification details](/doc/certified-hardware/dasharo-fidelisguard-z690/) |
 | [Nitrokey](https://www.nitrokey.com/)  | [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119)                                                                                              | [Certification details](/doc/certified-hardware/nitropad-t430/)             |
diff --git a/user/hardware/certified-hardware/nitropc-pro.md b/user/hardware/certified-hardware/nitropc-pro.md
index 91abff8b..bce50f0c 100644
--- a/user/hardware/certified-hardware/nitropc-pro.md
+++ b/user/hardware/certified-hardware/nitropc-pro.md
@@ -17,7 +17,7 @@ ref: 356
   <b>Note:</b> Only the "Dasharo TianoCore UEFI without Measured Boot, without Nitrokey" firmware option is certified. The "HEADS with Measured Boot, requires Nitrokey!" firmware option is <em>not</em> certified.
 </div>
 
-The [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
+The [NitroPC Pro](https://web.archive.org/web/20231027112856/https://shop.nitrokey.com/shop/product/nitropc-pro-523) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
 
 [![Photo of NitroPC Pro](/attachment/posts/nitropc-pro.jpg)](https://shop.nitrokey.com/shop/product/nitropc-pro-523)
 
@@ -40,7 +40,7 @@ The NitroPC Pro also comes with a "Dasharo Entry Subscription," which includes t
 - Accesses to the latest firmware releases
 - Exclusive newsletter
 - Special firmware updates, including early access to updates enhancing privacy, security, performance, and compatibility
-- Early access to new firmware releases for [newly-supported desktop platforms](https://docs.dasharo.com/variants/overview/#desktop) (please see the [roadmap](https://github.com/Dasharo/presentations/blob/main/dug2_dasharo_roadmap.md#dasharo-desktop-roadmap))
+- Early access to new firmware releases for [newly-supported desktop platforms](https://docs.dasharo.com/variants/overview/#desktop) (please see the [roadmap](https://github.com/Dasharo/presentations/blob/main/archive/dug_2/dug2_dasharo_roadmap.md#dasharo-desktop-roadmap))
 - Access to the Dasharo Premier Support invite-only live chat channel on the Matrix network, allowing direct access to the Dasharo Team and fellow subscribers with personalized and priority assistance
 - Insider's view and influence on the Dasharo feature roadmap for a real impact on Dasharo development
 - [Dasharo Tools Suite Entry Subscription](https://docs.dasharo.com/osf-trivia-list/dts/#what-is-dasharo-tools-suite-supporters-entrance) keys
diff --git a/user/hardware/certified-hardware/novacustom-nv41-series.md b/user/hardware/certified-hardware/novacustom-nv41-series.md
index ca7b6745..d4600ad5 100644
--- a/user/hardware/certified-hardware/novacustom-nv41-series.md
+++ b/user/hardware/certified-hardware/novacustom-nv41-series.md
@@ -16,19 +16,23 @@ The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is [of
 The following configuration options are certified for Qubes OS Release 4:
 
 Processor:
+
 - Intel Core i5-1240P processor
 - Intel Core i7-1260P processor
 
 Memory:
+
 - 2 x 16 GB Kingston DDR4 SODIMM 3200 MHz (32 GB total)
 - 1 x 32 GB Kingston DDR4 SODIMM 3200 MHz (32 GB total)
 - 2 x 32 GB Kingston DDR4 SODIMM 3200 MHz (64 GB total)
 
 M.2 storage chip:
+
 - Samsung 980 SSD (all capacities)
 - Samsung 980 Pro SSD (all capacities)
 
 Wi-Fi and Bluetooth:
+
 - Intel AX-200/201 Wi-Fi module 2976 Mbps, 802.11ax/Wi-Fi 6 + Bluetooth 5.2
 - Killer (Intel) Wireless-AX 1675x M.2 Wi-Fi module 802.11ax/Wi-Fi 6E + Bluetooth 5.3
 - Blob-free: Qualcomm Atheros QCNFA222 Wi-Fi 802.11a/b/g/n + Bluetooth 4.0
diff --git a/user/how-to-guides/how-to-organize-your-qubes.md b/user/how-to-guides/how-to-organize-your-qubes.md
index 947312b9..780f0664 100644
--- a/user/how-to-guides/how-to-organize-your-qubes.md
+++ b/user/how-to-guides/how-to-organize-your-qubes.md
@@ -336,7 +336,7 @@ her setup looks like this:
   reports.
 
 - **Two qubes for taxes.** Carol has a [Windows
-  qube](https://github.com/Qubes-Community/Contents/blob/master/docs/os/windows/windows.md)
+  qube](/doc/templates/windows/)
   for running her Windows-only tax software. She also has an offline vault
   where she stores all of her tax-related forms and documents, organized by
   year.
diff --git a/user/security-in-qubes/anti-evil-maid.md b/user/security-in-qubes/anti-evil-maid.md
index 0bcf0964..3980b00a 100644
--- a/user/security-in-qubes/anti-evil-maid.md
+++ b/user/security-in-qubes/anti-evil-maid.md
@@ -43,7 +43,7 @@ Security Considerations
 However, in its default configuration, installing and using AEM requires attaching a USB drive (i.e., [mass storage device](https://en.wikipedia.org/wiki/USB_mass_storage_device_class)) directly to dom0.
 (The other option is to install AEM to an internal disk.
 However, this carries significant security implications, as explained [here](https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html).) This presents us with a classic security trade-off: each Qubes user must make a choice between protecting dom0 from a potentially malicious USB drive, on the one hand, and protecting the system from Evil Maid attacks, on the other hand.
-Given the practical feasibility of attacks like [BadUSB](https://srlabs.de/badusb/) and revelations regarding pervasive government hardware backdoors, this is no longer a straightforward decision.
+Given the practical feasibility of attacks like [BadUSB](https://www.blackhat.com/us-14/briefings.html#badusb-on-accessories-that-turn-evil) and revelations regarding pervasive government hardware backdoors, this is no longer a straightforward decision.
 New, factory-sealed USB drives cannot simply be assumed to be "clean" (e.g., to have non-malicious microcontroller firmware).
 Therefore, it is up to each individual Qubes user to evaluate the relative risk of each attack vector against his or her security model.
 
diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index 478dc981..272eab36 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -312,7 +312,7 @@ Third step, code the appropriate new filtering firewall rule to allow new connec
 nft add rule qubes custom-forward iifname ens6 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
 ```
 
-- **Note:** If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
+- **Note:** If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules.
 
 - If you want to expose the service on multiple interfaces, repeat steps 2 and 3 above, for each interface. Alternatively, you can leave out the interface completely.
 
diff --git a/user/security-in-qubes/firewall_4.1.md b/user/security-in-qubes/firewall_4.1.md
index 7c5e2769..7da45432 100644
--- a/user/security-in-qubes/firewall_4.1.md
+++ b/user/security-in-qubes/firewall_4.1.md
@@ -10,8 +10,7 @@ title: Firewall 4.1
 Introduction
 ----------------------------------
 This page explains use of the firewall in Qubes 4.1, using `iptables`.  
-From Qubes 4.2, all firewall components use `nftables`. For details of that usage see [here](../firewall/)
-
+From Qubes 4.2, all firewall components use `nftables`. For details of that usage see [here](../firewall/).
 
 Understanding firewalling in Qubes
 ----------------------------------
@@ -60,14 +59,10 @@ Reconnecting qubes after a NetVM reboot
 
 Normally Qubes doesn't let the user stop a NetVM if there are other qubes running which use it as their own NetVM.
 But in case the NetVM stops for whatever reason (e.g. it crashes, or the user forces its shutdown via qvm-kill via terminal in Dom0), Qubes R4.0 will often automatically repair the connection.
-If it does not, then there is an easy way to restore the connection to the NetVM by issuing in dom0:
-
-` qvm-prefs <vm> netvm <netvm> `
+If it does not, then there is an easy way to restore the connection to the NetVM by issuing in dom0: `qvm-prefs <vm> netvm <netvm>`
 
 Normally qubes do not connect directly to the actual NetVM which has networking devices, but rather to the default sys-firewall first, and in most cases it would be the NetVM that will crash, e.g. in response to S3 sleep/restore or other issues with WiFi drivers.
-In that case it is only necessary to issue the above command once, for the sys-firewall (this assumes default VM-naming used by the default Qubes installation):
-
-` qvm-prefs sys-firewall netvm sys-net `
+In that case it is only necessary to issue the above command once, for the sys-firewall (this assumes default VM-naming used by the default Qubes installation): `qvm-prefs sys-firewall netvm sys-net`
 
 Network service qubes
 ---------------------
@@ -90,7 +85,7 @@ The sys-firewall-2 proxy ensures that:
 
 If you adopt this model, you should be aware that all traffic will arrive at the `network service qube` appearing to originate from the IP address of `sys-firewall-2`.
 
-For the VPN service please also look at the [VPN documentation](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md).
+For the VPN service please also look at the [VPN documentation](https://forum.qubes-os.org/t/configuring-a-proxyvm-vpn-gateway/19061).
 
 Enabling networking between two qubes
 -------------------------------------
diff --git a/user/security-in-qubes/mfa.md b/user/security-in-qubes/mfa.md
index 3c6b4d79..9ea5b532 100644
--- a/user/security-in-qubes/mfa.md
+++ b/user/security-in-qubes/mfa.md
@@ -46,7 +46,7 @@ and then use it as an additional factor to login to your Qubes system.
     google-authenticator
     ```
 
-3. Walk through the setup instructions 2 which will also generate your QR code for your auth app of choice:
+3. Walk through the setup instructions which will also generate your QR code for your auth app of choice:
 
    ```
    Do you want me to update your “/home/user/.google_authenticator” file (y/n) y
@@ -120,7 +120,8 @@ The second option is recovery from a backup. It will work as long as you include
 The YubiKey / NitroKey3 is a hardware authentication device manufactured by Yubico / NitroKey
 to protect access to computers, networks, and online services that supports
 one-time passwords (OTP), public-key cryptography, and authentication, and the
-Universal 2nd Factor (U2F) and FIDO2 protocols[1] developed by the FIDO Alliance.
+Universal 2nd Factor [(U2F)](https://en.wikipedia.org/wiki/Universal_2nd_Factor)
+and FIDO2 protocols developed by the [FIDO Alliance](https://en.wikipedia.org/wiki/FIDO_Alliance).
 
 You can use a YubiKey / NitroKey3 to enhance the user authentication in Qubes. The following
 instructions explain how to setup the YubiKey / NitroKey3 as an *additional* way to login.
diff --git a/user/security-in-qubes/split-gpg-2.md b/user/security-in-qubes/split-gpg-2.md
index 68cdb3aa..83a36f8d 100644
--- a/user/security-in-qubes/split-gpg-2.md
+++ b/user/security-in-qubes/split-gpg-2.md
@@ -121,7 +121,7 @@ If you want to generate a key on a smartcard or other hardware token, use `addca
 ## Advanced usage
 
 There are a few option not described in this README.
-See the comments in the example (config and the source code)[https://github.com/QubesOS/qubes-app-linux-split-gpg2/blob/main/qubes-split-gpg2.conf.example].
+See the comments in the example [config and the source code](https://github.com/QubesOS/qubes-app-linux-split-gpg2/blob/main/qubes-split-gpg2.conf.example).
 
 Similar to a smartcard, split-gpg2 only tries to protect the private key.
 For advanced usages, consider if a specialized RPC service would be better.
diff --git a/user/security-in-qubes/split-gpg.md b/user/security-in-qubes/split-gpg.md
index 86966b2f..c19096b1 100644
--- a/user/security-in-qubes/split-gpg.md
+++ b/user/security-in-qubes/split-gpg.md
@@ -303,7 +303,7 @@ In this example, the following keys are stored in the following locations (see b
 
 * `sec` (master secret key)
 
-   Depending on your needs, you may wish to create this as a **certify-only (C)** key, i.e., a key which is capable only of signing (a.k.a., "certifying") other keys.
+   - Depending on your needs, you may wish to create this as a **certify-only (C)** key, i.e., a key which is capable only of signing (a.k.a., "certifying") other keys.
    This key may be created *without* an expiration date.
    This is for two reasons.
    First, the master secret key is never to leave the `vault` VM, so it is extremely unlikely ever to be obtained by an adversary (see below).
@@ -312,7 +312,7 @@ In this example, the following keys are stored in the following locations (see b
    An adversary who does *not* possess the passphrase cannot use the key at all.
    In either case, an expiration date provides no additional benefit.
 
-   By the same token, however, having a passphrase on the key is of little value.
+   - By the same token, however, having a passphrase on the key is of little value.
    An adversary who is capable of stealing the key from your `vault` would almost certainly also be capable of stealing the passphrase as you enter it.
    An adversary who obtains the passphrase can then use it in order to change or remove the passphrase from the key.
    Therefore, using a passphrase at all should be considered optional.
@@ -320,40 +320,40 @@ In this example, the following keys are stored in the following locations (see b
 
 * `ssb` (secret subkey)
 
-   Depending on your needs, you may wish to create two different subkeys: one for **signing (S)** and one for **encryption (E)**.
+   - Depending on your needs, you may wish to create two different subkeys: one for **signing (S)** and one for **encryption (E)**.
    You may also wish to give these subkeys reasonable expiration dates (e.g., one year).
    Once these keys expire, it is up to you whether to *renew* these keys by extending the expiration dates or to create *new* subkeys when the existing set expires.
 
-   On the one hand, an adversary who obtains any existing encryption subkey (for example) will be able to use it in order to decrypt all emails (for example) which were encrypted to that subkey.
+   - On the one hand, an adversary who obtains any existing encryption subkey (for example) will be able to use it in order to decrypt all emails (for example) which were encrypted to that subkey.
    If the same subkey were to continue to be used--and its expiration date continually extended--only that one key would need to be stolen (e.g., as a result of the `work-gpg` VM being compromised; see below) in order to decrypt *all* of the user's emails.
    If, on the other hand, each encryption subkey is used for at most approximately one year, then an adversary who obtains the secret subkey will be capable of decrypting at most approximately one year's worth of emails.
 
-   On the other hand, creating a new signing subkey each year without renewing (i.e., extending the expiration dates of) existing signing subkeys would mean that all of your old signatures would eventually read as "EXPIRED" whenever someone attempts to verify them.
+   - On the other hand, creating a new signing subkey each year without renewing (i.e., extending the expiration dates of) existing signing subkeys would mean that all of your old signatures would eventually read as "EXPIRED" whenever someone attempts to verify them.
    This can be problematic, since there is no consensus on how expired signatures should be handled.
    Generally, digital signatures are intended to last forever, so this is a strong reason against regularly retiring one's signing subkeys.
 
 * `pub` (public key)
 
-   This is the complement of the master secret key.
+   - This is the complement of the master secret key.
    It can be uploaded to keyservers (or otherwise publicly distributed) and may be signed by others.
 
 * `vault`
 
-   This is a network-isolated VM.
+   - This is a network-isolated VM.
    The initial master keypair and subkeys are generated in this VM.
    The master secret key *never* leaves this VM under *any* circumstances.
    No files or text is *ever* [copied](/doc/how-to-copy-and-move-files/#security) or [pasted](/doc/how-to-copy-and-paste-text/#security) into this VM under *any* circumstances.
 
 * `work-gpg`
 
-   This is a network-isolated VM.
+   - This is a network-isolated VM.
    This VM is used *only* as the GPG backend for `work-email`.
    The secret subkeys (but *not* the master secret key) are [copied](/doc/how-to-copy-and-move-files/#security) from the `vault` VM to this VM.
    Files from less trusted VMs are *never* [copied](/doc/how-to-copy-and-move-files/#security) into this VM under *any* circumstances.
 
 * `work-email`
 
-   This VM has access to the mail server.
+   - This VM has access to the mail server.
    It accesses the `work-gpg` VM via the Split GPG protocol.
    The public key may be stored in this VM so that it can be attached to emails and for other such purposes.
 

From 117b9ee6a378a9211db5a35cbae40a0cbda4b181 Mon Sep 17 00:00:00 2001
From: Andrew David Wong <adw@qubes-os.org>
Date: Thu, 5 Jun 2025 05:45:51 -0700
Subject: [PATCH 328/332] Remove Joanna from list of security team members

Thanks to oli from the Qubes OS Forum for pointing this out:
https://forum.qubes-os.org/t/qubes-canary-043/34234/2

Full explanation:
https://forum.qubes-os.org/t/qubes-canary-043/34234/3
---
 project-security/security.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/project-security/security.md b/project-security/security.md
index a8b325d8..bf8cff50 100644
--- a/project-security/security.md
+++ b/project-security/security.md
@@ -93,4 +93,3 @@ of the actions listed above.
 
 - [Marek Marczykowski-Górecki](/team/#marek-marczykowski-górecki)
 - [Simon Gaiser (aka HW42)](/team/#simon-gaiser-aka-hw42)
-- [Joanna Rutkowska](/team/#joanna-rutkowska) ([emeritus, canaries only](/news/2018/11/05/qubes-security-team-update/))

From b9a4429552199e2a07f369800514b3edbe5ac153 Mon Sep 17 00:00:00 2001
From: unman <unman@thirdeyesecurity.org>
Date: Thu, 5 Jun 2025 15:18:41 +0000
Subject: [PATCH 329/332] Update KDE page with more detailed information post
 install

---
 user/advanced-topics/kde.md | 40 +++++++++++++++++++++++++++----------
 1 file changed, 29 insertions(+), 11 deletions(-)

diff --git a/user/advanced-topics/kde.md b/user/advanced-topics/kde.md
index c2553f7f..715f928e 100644
--- a/user/advanced-topics/kde.md
+++ b/user/advanced-topics/kde.md
@@ -8,17 +8,37 @@ ref: 176
 title: KDE (desktop environment)
 ---
 
-Installation
-------------
+## Installation
 
 Prior to R3.2, KDE was the default desktop environment in Qubes. Beginning with
-R3.2, however, [XFCE is the new default desktop environment](/doc/releases/3.2/release-notes/). Nonetheless, it is
-still possible to install KDE by issuing this command in dom0:
-
+R3.2, however, [XFCE is the new default desktop environment](/doc/releases/3.2/release-notes/).
+Nonetheless, it is still possible to install KDE by issuing this command in dom0:
 ```shell_session
 $ sudo qubes-dom0-update kde-settings-qubes
 ```
+You may notice some warnings and errors in the installation - it is safe to ignore these.
 
+After the installation is complete log out.
+At the top of the log in screen is a small icon with *X* on it - if you click on it you will see choices between Xfce and
+Plasma. Select the Plasma(X11) option, and log in - you will see that Plasma (the KDE desktop environment) loads.
+
+KDE is very customisable, and there is a range of widgets to use.
+If you want to use the Menu widget, then you must edit `/etc/X11/xinit/xinitrc.d/55xfce-qubes.sh` as follows:
+```
+#!/usr/bin/sh
+
+# Use Qubes provided menu instead of default XFCE one
+if [ "$XDG_SESSION_DESKTOP" = "KDE" ]; then
+XDG_MENU_PREFIX="kf5-"
+else
+XDG_MENU_PREFIX="qubes-"
+fi
+export XDG_MENU_PREFIX
+```
+This allows you to edit the menu as you will. When editing the Menu *DO NOT use the option under "Edit->Restore to System Menu"*
+
+
+### Login manager
 You can also change your default login manager (lightdm) to the new KDE default: sddm
 
 * first you need to edit the `/etc/sddm.conf` to make sure if the custom X parameter is set according to Qubes needs:
@@ -44,8 +64,8 @@ You can also change your default login manager (lightdm) to the new KDE default:
 
 If you encounter performance issues with KDE, try switching back to LightDM.
 
-Window Management
------------------
+
+## Window Management
 
 You can set each window's position and size like this:
 
@@ -67,14 +87,12 @@ You can also use `kstart` to control virtual desktop placement like this:
   kstart --desktop 3 --windowclass <vm_name> -q --tray -a <vm_name> '<run_program_command>'
 ~~~
 
-(Replace "3" with whichever virtual desktop you want the window to be
-on.)
+(Replace "3" with whichever virtual desktop you want the window to be on.)
 
 This can be useful for creating a simple shell script which will set up your
 workspace the way you like.
 
-Removal
-------------
+## Removal
 
 If you decide to remove KDE do **not** use `dnf remove @kde-desktop-qubes`. You will almost certainly break your system.
 

From 823c5f34ba6815f187e314431936b1ca4317c1ec Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Thu, 5 Jun 2025 20:19:22 -0400
Subject: [PATCH 330/332] admin-api reset to upstream

---
 developer/services/admin-api.md | 25 +++++++++++++------------
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/developer/services/admin-api.md b/developer/services/admin-api.md
index 15f7e6dc..f05ee780 100644
--- a/developer/services/admin-api.md
+++ b/developer/services/admin-api.md
@@ -13,7 +13,8 @@ ref: 36
 title: Admin API
 ---
 
-_You may also be interested in the article [Introducing the Qubes Admin API](/news/2017/06/27/qubes-admin-api/)._
+_You may also be interested in the article
+[Introducing the Qubes Admin API](/news/2017/06/27/qubes-admin-api/)._
 
 ## Goals
 
@@ -64,7 +65,7 @@ to set the policy using current mechanism.
 | call                                           | dest       | argument     | inside                                                              | return                                              | note |
 |------------------------------------------------|------------|--------------|---------------------------------------------------------------------|-----------------------------------------------------| ---- |
 | `admin.vmclass.List`                           | `dom0`     | -            | -                                                                   | `<class>\n`                                         |
-| `admin.vm.List`                                | `dom0|<vm>`| -            | -                                                                   | `<name> class=<class> state=<state>\n`              |
+| `admin.vm.List`                                | `dom0      | <vm>`        | -                                                                   | -                                                   | `<name> class=<class> state=<state>\n`                    |
 | `admin.vm.Create.<class>`                      | `dom0`     | template     | `name=<name> label=<label>`                                         | -                                                   |
 | `admin.vm.CreateInPool.<class>`                | `dom0`     | template     | `name=<name> label=<label> `<br/>`pool=<pool> pool:<volume>=<pool>` | -                                                   | either use `pool=` to put all volumes there, <br/>or `pool:<volume>=` for individual volumes - both forms are not allowed at the same time
 | `admin.vm.CreateDisposable`                    | template   | -            | -                                                                   | name                                                | Create new DisposableVM, `template` is any AppVM with `dispvm_allowed` set to True, or `dom0` to use default defined in `default_dispvm` property of calling VM; VM created with this call will be automatically removed after its shutdown; the main difference from `admin.vm.Create.DispVM` is automatic (random) name generation.
@@ -75,17 +76,17 @@ to set the policy using current mechanism.
 | `admin.label.Index`                            | `dom0`     | label        | -                                                                   | `<label-index>`                                     |
 | `admin.label.Remove`                           | `dom0`     | label        | -                                                                   | -                                                   |
 | `admin.property.List`                          | `dom0`     | -            | -                                                                   | `<property>\n`                                      |
-| `admin.property.Get`                           | `dom0`     | property     | -                                                                   | `default={True|False} `<br/>`type={str|int|bool|vm|label|list} <value>`   | Type `list` is added in R4.1. Values are of type `str` and each entry is suffixed with newline character.
+| `admin.property.Get`                           | `dom0`     | property     | -                                                                   | `default={True                                      |False} `<br/>`type={str|int|bool|vm|label|list} <value>`   | Type `list` is added in R4.1. Values are of type `str` and each entry is suffixed with newline character.
 | `admin.property.GetAll`                        | `dom0`     | -            | -                                                                   | `<property-name> <full-value-as-in-property.Get>\n` | Get all the properties in one call. Each property is returned on a separate line and use the same value encoding as property.Get method, with an exception that newlines are encoded as literal `\n` and literal `\` are encoded as `\\`.
-| `admin.property.GetDefault`                    | `dom0`     | property     | -                                                                   | `type={str|int|bool|vm|label|list} <value>`         | Type `list` is added in R4.1. Values are of type `str` and each entry is suffixed with newline character.
+| `admin.property.GetDefault`                    | `dom0`     | property     | -                                                                   | `type={str                                          |int|bool|vm|label|list} <value>`               | Type `list` is added in R4.1. Values are of type `str` and each entry is suffixed with newline character.
 | `admin.property.Help`                          | `dom0`     | property     | -                                                                   | `help`                                              |
 | `admin.property.HelpRst`                       | `dom0`     | property     | -                                                                   | `help.rst`                                          |
 | `admin.property.Reset`                         | `dom0`     | property     | -                                                                   | -                                                   |
 | `admin.property.Set`                           | `dom0`     | property     | value                                                               | -                                                   |
 | `admin.vm.property.List`                       | vm         | -            | -                                                                   | `<property>\n`                                      |
-| `admin.vm.property.Get`                        | vm         | property     | -                                                                   | `default={True|False} `<br/>`type={str|int|bool|vm|label|list} <value>`   | Type `list` is added in R4.1. Each list entry is suffixed with a newline character.
+| `admin.vm.property.Get`                        | vm         | property     | -                                                                   | `default={True                                      |False} `<br/>`type={str|int|bool|vm|label|list} <value>`   | Type `list` is added in R4.1. Each list entry is suffixed with a newline character.
 | `admin.vm.property.GetAll`                     | vm         | -            | -                                                                   | `<property-name> <full-value-as-in-property.Get>\n` | Get all the properties in one call. Each property is returned on a separate line and use the same value encoding as property.Get method, with an exception that newlines are encoded as literal `\n` and literal `\` are encoded as `\\`.
-| `admin.vm.property.GetDefault`                 | vm         | property     | -                                                                   | `type={str|int|bool|vm|label|type} <value>`         | Type `list` is added in R4.1. Each list entry is suffixed with a newline character.
+| `admin.vm.property.GetDefault`                 | vm         | property     | -                                                                   | `type={str                                          |int|bool|vm|label|type} <value>`               | Type `list` is added in R4.1. Each list entry is suffixed with a newline character.
 | `admin.vm.property.Help`                       | vm         | property     | -                                                                   | `help`                                              |
 | `admin.vm.property.HelpRst`                    | vm         | property     | -                                                                   | `help.rst`                                          |
 | `admin.vm.property.Reset`                      | vm         | property     | -                                                                   | -                                                   |
@@ -153,8 +154,8 @@ to set the policy using current mechanism.
 | `admin.backup.Execute`                         | `dom0`     | config id    | -                                                                   | -                                                   | config in `/etc/qubes/backup/<id>.conf`, only one backup operation of given `config id` can be running at once |
 | `admin.backup.Info`                            | `dom0`     | config id    | -                                                                   | backup info                                         | info what would be included in the backup
 | `admin.backup.Cancel`                          | `dom0`     | config id    | -                                                                   | -                                                   | cancel running backup operation
-| `admin.Events`                                 | `dom0| vm` | -            | -                                                                   | events                                              |
-| `admin.vm.Stats`                               | `dom0| vm` | -            | -                                                                   | `vm-stats` events, see below                        | emit VM statistics (CPU, memory usage) in form of events
+| `admin.Events`                                 | `dom0      | vm`          | -                                                                   | -                                                   | events                                                    |
+| `admin.vm.Stats`                               | `dom0      | vm`          | -                                                                   | -                                                   | `vm-stats` events, see below                              | emit VM statistics (CPU, memory usage) in form of events
 
 Volume properties:
 
@@ -218,8 +219,8 @@ Server will close the connection.
 Traceback may be empty, can be enabled server-side as part of debug mode.
 Delimiting zero-byte is always present.
 
-Fields should be fromatted to `%`-style format string, possibly after
-client-side translation, to form final message to be displayed to the user. Server
+Fields are should substituted into `%`-style format string, possibly after
+client-side translation, to form final message to be displayed unto user. Server
 does not by itself support translation.
 
 ## Tags
@@ -227,10 +228,10 @@ does not by itself support translation.
 The tags provided can be used to write custom policies. They are not used in
 a&nbsp;default Qubes OS installation. However, they are created anyway.
 
-- `created-by-<vm>` - Created in an extension to `qubesd` at the
+- `created-by-<vm>` &mdash;&nbsp;Created in an extension to qubesd at the
   moment of creation of the VM. Cannot be changed via API, which is also
   enforced by this extension.
-- `managed-by-<vm>` - Can be used for the same purpose, but it is
+- `managed-by-<vm>` &mdash;&nbsp;Can be used for the same purpose, but it is
   not created automatically, nor is it forbidden to set or reset this tag.
 
 ## Backup profile

From 4554eef3622cda3813ba02a6378cba48b80c205f Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Tue, 1 Jul 2025 03:17:45 -0400
Subject: [PATCH 331/332] exchanged webarchive links, minor wording

---
 developer/releases/4_0/release-notes.md                   | 2 +-
 user/downloading-installing-upgrading/install-security.md | 4 ++--
 user/hardware/certified-hardware/nitropc-pro.md           | 2 +-
 user/security-in-qubes/anti-evil-maid.md                  | 2 +-
 user/templates/fedora/fedora-upgrade.md                   | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/developer/releases/4_0/release-notes.md b/developer/releases/4_0/release-notes.md
index f58eb0b9..1bed1302 100644
--- a/developer/releases/4_0/release-notes.md
+++ b/developer/releases/4_0/release-notes.md
@@ -9,7 +9,7 @@ title: Qubes R4.0 release notes
 New features since 3.2
 ----------------------
 
-* Core management scripts rewrite with better structure and extensibility, [API documentation](https://web.archive.org/web/20230128102821/https://dev.qubes-os.org/projects/qubes-core-admin/en/latest/)
+* Core management scripts rewrite with better structure and extensibility, [current API documentation](https://dev.qubes-os.org/projects/core-admin/en/latest/) and the documentation API index as a [webarchive](https://web.archive.org/web/20230128102821/https://dev.qubes-os.org/projects/qubes-core-admin/en/latest/)
 * [Admin API](/news/2017/06/27/qubes-admin-api/) allowing strictly controlled managing from non-dom0
 * All `qvm-*` command-line tools rewritten, some options have changed
 * Renaming VM directly is prohibited, there is GUI to clone under new name and remove old VM
diff --git a/user/downloading-installing-upgrading/install-security.md b/user/downloading-installing-upgrading/install-security.md
index a113fb5e..f246d8f3 100644
--- a/user/downloading-installing-upgrading/install-security.md
+++ b/user/downloading-installing-upgrading/install-security.md
@@ -1,4 +1,4 @@
----
+    ---
 lang: en
 layout: doc
 permalink: /doc/install-security/
@@ -51,7 +51,7 @@ Cons:
   (If the drive is mounted to a compromised machine, the ISO could be maliciously altered after it has been written to the drive.)
 * Untrustworthy firmware.
   (Firmware can be malicious even if the drive is new.
-  Plugging a drive with rewritable firmware into a compromised machine can also [compromise the drive](https://www.blackhat.com/us-14/briefings.html#badusb-on-accessories-that-turn-evil).
+  Plugging a drive with rewritable firmware into a compromised machine can also [compromise the drive](https://web.archive.org/web/20160304013434/https://srlabs.de/badusb/).
   Installing from a compromised drive could compromise even a brand new Qubes installation.)
 
 ### Optical discs
diff --git a/user/hardware/certified-hardware/nitropc-pro.md b/user/hardware/certified-hardware/nitropc-pro.md
index bce50f0c..d3a65ebc 100644
--- a/user/hardware/certified-hardware/nitropc-pro.md
+++ b/user/hardware/certified-hardware/nitropc-pro.md
@@ -40,7 +40,7 @@ The NitroPC Pro also comes with a "Dasharo Entry Subscription," which includes t
 - Accesses to the latest firmware releases
 - Exclusive newsletter
 - Special firmware updates, including early access to updates enhancing privacy, security, performance, and compatibility
-- Early access to new firmware releases for [newly-supported desktop platforms](https://docs.dasharo.com/variants/overview/#desktop) (please see the [roadmap](https://github.com/Dasharo/presentations/blob/main/archive/dug_2/dug2_dasharo_roadmap.md#dasharo-desktop-roadmap))
+- Early access to new firmware releases for [newly-supported desktop platforms](https://docs.dasharo.com/variants/overview/#desktop) (please see the [roadmap](https://github.com/Dasharo/presentations/blob/8f360b3e82108d1e85585c1c324a28a08dd276a5/dug2_dasharo_roadmap.md))
 - Access to the Dasharo Premier Support invite-only live chat channel on the Matrix network, allowing direct access to the Dasharo Team and fellow subscribers with personalized and priority assistance
 - Insider's view and influence on the Dasharo feature roadmap for a real impact on Dasharo development
 - [Dasharo Tools Suite Entry Subscription](https://docs.dasharo.com/osf-trivia-list/dts/#what-is-dasharo-tools-suite-supporters-entrance) keys
diff --git a/user/security-in-qubes/anti-evil-maid.md b/user/security-in-qubes/anti-evil-maid.md
index 3980b00a..e9b3f205 100644
--- a/user/security-in-qubes/anti-evil-maid.md
+++ b/user/security-in-qubes/anti-evil-maid.md
@@ -43,7 +43,7 @@ Security Considerations
 However, in its default configuration, installing and using AEM requires attaching a USB drive (i.e., [mass storage device](https://en.wikipedia.org/wiki/USB_mass_storage_device_class)) directly to dom0.
 (The other option is to install AEM to an internal disk.
 However, this carries significant security implications, as explained [here](https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html).) This presents us with a classic security trade-off: each Qubes user must make a choice between protecting dom0 from a potentially malicious USB drive, on the one hand, and protecting the system from Evil Maid attacks, on the other hand.
-Given the practical feasibility of attacks like [BadUSB](https://www.blackhat.com/us-14/briefings.html#badusb-on-accessories-that-turn-evil) and revelations regarding pervasive government hardware backdoors, this is no longer a straightforward decision.
+Given the practical feasibility of attacks like [BadUSB](https://web.archive.org/web/20160304013434/https://srlabs.de/badusb/) and revelations regarding pervasive government hardware backdoors, this is no longer a straightforward decision.
 New, factory-sealed USB drives cannot simply be assumed to be "clean" (e.g., to have non-malicious microcontroller firmware).
 Therefore, it is up to each individual Qubes user to evaluate the relative risk of each attack vector against his or her security model.
 
diff --git a/user/templates/fedora/fedora-upgrade.md b/user/templates/fedora/fedora-upgrade.md
index 969d63bc..932f8b7d 100644
--- a/user/templates/fedora/fedora-upgrade.md
+++ b/user/templates/fedora/fedora-upgrade.md
@@ -121,7 +121,7 @@ The same general procedure may be used to upgrade any template based on the stan
 
        If this attempt is successful, proceed to step 4.
 
-     - `dnf` may complain: `At least X MB more space needed on the / filesystem.`
+     - `dnf` may error with the text: `At least X MB more space needed on the / filesystem.`
 
        In this case, one option is to [resize the template's disk image](/doc/resize-disk-image/) before reattempting the upgrade process.
        (See [Additional Information](#additional-information) below for other options.)

From e3db139fe3a5c2be20f6624717905fd6871c5e75 Mon Sep 17 00:00:00 2001
From: qubedmaiska <qubedmaiska@protonmail.com>
Date: Tue, 1 Jul 2025 16:12:00 -0400
Subject: [PATCH 332/332] fixed a tab

---
 user/downloading-installing-upgrading/install-security.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/downloading-installing-upgrading/install-security.md b/user/downloading-installing-upgrading/install-security.md
index f246d8f3..cd94af58 100644
--- a/user/downloading-installing-upgrading/install-security.md
+++ b/user/downloading-installing-upgrading/install-security.md
@@ -1,4 +1,4 @@
-    ---
+---
 lang: en
 layout: doc
 permalink: /doc/install-security/