Merge branch 'QubesOS:master' into master

developer/releases/4_3/release-notes.rst

@@ -261,9 +261,6 @@ Other
 - New Devices API for salt
   (`#9753 <https://github.com/QubesOS/qubes-issues/issues/9753>`__).
 
-- IPv6 DNS support for full IPv4-less environments
-  (`#10038 <https://github.com/QubesOS/qubes-issues/issues/10038>`__).
-
 Dropped or replaced features
 ----------------------------
 

developer/releases/4_3/schedule.rst

@@ -24,4 +24,6 @@ The table below is based on our :ref:`release-schedule-policy`.
      - `4.3.0-rc2 release <https://www.qubes-os.org/news/2025/09/19/qubes-os-4-3-0-rc2-available-for-testing/>`_
    * - 2025-10-27
      - `4.3.0-rc3 release <https://www.qubes-os.org/news/2025/10/27/qubes-os-4-3-0-rc3-available-for-testing/>`_
+   * - 2025-12-06
+     - `4.3.0-rc4 release <https://www.qubes-os.org/news/2025/12/06/qubes-os-4-3-0-rc4-available-for-testing/>`_
 

developer/services/disposablevm-implementation.rst

@@ -66,13 +66,16 @@ Preloaded disposable's management
 
 These are common events that trigger changes in preloaded disposables quantity:
 
-- Setting or deleting the ``preload-dispvm-max`` feature will refill or remove;
-- (Re)starting :file:`qubes-preload-dispvm.service` will refresh;
-- Using a preloaded disposable will refill;
-- Requesting a disposable will refill;
-- Updating the volumes of a template or disposable template will refresh;
-- Changing system's :py:attr:`default_dispvm <core-admin:qubes.vm.dispvm.DispVM.default_dispvm>` while system's feature is set to a different value than the disposable template setting will refill or remove; and
-- Qubesd was interrupted mid preload creation, on the next service restart, :py:meth:`domain-load <core-admin:qubes.vm.mix.dvmtemplate.DVMTemplateMixin.on_domain_loaded>` of the disposable template will refresh the incomplete disposables.
+- Refill or remove:
+  - Changing the ``preload-dispvm-max`` feature;
+  - Changing system's :py:attr:`default_dispvm <core-admin:qubes.vm.dispvm.DispVM.default_dispvm>` while system's feature is set to a different value than the disposable template setting;
+- Refill:
+  - (Re)starting :file:`qubes-preload-dispvm.service`;
+  - Using a preloaded disposable;
+  - Requesting a disposable;
+- Refresh:
+  - Updating the volumes of a template or disposable template;
+  - Qubesd was interrupted mid preload creation, on the next service restart, :py:meth:`domain-load <core-admin:qubes.vm.mix.dvmtemplate.DVMTemplateMixin.on_domain_loaded>` of the disposable template.
 
 Preloaded disposable's temporary gaps
 """""""""""""""""""""""""""""""""""""
@@ -113,13 +116,6 @@ Preloaded disposables are paused for various reasons:
 
 But this comes at a cost:
 
-- Can only connect to the GUI after the qube is requested (longer run time), else, if `early GUI connection was made before the qube is paused <https://github.com/qubesos/qubes-issues/issues/9940>`__:
-
-  - Events such as screen resize by plugging or removing external monitors can't work;
-  - No easy way to hide autostarted applications, depends on qube collaboration;
-  - Can only preload after GUI login to be able to establish a connection;
-  - Can't survive GUI login and logout as the connection might change;
-
 - Memory management before pause may take some seconds, that is not prejudicial to the time to use the qube but it is prejudicial to the system as :doc:`qmemman </developer/services/qmemman>` can not balloon/balance other qubes in the mean time due to its design.
 
 Preloaded disposable's security
@@ -131,12 +127,14 @@ As preloaded disposables are started before being used, methods to prevent accid
 - The qube has the ``internal`` feature enabled, Qubes GUI applications were patched to hide and show :term:`internal qubes<internal qube>` by handling events for ``domain-feature-((pre-)?set|delete):internal``;
 - When requesting an unnamed disposable, the qube object is only returned to the user once it has finished preloading;
 - The qube is paused as the last stage of preloading, this permits receiving :py:meth:`domain-unpaused <core-admin:qubes.vm.dispvm.DispVM.on_domain_unpaused>` event and be notified that the qube was used, marked as such and removed from the preload list to avoid reuse, even without the qube being requested with :py:meth:`core-admin:qubes.vm.dispvm.DispVM.from_appvm`;
-- The GUID only connects to the GUI agent on the qube after the preloaded disposable is marked as used, this prevents that an autostarted application such as a terminal appears on the screen before preloading has finished. Enabling a GUI is is controlled by the :py:attr:`is_preload <core-admin:qubes.vm.dispvm.DispVM.is_preload>` property, that when disabled, allows the GUI connection to initiate. This method delays GUI calls considerably as establishing the connection can take ~2 seconds, research is being done to prevent this delay.
+- The GUID and Audio daemon only connects to the GUI agent and audio agent on the qube after the preloaded disposable is marked as used, this prevents that an autostarted applications appearing on the screen before it is ready or before pause, which could be confusing. Enabling a GUI is controlled by the :py:attr:`is_preload <core-admin:qubes.vm.dispvm.DispVM.is_preload>` property, that when disabled, allows the GUI and audio connection to initiate.
 
 Another point of security is reliability:
 
 - The ``preload-dispvm-threshold`` feature controls how much free memory must be present on the system before attempting to create a new preloaded disposable. Used to ensure preloaded disposables do not consume all available memory, which would prevent starting other qubes.
 
+To have late GUI daemon but an early GUI agent, changes have been made that limit the usability on ``sys-gui``. `Events such as plugging or removing external monitors can't work, it will be ignored by Xephyr <https://github.com/QubesOS/qubes-gui-agent-linux/pull/253>`__.
+
 Alternatives considered
 ^^^^^^^^^^^^^^^^^^^^^^^
 

requirements.txt

@@ -33,5 +33,5 @@ sphinxext-opengraph==0.12.0
 sphinxnotes-any==2.5
 sphinxnotes-comboroles==1.0
 sphinxnotes-strike==1.2.1
-urllib3==2.5.0
+urllib3==2.6.0
 Wand==0.6.13

user/advanced-topics/installing-contributed-packages.rst

@@ -8,7 +8,7 @@ Installing contributed packages
 
 *This page is for users who wish to install contributed packages. If you want to contribute a package, please see* :doc:`package contributions </developer/general/package-contributions>` *.*
 
-Qubes OS contributed packages are available under the `QubesOS-contrib <https://github.com/QubesOS-contrib/>`__ GitHub Project. This is a place where our community can :doc:`contribute Qubes OS related packages, additions and various customizations </developer/general/package-contributions>`.
+Contributed packages are software created by the community of Qubes OS users. They are managed, reviewed, and signed by the Qubes OS maintainer team to ensure they are safe to install on Qubes OS. Qubes OS contributed packages are available under the `QubesOS-contrib <https://github.com/QubesOS-contrib/>`__ GitHub Project. This is a place where our community can :doc:`contribute Qubes OS related packages, additions and various customizations </developer/general/package-contributions>`.
 
 Installing the repositories
 ---------------------------

user/advanced-topics/standalones-and-hvms.rst

@@ -32,7 +32,7 @@ PVH has less attack surface than PV, as it relies on Second Level Address Transl
 
 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.
+PVH has better performance than HVM, as the stubdomain in 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.
 
@@ -80,7 +80,7 @@ Using the GUI
 ^^^^^^^^^^^^^
 
 
-In Qube Manager, select “Create new qube” from the Qube menu, or select the “Create a new qube” button. In the “create new qube” dialog box set Type to “Empty standalone qube (install your own OS)”. If “install system from device” is selected (which it is by default), then ``virt_mode`` will be set to ``hvm`` automatically. Otherwise, open the newly-created qube’s Settings GUI and, in the “Advanced” tab, select ``HVM`` in the virtualization mode drop-down list. Also, make sure “Kernel” is set to ``(none)`` on the same tab.
+In Qube Manager, use either the "New qube" button, or the "New qube" entry in the "Qube" menu. In the "Create new qube" dialog box click on tab "Standalone". If "install system from device" is selected (which it is by default), then ``virt_mode`` will be set to ``hvm`` automatically. Otherwise, open the newly-created qube’s Settings GUI and, in the "Advanced" tab, select ``HVM`` in the virtualization mode drop-down list. Also, make sure “Kernel” is set to ``(none)`` on the same tab.
 
 Command line
 ^^^^^^^^^^^^

user/how-to-guides/how-to-use-disposables.rst

@@ -156,7 +156,7 @@ The same can be done from the command line, although more difficult:
       ")"
       user@dom0:~$ qvm-device <DEVICE_CLASS> attach <ATTACH_OPTIONS> -- "$disp" <BACKEND:DEVICE_ID>
       user@dom0:~$ # Do your tasks.
-      user@dom0:~$ qvm-device <DEVICE_CLASS> dettach <ATTACH_OPTIONS> -- "$disp"
+      user@dom0:~$ qvm-device <DEVICE_CLASS> detach <ATTACH_OPTIONS> -- "$disp"
       user@dom0:~$ qvm-kill -- "$disp"
 
 Retrieve unnamed disposables faster (preloaded disposables)