openQA to support other resolutions too, but for now I have set the resolution
on the tested system to 1024x768 (and used an EDID that lists that resolution).
on the tested system to 1024x768 (and used an EDID that lists that resolution).
On the test system, something needs to actually enable HDMI output. For this
purpose, I passed a kickstart file to the Qubes OS installer that includes
commands to execute before installation (the %pre section). While at it, I
could use the same kickstart file for other test-related customizations, like
restoring the default boot order at the end or enabling SSH access for
collecting logs.
HID input
Recording video output is not everything. To run tests, one also needs to send
commands to the system under test (SUT). This can be done in several ways,
including via serial console and SSH connection. In order to have the most
realistic setup, I chose to emulate USB input devices. With this, we could
interact with the system in the same way a user would. To emulate USB input
device(s), I used the Linux USB Gadget subsystem. To emulate HID devices, I had
to prepare a HID denoscriptor — a denoscription for the driver, listing what kind
of device it is and what events it can send.
I wanted the device(s) to meet the following requirements:
Have two interfaces (which in practice is two separate HID devices): keyboard
and pointer (mouse/tablet)
Be properly categorized by udev (so the input
proxy (https://github.com/QubesOS/qubes-app-linux-input-proxy) picks it up
properly)
Be properly categorized by Xorg
Support both absolute pointer position events (like “move mouse to a specific
point” instead of “move mouse a bit to the right”) and normal mouse buttons
I searched for a denoscriptor meeting the above requirements. The one for
keyboards is rather standard, but the one for mouse/tablet devices is not. So,
I took the Device Class Definition for HID 1.11 together with HID Usage Tables
1.22 (https://www.usb.org/hid) and crafted one myself. This was a bit of a
challenge, because both udev and Xorg have a set of heuristics to categorize
devices, and they differ in subtle ways.
Then, I wrote a
noscript (https://gist.github.com/marmarek/5c44ffeb2f36e106b4d34e7e8780c208)
that sets this all up and controls the device(s) according to what openQA
requests.
The last detail is about connecting an RPi to the target system. The RPi4 has a
single USB-C port used both for powering the RPi itself as well as for USB
device emulation. Generally, this would be fine, with the exception that the
target system is going to be disconnected from power from time to time. If the
RPi were powered this way, it would lose power too, and there would be nothing
capable of turning it back on. This is yet another case where the PiKVM project
provided an inspiration (https://github.com/pikvm/pikvm#setting-up-the-v2): a
Y-split cable that connects the VBUS pin to only one end and the data pins to
the other.
Serial console
Several openQA functions require some kind of console access. This includes
retrieving command outputs (and exit codes), waiting for various events, etc.
Unfortunately, a real serial console is very rare in modern laptops. I could
restructure the tests not to use those functions, but that would be rather
disappointing in terms of test result quality. As a solution, I added a small
qrexec service in dom0 that reads a pipe that pretends to be a serial console,
then I used qvm-connect-tcp in sys-net to redirect the TCP port to that
service. This isn’t as reliable as a real serial console (especially for things
like restarting sys-net), but it does work in the majority of cases. In the
future, I will restructure the tests not to rely on this functionality in order
to account for the few rare cases where it doesn’t work.
Bonus: remote-controlled test laptops for developers
Remote power and boot control is useful not only for automatic tests, but also
for ordinary developers. There are several cases where it is useful:
Additional machines to develop and test features on different versions of
Qubes
Access to specific hardware
I’ve prepared the whole setup to be usable not only with openQA, but also to
purpose, I passed a kickstart file to the Qubes OS installer that includes
commands to execute before installation (the %pre section). While at it, I
could use the same kickstart file for other test-related customizations, like
restoring the default boot order at the end or enabling SSH access for
collecting logs.
HID input
Recording video output is not everything. To run tests, one also needs to send
commands to the system under test (SUT). This can be done in several ways,
including via serial console and SSH connection. In order to have the most
realistic setup, I chose to emulate USB input devices. With this, we could
interact with the system in the same way a user would. To emulate USB input
device(s), I used the Linux USB Gadget subsystem. To emulate HID devices, I had
to prepare a HID denoscriptor — a denoscription for the driver, listing what kind
of device it is and what events it can send.
I wanted the device(s) to meet the following requirements:
Have two interfaces (which in practice is two separate HID devices): keyboard
and pointer (mouse/tablet)
Be properly categorized by udev (so the input
proxy (https://github.com/QubesOS/qubes-app-linux-input-proxy) picks it up
properly)
Be properly categorized by Xorg
Support both absolute pointer position events (like “move mouse to a specific
point” instead of “move mouse a bit to the right”) and normal mouse buttons
I searched for a denoscriptor meeting the above requirements. The one for
keyboards is rather standard, but the one for mouse/tablet devices is not. So,
I took the Device Class Definition for HID 1.11 together with HID Usage Tables
1.22 (https://www.usb.org/hid) and crafted one myself. This was a bit of a
challenge, because both udev and Xorg have a set of heuristics to categorize
devices, and they differ in subtle ways.
Then, I wrote a
noscript (https://gist.github.com/marmarek/5c44ffeb2f36e106b4d34e7e8780c208)
that sets this all up and controls the device(s) according to what openQA
requests.
The last detail is about connecting an RPi to the target system. The RPi4 has a
single USB-C port used both for powering the RPi itself as well as for USB
device emulation. Generally, this would be fine, with the exception that the
target system is going to be disconnected from power from time to time. If the
RPi were powered this way, it would lose power too, and there would be nothing
capable of turning it back on. This is yet another case where the PiKVM project
provided an inspiration (https://github.com/pikvm/pikvm#setting-up-the-v2): a
Y-split cable that connects the VBUS pin to only one end and the data pins to
the other.
Serial console
Several openQA functions require some kind of console access. This includes
retrieving command outputs (and exit codes), waiting for various events, etc.
Unfortunately, a real serial console is very rare in modern laptops. I could
restructure the tests not to use those functions, but that would be rather
disappointing in terms of test result quality. As a solution, I added a small
qrexec service in dom0 that reads a pipe that pretends to be a serial console,
then I used qvm-connect-tcp in sys-net to redirect the TCP port to that
service. This isn’t as reliable as a real serial console (especially for things
like restarting sys-net), but it does work in the majority of cases. In the
future, I will restructure the tests not to rely on this functionality in order
to account for the few rare cases where it doesn’t work.
Bonus: remote-controlled test laptops for developers
Remote power and boot control is useful not only for automatic tests, but also
for ordinary developers. There are several cases where it is useful:
Additional machines to develop and test features on different versions of
Qubes
Access to specific hardware
I’ve prepared the whole setup to be usable not only with openQA, but also to
👍2🤮1
allow for the delegation of specific test machines to individual trusted
developers. More importantly, this allows not only for manually testing
software on those machines, but also for automating several tasks, such as the
Git bisection mentioned earlier.
Final thoughts
Testing a whole operating system is a challenging task, because there are a lot
of moving parts. OpenQA is a great tool for that, but its main target is
running tests in a virtualized environment. This works fine for several
components (like Qubes Manager and GUI virtualization) but not for
hardware-related features (sys-net, sys-usb, system suspend, and several
others). Before this work, we ran tests on actual laptops manually, but that
was time-consuming and thus not all updates or configurations were tested.
Automation allows our testing to be much more comprehensive, including ensuring
ongoing compatibility with Qubes OS certified hardware.
developers. More importantly, this allows not only for manually testing
software on those machines, but also for automating several tasks, such as the
Git bisection mentioned earlier.
Final thoughts
Testing a whole operating system is a challenging task, because there are a lot
of moving parts. OpenQA is a great tool for that, but its main target is
running tests in a virtualized environment. This works fine for several
components (like Qubes Manager and GUI virtualization) but not for
hardware-related features (sys-net, sys-usb, system suspend, and several
others). Before this work, we ran tests on actual laptops manually, but that
was time-consuming and thus not all updates or configurations were tested.
Automation allows our testing to be much more comprehensive, including ensuring
ongoing compatibility with Qubes OS certified hardware.
👍3👏3🤮1
Fedora 34 approaching EOL; Fedora 35 templates available
https://www.qubes-os.org/news/2022/05/26/fedora-34-approaching-eol-fedora-35-templates-available/
Fedora 34 is scheduled to reach EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)) on 2022-06-07, and
new Fedora 35 templates are now available for both Qubes 4.0 and 4.1.
We strongly recommend that all Qubes users upgrade (https://www.qubes-os.org/doc/templates/fedora/#upgrading) their Fedora 34
templates and standalones to Fedora 35 before Fedora 34 reaches EOL.
We provide fresh Fedora 35 template packages through the official Qubes
repositories, which you can install in dom0 by following the standard
installation instructions (https://www.qubes-os.org/doc/templates/fedora/#installing). Alternatively, we also provide step-by-step
instructions for performing an in-place upgrade (https://www.qubes-os.org/doc/templates/fedora/) of an existing Fedora
template. After upgrading your templates, please remember to switch all
qubes that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).
For a complete list of template releases that are supported for your
specific Qubes release, see our supported template releases (https://www.qubes-os.org/doc/supported-releases/#templates).
Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL (https://www.qubes-os.org/doc/supported-releases/#note-on-dom0-and-eol).
https://www.qubes-os.org/news/2022/05/26/fedora-34-approaching-eol-fedora-35-templates-available/
Fedora 34 is scheduled to reach EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)) on 2022-06-07, and
new Fedora 35 templates are now available for both Qubes 4.0 and 4.1.
We strongly recommend that all Qubes users upgrade (https://www.qubes-os.org/doc/templates/fedora/#upgrading) their Fedora 34
templates and standalones to Fedora 35 before Fedora 34 reaches EOL.
We provide fresh Fedora 35 template packages through the official Qubes
repositories, which you can install in dom0 by following the standard
installation instructions (https://www.qubes-os.org/doc/templates/fedora/#installing). Alternatively, we also provide step-by-step
instructions for performing an in-place upgrade (https://www.qubes-os.org/doc/templates/fedora/) of an existing Fedora
template. After upgrading your templates, please remember to switch all
qubes that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).
For a complete list of template releases that are supported for your
specific Qubes release, see our supported template releases (https://www.qubes-os.org/doc/supported-releases/#templates).
Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL (https://www.qubes-os.org/doc/supported-releases/#note-on-dom0-and-eol).
🎉3
Fedora 34 has reached EOL
https://www.qubes-os.org/news/2022/06/07/fedora-34-eol/
As a reminder following our previous announcement (https://www.qubes-os.org/news/2022/05/26/fedora-34-approaching-eol-fedora-35-templates-available/), Fedora 34 has now
reached EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)). If you have not already done so, we
strongly recommend upgrading (https://www.qubes-os.org/doc/templates/fedora/#upgrading) all remaining Fedora 34 templates and
standalones to Fedora 35 immediately.
We provide fresh Fedora 35 template packages through the official Qubes
repositories, which you can install in dom0 by following the standard
installation instructions (https://www.qubes-os.org/doc/templates/fedora/#installing). Alternatively, we also provide step-by-step
instructions for performing an in-place upgrade (https://www.qubes-os.org/doc/templates/fedora/in-place-upgrade/) of an existing Fedora
template. After upgrading your templates, please remember to switch all
qubes that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).
For a complete list of template releases that are supported for your
specific Qubes release, see our supported template releases (https://www.qubes-os.org/doc/supported-releases/#templates).
Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL (https://www.qubes-os.org/doc/supported-releases/#note-on-dom0-and-eol).
https://www.qubes-os.org/news/2022/06/07/fedora-34-eol/
As a reminder following our previous announcement (https://www.qubes-os.org/news/2022/05/26/fedora-34-approaching-eol-fedora-35-templates-available/), Fedora 34 has now
reached EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)). If you have not already done so, we
strongly recommend upgrading (https://www.qubes-os.org/doc/templates/fedora/#upgrading) all remaining Fedora 34 templates and
standalones to Fedora 35 immediately.
We provide fresh Fedora 35 template packages through the official Qubes
repositories, which you can install in dom0 by following the standard
installation instructions (https://www.qubes-os.org/doc/templates/fedora/#installing). Alternatively, we also provide step-by-step
instructions for performing an in-place upgrade (https://www.qubes-os.org/doc/templates/fedora/in-place-upgrade/) of an existing Fedora
template. After upgrading your templates, please remember to switch all
qubes that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).
For a complete list of template releases that are supported for your
specific Qubes release, see our supported template releases (https://www.qubes-os.org/doc/supported-releases/#templates).
Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL (https://www.qubes-os.org/doc/supported-releases/#note-on-dom0-and-eol).
XSAs released on 2022-06-09
https://www.qubes-os.org/news/2022/06/09/xsas-released-on-2022-06-09/
The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is affected.
Therefore, user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
XSA-401
XSA-402
Please see QSB-080 for the actions users must take in order to
protect themselves, as well as further details about these XSAs:
https://www.qubes-os.org/news/2022/06/09/qsb-080/
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
(none)
Related links
Xen XSA list: https://xenbits.xen.org/xsa/
Qubes XSA tracker: https://www.qubes-os.org/security/xsa/
Qubes security pack (qubes-secpack): https://www.qubes-os.org/security/pack/
Qubes security bulletins (QSBs): https://www.qubes-os.org/security/qsb/
https://www.qubes-os.org/news/2022/06/09/xsas-released-on-2022-06-09/
The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is affected.
Therefore, user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
XSA-401
XSA-402
Please see QSB-080 for the actions users must take in order to
protect themselves, as well as further details about these XSAs:
https://www.qubes-os.org/news/2022/06/09/qsb-080/
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
(none)
Related links
Xen XSA list: https://xenbits.xen.org/xsa/
Qubes XSA tracker: https://www.qubes-os.org/security/xsa/
Qubes security pack (qubes-secpack): https://www.qubes-os.org/security/pack/
Qubes security bulletins (QSBs): https://www.qubes-os.org/security/qsb/
QSB-080: Issues with PV domains and PCI passthrough (XSA-401, XSA-402)
https://www.qubes-os.org/news/2022/06/09/qsb-080/
We have just published Qubes Security Bulletin (QSB) 080:
Issues with PV domains and PCI passthrough (XSA-401, XSA-402).
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB-080 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-080-2022.txt
In addition, you may wish to:
Get the qubes-secpack: https://www.qubes-os.org/security/pack/
View all past QSBs: https://www.qubes-os.org/security/qsb/
View the XSA Tracker: https://www.qubes-os.org/security/xsa/
---===[ Qubes Security Bulletin 080 ]===---
2022-06-09
Issues with PV domains and PCI passthrough (XSA-401, XSA-402)
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0, in dom0:
- Xen packages, version 4.8.5-40
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.5-2
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Summary
--------
The following security advisories were published on 2022-06-09:
XSA-401 [3] "x86 pv: Race condition in typeref acquisition":
| Xen maintains a type reference count for pages, in addition to a
| regular reference count. This scheme is used to maintain invariants
| required for Xen's safety, e.g. PV guests may not have direct
| writeable access to pagetables; updates need auditing by Xen.
|
| Unfortunately, the logic for acquiring a type reference has a race
| condition, whereby a safely TLB flush is issued too early and creates
| a window where the guest can re-establish the read/write mapping
| before writeability is prohibited.
XSA-402 [4] "x86 pv: Insufficient care with non-coherent mappings":
| Xen maintains a type reference count for pages, in addition to a
| regular reference count. This scheme is used to maintain invariants
| required for Xen's safety, e.g. PV guests may not have direct
| writeable access to pagetables; updates need auditing by Xen.
|
| Unfortunately, Xen's safety logic doesn't account for CPU-induced
| cache non-coherency; cases where the CPU can cause the content of the
| cache to be different to the content in main memory. In such cases,
| Xen's safety logic can incorrectly conclude that the contents of a
| page is safe.
Impact
-------
These vulnerabilities, if exploited, could allow malicious PV domains
with assigned PCI devices to escalate their privileges to that of the
host. However, in the default Qubes OS configuration, these
vulnerabilities affect only the stubdomains for sys-net and sys-usb.
Therefore, in order to exploit these vulnerabilities in a default Qubes
installation, an adversary would first have to discover and exploit an
independent vulnerability in QEMU in order to gain control of an
appropriate stubdomain. Only after having done so would the adversary be
in a position to attempt to exploit the vulnerabilities discussed in
this bulletin.
XSA-402 affects only AMD systems and Intel systems before Ivy Bridge
(the third generation of the Intel Core processors). Newer Intel systems
are not affected.
Credits
--------
See the original Xen Security Advisory.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
https://www.qubes-os.org/news/2022/06/09/qsb-080/
We have just published Qubes Security Bulletin (QSB) 080:
Issues with PV domains and PCI passthrough (XSA-401, XSA-402).
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB-080 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-080-2022.txt
In addition, you may wish to:
Get the qubes-secpack: https://www.qubes-os.org/security/pack/
View all past QSBs: https://www.qubes-os.org/security/qsb/
View the XSA Tracker: https://www.qubes-os.org/security/xsa/
---===[ Qubes Security Bulletin 080 ]===---
2022-06-09
Issues with PV domains and PCI passthrough (XSA-401, XSA-402)
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0, in dom0:
- Xen packages, version 4.8.5-40
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.5-2
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Summary
--------
The following security advisories were published on 2022-06-09:
XSA-401 [3] "x86 pv: Race condition in typeref acquisition":
| Xen maintains a type reference count for pages, in addition to a
| regular reference count. This scheme is used to maintain invariants
| required for Xen's safety, e.g. PV guests may not have direct
| writeable access to pagetables; updates need auditing by Xen.
|
| Unfortunately, the logic for acquiring a type reference has a race
| condition, whereby a safely TLB flush is issued too early and creates
| a window where the guest can re-establish the read/write mapping
| before writeability is prohibited.
XSA-402 [4] "x86 pv: Insufficient care with non-coherent mappings":
| Xen maintains a type reference count for pages, in addition to a
| regular reference count. This scheme is used to maintain invariants
| required for Xen's safety, e.g. PV guests may not have direct
| writeable access to pagetables; updates need auditing by Xen.
|
| Unfortunately, Xen's safety logic doesn't account for CPU-induced
| cache non-coherency; cases where the CPU can cause the content of the
| cache to be different to the content in main memory. In such cases,
| Xen's safety logic can incorrectly conclude that the contents of a
| page is safe.
Impact
-------
These vulnerabilities, if exploited, could allow malicious PV domains
with assigned PCI devices to escalate their privileges to that of the
host. However, in the default Qubes OS configuration, these
vulnerabilities affect only the stubdomains for sys-net and sys-usb.
Therefore, in order to exploit these vulnerabilities in a default Qubes
installation, an adversary would first have to discover and exploit an
independent vulnerability in QEMU in order to gain control of an
appropriate stubdomain. Only after having done so would the adversary be
in a position to attempt to exploit the vulnerabilities discussed in
this bulletin.
XSA-402 affects only AMD systems and Intel systems before Ivy Bridge
(the third generation of the Intel Core processors). Newer Intel systems
are not affected.
Credits
--------
See the original Xen Security Advisory.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://xenbits.xen.org/xsa/advisory-401.html
[4] https://xenbits.xen.org/xsa/advisory-402.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
[4] https://xenbits.xen.org/xsa/advisory-402.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Qubes Canary 031
https://www.qubes-os.org/news/2022/06/12/canary-031/
We have published Qubes Canary 031. The text of this canary is
reproduced below.
This canary and its accompanying signatures will always be available in
the Qubes security pack (qubes-secpack).
View Qubes Canary 031 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-031-2022.txt
Learn how to obtain and authenticate the qubes-secpack and all the
signatures it contains:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canary/
---===[ Qubes Canary 031 ]===---
Statements
-----------
The Qubes security team members who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is June 11, 2022.
2. There have been 80 Qubes security bulletins published so far.
3. The Qubes Master Signing Key fingerprint is:
427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).
5. We plan to publish the next of these canary statements in the first
fourteen days of September 2022. Special note should be taken if no new
canary is published by that time or if the list of statements changes
without plausible explanation.
Special announcements
----------------------
None.
Disclaimers and notes
----------------------
We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently compromised.
This means that we assume NO trust in any of the servers or services
which host or provide any Qubes-related data, in particular, software
updates, source code repositories, and Qubes ISO downloads.
This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other means,
like blackmail or compromising the signers' laptops, to coerce us to
produce false declarations.
The proof of freshness provided below serves to demonstrate that this
canary could not have been created prior to the date stated. It shows
that a series of canaries was not created in advance.
This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to anybody.
None of the signers should be ever held legally responsible for any of
the statements made here.
Proof of freshness
-------------------
Sat, 11 Jun 2022 16:02:15 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
The Artillery War in the Donbas: Ukraine Relying Heavily on Heavy Weapons from the West
Ongoing Dependence on Russian Energy: The Natural Gas Continues to Flow
Europe's Top Prosecutor Brings In More Money than She Spends
The Courageous Women of Kabul: Standing Up to the Taliban's Burqa Decree
Kremlin Threats: Europe Has To Learn To Defend Itself, But How?
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
‘We Buried Him and Kept Walking’: Children Die as Somalis Flee Hunger
Rumbling Through Modern Jordan, a Railway From the Past
McDonald’s Is Reinvented in Russia as the Economy Stumbles On
Newly United, French Left Hopes to Counter President in Upcoming Vote
Recording India’s Linguistic Riches as Leaders Push Hindi as Nation’s Tongue
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Russia hands out passports in occupied Ukraine cities
Putin and Peter the Great: Russian leader likens himself to 18th Century tsar
China warns Taiwan independence would trigger war
Qatar World Cup 2022: German ex-football star says host's treatment of gay people is unacceptable
China: Footage of women attacked in restaurant sparks outrage
Source: Blockchain.info
https://www.qubes-os.org/news/2022/06/12/canary-031/
We have published Qubes Canary 031. The text of this canary is
reproduced below.
This canary and its accompanying signatures will always be available in
the Qubes security pack (qubes-secpack).
View Qubes Canary 031 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-031-2022.txt
Learn how to obtain and authenticate the qubes-secpack and all the
signatures it contains:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canary/
---===[ Qubes Canary 031 ]===---
Statements
-----------
The Qubes security team members who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is June 11, 2022.
2. There have been 80 Qubes security bulletins published so far.
3. The Qubes Master Signing Key fingerprint is:
427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).
5. We plan to publish the next of these canary statements in the first
fourteen days of September 2022. Special note should be taken if no new
canary is published by that time or if the list of statements changes
without plausible explanation.
Special announcements
----------------------
None.
Disclaimers and notes
----------------------
We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently compromised.
This means that we assume NO trust in any of the servers or services
which host or provide any Qubes-related data, in particular, software
updates, source code repositories, and Qubes ISO downloads.
This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other means,
like blackmail or compromising the signers' laptops, to coerce us to
produce false declarations.
The proof of freshness provided below serves to demonstrate that this
canary could not have been created prior to the date stated. It shows
that a series of canaries was not created in advance.
This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to anybody.
None of the signers should be ever held legally responsible for any of
the statements made here.
Proof of freshness
-------------------
Sat, 11 Jun 2022 16:02:15 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
The Artillery War in the Donbas: Ukraine Relying Heavily on Heavy Weapons from the West
Ongoing Dependence on Russian Energy: The Natural Gas Continues to Flow
Europe's Top Prosecutor Brings In More Money than She Spends
The Courageous Women of Kabul: Standing Up to the Taliban's Burqa Decree
Kremlin Threats: Europe Has To Learn To Defend Itself, But How?
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
‘We Buried Him and Kept Walking’: Children Die as Somalis Flee Hunger
Rumbling Through Modern Jordan, a Railway From the Past
McDonald’s Is Reinvented in Russia as the Economy Stumbles On
Newly United, French Left Hopes to Counter President in Upcoming Vote
Recording India’s Linguistic Riches as Leaders Push Hindi as Nation’s Tongue
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Russia hands out passports in occupied Ukraine cities
Putin and Peter the Great: Russian leader likens himself to 18th Century tsar
China warns Taiwan independence would trigger war
Qatar World Cup 2022: German ex-football star says host's treatment of gay people is unacceptable
China: Footage of women attacked in restaurant sparks outrage
Source: Blockchain.info
000000000000000000032e9b82971c2ef2eb1362c65e01f1db5f60fa81fd5eef
Footnotes
----------
[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this canary
in the qubes-secpack.git repo, and (2) via digital signatures on the
corresponding qubes-secpack.git repo tags. [2]
[2] Don't just trust the contents of this file blindly! Verify the
digital signatures! Instructions for doing so are documented here:
https://www.qubes-os.org/security/pack/
--
The Qubes Security Team
https://www.qubes-os.org/security/
Footnotes
----------
[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this canary
in the qubes-secpack.git repo, and (2) via digital signatures on the
corresponding qubes-secpack.git repo tags. [2]
[2] Don't just trust the contents of this file blindly! Verify the
digital signatures! Instructions for doing so are documented here:
https://www.qubes-os.org/security/pack/
--
The Qubes Security Team
https://www.qubes-os.org/security/
👍1
QSB-081: x86: MMIO Stale Data vulnerabilities (XSA-404)
https://www.qubes-os.org/news/2022/06/17/qsb-081/
We have just published Qubes Security Bulletin (QSB) 081:
x86: MMIO Stale Data vulnerabilities (XSA-404).
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB-081 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-081-2022.txt
In addition, you may wish to:
Get the qubes-secpack: https://www.qubes-os.org/security/pack/
View all past QSBs: https://www.qubes-os.org/security/qsb/
View the XSA Tracker: https://www.qubes-os.org/security/xsa/
---===[ Qubes Security Bulletin 081 ]===---
2022-06-17
x86: MMIO Stale Data vulnerabilities (XSA-404)
User action required
---------------------
Users with appropriate hardware (see the "affected hardware" section
below) must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0, in dom0:
- Xen packages, version 4.8.5-41
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.5-3
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Summary
--------
On 2022-06-14, the Xen Project published XSA-404, "x86: MMIO Stale
Data vulnerabilities" [3]:
| This issue is related to the SRBDS, TAA and MDS vulnerabilities.
| Please see:
|
| https://xenbits.xen.org/xsa/advisory-320.html (SRBDS)
| https://xenbits.xen.org/xsa/advisory-305.html (TAA)
| https://xenbits.xen.org/xsa/advisory-297.html (MDS)
|
| Please see Intel's whitepaper:
|
| https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/processor-mmio-stale-data-vulnerabilities.html
Impact
-------
An adversary who controls a VM with an assigned PCI device can infer
the memory content of other guests or Xen itself. This could allow the
adversary to read information that should be accessible only to Xen or
another VM and to use that information to launch further attacks. In
the default Qubes OS configuration, only sys-net and sys-usb can be
used to perform this attack.
Affected hardware
------------------
All Intel systems are affected. While mitigations are available, they
are available only for some Intel CPU models. Normally, it should be a
simple matter to look up a given CPU model number in a table to see
whether it is affected and whether it is eligible for any mitigations.
Indeed, Intel has published a table [4] that claims to serve this
purpose. Unfortunately, however, we have found several inaccuracies in
this table. Since we cannot rely on the table, we have had to devise an
alternative method using other published Intel technical documents that
appear to be more accurate. This has turned out to be quite complex.
Our best evidence indicates that mitigations are available for all and
only those CPUs that are both eligible for and updated with the Intel
microcode update released in May 2022. [5] Since going through all the
complicated technical steps of checking this manually would be
excessively cumbersome for most users, we have written a tool that does
it for you. Please note that this tool is entirely optional and is *not*
required for any security updates to take effect. Rather, its intended
purpose is to satisfy the curiosity of users who wish to know whether
their own CPUs are eligible for mitigations and who would struggle to
https://www.qubes-os.org/news/2022/06/17/qsb-081/
We have just published Qubes Security Bulletin (QSB) 081:
x86: MMIO Stale Data vulnerabilities (XSA-404).
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB-081 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-081-2022.txt
In addition, you may wish to:
Get the qubes-secpack: https://www.qubes-os.org/security/pack/
View all past QSBs: https://www.qubes-os.org/security/qsb/
View the XSA Tracker: https://www.qubes-os.org/security/xsa/
---===[ Qubes Security Bulletin 081 ]===---
2022-06-17
x86: MMIO Stale Data vulnerabilities (XSA-404)
User action required
---------------------
Users with appropriate hardware (see the "affected hardware" section
below) must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0, in dom0:
- Xen packages, version 4.8.5-41
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.5-3
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Summary
--------
On 2022-06-14, the Xen Project published XSA-404, "x86: MMIO Stale
Data vulnerabilities" [3]:
| This issue is related to the SRBDS, TAA and MDS vulnerabilities.
| Please see:
|
| https://xenbits.xen.org/xsa/advisory-320.html (SRBDS)
| https://xenbits.xen.org/xsa/advisory-305.html (TAA)
| https://xenbits.xen.org/xsa/advisory-297.html (MDS)
|
| Please see Intel's whitepaper:
|
| https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/processor-mmio-stale-data-vulnerabilities.html
Impact
-------
An adversary who controls a VM with an assigned PCI device can infer
the memory content of other guests or Xen itself. This could allow the
adversary to read information that should be accessible only to Xen or
another VM and to use that information to launch further attacks. In
the default Qubes OS configuration, only sys-net and sys-usb can be
used to perform this attack.
Affected hardware
------------------
All Intel systems are affected. While mitigations are available, they
are available only for some Intel CPU models. Normally, it should be a
simple matter to look up a given CPU model number in a table to see
whether it is affected and whether it is eligible for any mitigations.
Indeed, Intel has published a table [4] that claims to serve this
purpose. Unfortunately, however, we have found several inaccuracies in
this table. Since we cannot rely on the table, we have had to devise an
alternative method using other published Intel technical documents that
appear to be more accurate. This has turned out to be quite complex.
Our best evidence indicates that mitigations are available for all and
only those CPUs that are both eligible for and updated with the Intel
microcode update released in May 2022. [5] Since going through all the
complicated technical steps of checking this manually would be
excessively cumbersome for most users, we have written a tool that does
it for you. Please note that this tool is entirely optional and is *not*
required for any security updates to take effect. Rather, its intended
purpose is to satisfy the curiosity of users who wish to know whether
their own CPUs are eligible for mitigations and who would struggle to
make that determination manually. This tool is included in the
`qubes-core-dom0-linux-4.0.35` package for Qubes 4.0 and the
`qubes-core-dom0-linux-4.1.23` package for Qubes 4.1. These packages
will migrate from the security-testing repository to the current
(stable) repository over the next two weeks after being tested by the
community. [1] Once available, the packages are to be installed via the
Qubes Update tool or its command-line equivalents. [2]
After installing the required updates, you will be able to execute `sudo
cpu-microcode-info` in a dom0 terminal. This will output a table of
information about the logical CPUs (aka CPU "cores") in your system. The
"F-M-S/PI" column lists the "Family-Model-Stepping/Platform ID" codes
that Intel uses in its microcode documentation, [5] which is explained
in further detail in Intel's README. [6] (The manual process of checking
would involve extracting your CPU information, converting it to
hexadecimal, and looking it up in the appropriate table in this
document.) The "Loaded microcode version" column lists the microcode
versions currently loaded for each CPU. The "20220510 update available"
column lists whether the required May 2022 microcode update is
*available* for each CPU. The "20220510 update installed" column lists
whether the required May 2022 microcode update is *installed* in each
CPU.
In order for the updates associated with this bulletin to successfully
mitigate XSA-404, a value of "yes" is required in both of these last two
"20220510 update" columns. If the "available" column has a "yes" while
the "installed" column has a "no," then the May 2022 microcode update
must be installed first. If both columns have "no" values, then this CPU
remains vulnerable, and there is no known mitigation available. If your
system has such a CPU, then installing The Xen packages listed in the
"user action required" section above is *not* expected to mitigate the
problem described in this bulletin. Unfortunately, there is simply
nothing we can do for these CPUs in terms of patching unless we receive
a fix from Intel or receive new information about which CPUs are
affected. Nonetheless, we still recommend installing the updates anyway
(once available), since they will not make the problem any worse,
keeping up-to-date with all security updates is a general best practice,
and future updates will be based on the latest version.
However, hope is not entirely lost for users whose CPUs are not eligible
for software mitigations. Since the vulnerability discussed in this
bulletin does not affect VMs without PCI passthrough devices, users
still have the option of altering their habits to treat VMs like sys-usb
and sys-net as more trusted. While this can be especially challenging in
the case of sys-net, it at least affords users *some* latitude in
working around the problem by being mindful of when such VMs are
running, how trusted their templates are, and similar considerations.
Further plans regarding PCI passthrough
----------------------------------------
This is yet another issue affecting only VMs with access to PCI devices.
This pattern of vulnerabilities has prompted us to research more secure
ways of handling such VMs in future Qubes releases. Eventually, we plan
to treat them as more privileged VMs that require additional protection.
Specific protective measures will be discussed with the community as
part of our ongoing research and development efforts.
Credits
--------
See the original Xen Security Advisory.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://xenbits.xen.org/xsa/advisory-404.html
[4] https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
[5] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md#microcode-20220510
`qubes-core-dom0-linux-4.0.35` package for Qubes 4.0 and the
`qubes-core-dom0-linux-4.1.23` package for Qubes 4.1. These packages
will migrate from the security-testing repository to the current
(stable) repository over the next two weeks after being tested by the
community. [1] Once available, the packages are to be installed via the
Qubes Update tool or its command-line equivalents. [2]
After installing the required updates, you will be able to execute `sudo
cpu-microcode-info` in a dom0 terminal. This will output a table of
information about the logical CPUs (aka CPU "cores") in your system. The
"F-M-S/PI" column lists the "Family-Model-Stepping/Platform ID" codes
that Intel uses in its microcode documentation, [5] which is explained
in further detail in Intel's README. [6] (The manual process of checking
would involve extracting your CPU information, converting it to
hexadecimal, and looking it up in the appropriate table in this
document.) The "Loaded microcode version" column lists the microcode
versions currently loaded for each CPU. The "20220510 update available"
column lists whether the required May 2022 microcode update is
*available* for each CPU. The "20220510 update installed" column lists
whether the required May 2022 microcode update is *installed* in each
CPU.
In order for the updates associated with this bulletin to successfully
mitigate XSA-404, a value of "yes" is required in both of these last two
"20220510 update" columns. If the "available" column has a "yes" while
the "installed" column has a "no," then the May 2022 microcode update
must be installed first. If both columns have "no" values, then this CPU
remains vulnerable, and there is no known mitigation available. If your
system has such a CPU, then installing The Xen packages listed in the
"user action required" section above is *not* expected to mitigate the
problem described in this bulletin. Unfortunately, there is simply
nothing we can do for these CPUs in terms of patching unless we receive
a fix from Intel or receive new information about which CPUs are
affected. Nonetheless, we still recommend installing the updates anyway
(once available), since they will not make the problem any worse,
keeping up-to-date with all security updates is a general best practice,
and future updates will be based on the latest version.
However, hope is not entirely lost for users whose CPUs are not eligible
for software mitigations. Since the vulnerability discussed in this
bulletin does not affect VMs without PCI passthrough devices, users
still have the option of altering their habits to treat VMs like sys-usb
and sys-net as more trusted. While this can be especially challenging in
the case of sys-net, it at least affords users *some* latitude in
working around the problem by being mindful of when such VMs are
running, how trusted their templates are, and similar considerations.
Further plans regarding PCI passthrough
----------------------------------------
This is yet another issue affecting only VMs with access to PCI devices.
This pattern of vulnerabilities has prompted us to research more secure
ways of handling such VMs in future Qubes releases. Eventually, we plan
to treat them as more privileged VMs that require additional protection.
Specific protective measures will be discussed with the community as
part of our ongoing research and development efforts.
Credits
--------
See the original Xen Security Advisory.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://xenbits.xen.org/xsa/advisory-404.html
[4] https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
[5] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md#microcode-20220510
Qubes OS 4.1.1-rc1 has been released!
https://www.qubes-os.org/news/2022/06/27/qubes-4-1-1-rc1/
We’re pleased to announce the first release candidate for Qubes 4.1.1!
This release aims to consolidate all the security patches, bug fixes,
and upstream template OS upgrades that have occurred since the initial
Qubes 4.1.0 release in February. Our goal is to provide a secure and
convenient way for users to install (or reinstall) the latest stable
Qubes release with an up-to-date ISO.
Qubes 4.1.1-rc1 is available on the downloads (https://www.qubes-os.org/downloads/) page.
What is a release candidate?
A release candidate (RC) is a software build that has the potential to
become a stable release, unless significant bugs are discovered in
testing. Release candidates are intended for more advanced (or
adventurous!) users who are comfortable testing early versions of
software that are potentially buggier than stable releases. You can read
more about the Qubes OS release process in the version scheme (https://www.qubes-os.org/doc/version-scheme/)
documentation.
What is a patch release?
The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version
numbers are written as ... Hence, we refer to
releases that increment the third number as “patch releases.” A patch
release does not designate a separate, new major or minor release of
Qubes OS. Rather, it designates its respective major or minor release
(in this case, 4.1.0) inclusive of all updates up to a certain point.
Installing Qubes 4.1.0 and fully updating it results in essentially the
same system as installing Qubes 4.1.1. You can learn more about how
Qubes release versioning works in the version scheme (https://www.qubes-os.org/doc/version-scheme/) documentation.
What’s new in Qubes 4.1.1?
Qubes 4.1.1-rc1 includes numerous updates over the initial 4.1.0
release, in particular:
All 4.1.0 dom0 updates to date
Fedora 36 template (upgraded from Fedora 34)
Linux kernel 5.15 (upgraded from 5.10)
How to test Qubes 4.1.1-rc1
If you’re willing to test (https://www.qubes-os.org/doc/testing/) this release candidate, you can help to
improve the eventual stable release by reporting any bugs you
encounter (https://www.qubes-os.org/doc/issue-tracking/). We strongly encourage experience users to join the testing
team (https://forum.qubes-os.org/t/joining-the-testing-team/5190)!
Release candidate planning
If no significant bugs are discovered in 4.1.1-rc1, we expect to
announce the stable release of 4.1.1 in two to three weeks.
https://www.qubes-os.org/news/2022/06/27/qubes-4-1-1-rc1/
We’re pleased to announce the first release candidate for Qubes 4.1.1!
This release aims to consolidate all the security patches, bug fixes,
and upstream template OS upgrades that have occurred since the initial
Qubes 4.1.0 release in February. Our goal is to provide a secure and
convenient way for users to install (or reinstall) the latest stable
Qubes release with an up-to-date ISO.
Qubes 4.1.1-rc1 is available on the downloads (https://www.qubes-os.org/downloads/) page.
What is a release candidate?
A release candidate (RC) is a software build that has the potential to
become a stable release, unless significant bugs are discovered in
testing. Release candidates are intended for more advanced (or
adventurous!) users who are comfortable testing early versions of
software that are potentially buggier than stable releases. You can read
more about the Qubes OS release process in the version scheme (https://www.qubes-os.org/doc/version-scheme/)
documentation.
What is a patch release?
The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version
numbers are written as ... Hence, we refer to
releases that increment the third number as “patch releases.” A patch
release does not designate a separate, new major or minor release of
Qubes OS. Rather, it designates its respective major or minor release
(in this case, 4.1.0) inclusive of all updates up to a certain point.
Installing Qubes 4.1.0 and fully updating it results in essentially the
same system as installing Qubes 4.1.1. You can learn more about how
Qubes release versioning works in the version scheme (https://www.qubes-os.org/doc/version-scheme/) documentation.
What’s new in Qubes 4.1.1?
Qubes 4.1.1-rc1 includes numerous updates over the initial 4.1.0
release, in particular:
All 4.1.0 dom0 updates to date
Fedora 36 template (upgraded from Fedora 34)
Linux kernel 5.15 (upgraded from 5.10)
How to test Qubes 4.1.1-rc1
If you’re willing to test (https://www.qubes-os.org/doc/testing/) this release candidate, you can help to
improve the eventual stable release by reporting any bugs you
encounter (https://www.qubes-os.org/doc/issue-tracking/). We strongly encourage experience users to join the testing
team (https://forum.qubes-os.org/t/joining-the-testing-team/5190)!
Release candidate planning
If no significant bugs are discovered in 4.1.1-rc1, we expect to
announce the stable release of 4.1.1 in two to three weeks.
Qubes OS 4.0 reaches EOL on 2022-08-04
https://www.qubes-os.org/news/2022/07/04/qubes-os-4-0-eol-on-2022-08-04/
Qubes OS 4.0 is scheduled to reach end-of-life (EOL) on 2022-08-04 — one
month from the date of this announcement.
What about patch releases?
The Qubes OS Project uses the semantic versioning (https://semver.org/)
standard. Version numbers are written as ... When a
major or minor release reaches EOL, all of its patch releases also reach EOL.
For example, in this case, when we say that “Qubes 4.0” (without specifying a
number) is approaching EOL, we’re specifying a particular minor
release, inclusive of all patch releases within it. This means that Qubes
4.0.0, 4.0.1, 4.0.2, 4.0.3, and 4.0.4 will all reach EOL at the same time (on
2022-08-04), since they are all just patch releases of the same minor release.
How are EOL dates determined?
According to our support policy (https://www.qubes-os.org/doc/supported-releases/), stable Qubes OS
releases are supported for six months after each subsequent major or minor
release (https://www.qubes-os.org/doc/version-scheme/). This means that Qubes 4.0 reaches EOL six
months after Qubes 4.1 was released. Since Qubes 4.1.0 was released on
2022-02-04 (https://www.qubes-os.org/news/2022/02/04/qubes-4-1-0/), Qubes 4.0’s EOL date is six months
later, on 2022-08-04.
Fun fact: Qubes 4.0.0 was initially released on
2018-03-28 (https://www.qubes-os.org/news/2018/03/28/qubes-40/), which means that it will be four
years, four months, and one week old when it reaches EOL. That’s the longest
support period for a stable Qubes release in our project’s history!
What should I do?
First off, if you’re already using Qubes 4.1, then you don’t have to do
anything. This announcement doesn’t affect you.
However, if you’ve stood by the venerable Qubes 4.0 till now, then you’ll want
to make sure you upgrade to Qubes 4.1 by 2022-08-04. When you upgrade,
though, depends on a few factors. You have several options (in no particular
order):
Perform an in-place upgrade (https://www.qubes-os.org/doc/upgrade/4.1/#in-place-upgrade) any time
between now and 2022-08-04.
Perform a clean install now using the stable Qubes 4.1.0
ISO (https://www.qubes-os.org/downloads/#qubes-release-4-1-0), which was published on
2022-02-04 (https://www.qubes-os.org/news/2022/02/04/qubes-4-1-0/).
Perform a clean install now using the first release candidate for Qubes
4.1.1 (https://www.qubes-os.org/news/2022/06/27/qubes-4-1-1-rc1/).
Wait to see whether the stable Qubes 4.1.1 ISO is published within the next
month.
Allow me to explain what I mean by the last option: While we certainly hope
to be able to announce the stable 4.1.1 release within the next few weeks, we
cannot guarantee that outcome. After all, the entire point of having release
candidates is because sometimes major bugs are discovered in builds that were
thought to be nearly ready for release. While we don’t expect any, we can never
be certain that no such bug will be found.
So, for those looking for a clean installation option, the main advantage of
the existing 4.1.0 ISO is that it is already available right now, while
there’s a decent chance but no guarantee that the stable 4.1.1 ISO will be
ready in time. Meanwhile, the release candidate is intended for testers and
adventurous types who don’t mind a bit of risk. The release candidates are not
intended for cases in which system reliability is required for important work.
The main disadvantage of the existing 4.1.0 ISO is that it’s quite old by
now. It’s missing some security updates (which you should download immediately
after installing, if you choose to go that route) and comes with an old Fedora
template that has already reached EOL (which you should upgrade immediately
after installing or refrain from using in favor of other templates).
If you’re not in any particular hurry to upgrade (and, if you’ve been content
https://www.qubes-os.org/news/2022/07/04/qubes-os-4-0-eol-on-2022-08-04/
Qubes OS 4.0 is scheduled to reach end-of-life (EOL) on 2022-08-04 — one
month from the date of this announcement.
What about patch releases?
The Qubes OS Project uses the semantic versioning (https://semver.org/)
standard. Version numbers are written as ... When a
major or minor release reaches EOL, all of its patch releases also reach EOL.
For example, in this case, when we say that “Qubes 4.0” (without specifying a
number) is approaching EOL, we’re specifying a particular minor
release, inclusive of all patch releases within it. This means that Qubes
4.0.0, 4.0.1, 4.0.2, 4.0.3, and 4.0.4 will all reach EOL at the same time (on
2022-08-04), since they are all just patch releases of the same minor release.
How are EOL dates determined?
According to our support policy (https://www.qubes-os.org/doc/supported-releases/), stable Qubes OS
releases are supported for six months after each subsequent major or minor
release (https://www.qubes-os.org/doc/version-scheme/). This means that Qubes 4.0 reaches EOL six
months after Qubes 4.1 was released. Since Qubes 4.1.0 was released on
2022-02-04 (https://www.qubes-os.org/news/2022/02/04/qubes-4-1-0/), Qubes 4.0’s EOL date is six months
later, on 2022-08-04.
Fun fact: Qubes 4.0.0 was initially released on
2018-03-28 (https://www.qubes-os.org/news/2018/03/28/qubes-40/), which means that it will be four
years, four months, and one week old when it reaches EOL. That’s the longest
support period for a stable Qubes release in our project’s history!
What should I do?
First off, if you’re already using Qubes 4.1, then you don’t have to do
anything. This announcement doesn’t affect you.
However, if you’ve stood by the venerable Qubes 4.0 till now, then you’ll want
to make sure you upgrade to Qubes 4.1 by 2022-08-04. When you upgrade,
though, depends on a few factors. You have several options (in no particular
order):
Perform an in-place upgrade (https://www.qubes-os.org/doc/upgrade/4.1/#in-place-upgrade) any time
between now and 2022-08-04.
Perform a clean install now using the stable Qubes 4.1.0
ISO (https://www.qubes-os.org/downloads/#qubes-release-4-1-0), which was published on
2022-02-04 (https://www.qubes-os.org/news/2022/02/04/qubes-4-1-0/).
Perform a clean install now using the first release candidate for Qubes
4.1.1 (https://www.qubes-os.org/news/2022/06/27/qubes-4-1-1-rc1/).
Wait to see whether the stable Qubes 4.1.1 ISO is published within the next
month.
Allow me to explain what I mean by the last option: While we certainly hope
to be able to announce the stable 4.1.1 release within the next few weeks, we
cannot guarantee that outcome. After all, the entire point of having release
candidates is because sometimes major bugs are discovered in builds that were
thought to be nearly ready for release. While we don’t expect any, we can never
be certain that no such bug will be found.
So, for those looking for a clean installation option, the main advantage of
the existing 4.1.0 ISO is that it is already available right now, while
there’s a decent chance but no guarantee that the stable 4.1.1 ISO will be
ready in time. Meanwhile, the release candidate is intended for testers and
adventurous types who don’t mind a bit of risk. The release candidates are not
intended for cases in which system reliability is required for important work.
The main disadvantage of the existing 4.1.0 ISO is that it’s quite old by
now. It’s missing some security updates (which you should download immediately
after installing, if you choose to go that route) and comes with an old Fedora
template that has already reached EOL (which you should upgrade immediately
after installing or refrain from using in favor of other templates).
If you’re not in any particular hurry to upgrade (and, if you’ve been content
to stick with 4.0 until now, then you’re probably not), one strategy is simply
to wait until closer to the EOL date, and see whether the stable 4.1.1 ISO
arrives in time. If it does, great! You can preform a clean install using that.
If it doesn’t, then you haven’t lost anything. You still have the same choices
you have right now. Just make sure you to leave yourself enough time to upgrade
one way or another!
to wait until closer to the EOL date, and see whether the stable 4.1.1 ISO
arrives in time. If it does, great! You can preform a clean install using that.
If it doesn’t, then you haven’t lost anything. You still have the same choices
you have right now. Just make sure you to leave yourself enough time to upgrade
one way or another!
XSAs released on 2022-07-05
https://www.qubes-os.org/news/2022/07/05/xsas-released-on-2022-07-05/
The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is affected.
Therefore, user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
XSA-403
XSA-405
Please see QSB-082 for the actions users must take in order to
protect themselves, as well as further details about these XSAs:
https://www.qubes-os.org/news/2022/07/05/qsb-082/
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-406 (ARM architecture only)
Related links
Xen XSA list: https://xenbits.xen.org/xsa/
Qubes XSA tracker: https://www.qubes-os.org/security/xsa/
Qubes security pack (qubes-secpack): https://www.qubes-os.org/security/pack/
Qubes security bulletins (QSBs): https://www.qubes-os.org/security/qsb/
https://www.qubes-os.org/news/2022/07/05/xsas-released-on-2022-07-05/
The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is affected.
Therefore, user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
XSA-403
XSA-405
Please see QSB-082 for the actions users must take in order to
protect themselves, as well as further details about these XSAs:
https://www.qubes-os.org/news/2022/07/05/qsb-082/
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-406 (ARM architecture only)
Related links
Xen XSA list: https://xenbits.xen.org/xsa/
Qubes XSA tracker: https://www.qubes-os.org/security/xsa/
Qubes security pack (qubes-secpack): https://www.qubes-os.org/security/pack/
Qubes security bulletins (QSBs): https://www.qubes-os.org/security/qsb/