XSAs released on 2023-08-08
https://www.qubes-os.org/news/2023/08/09/xsas-released-on-2023-08-08/
The Xen Project (https://xenproject.org/) has released one or more Xen security advisories (XSAs) (https://xenbits.xen.org/xsa/).
The security of Qubes OS is affected.
Therefore, user action is required.
XSAs that DO affect the security of Qubes OS
The following XSAs do affect the security of Qubes OS:
XSA-432 (https://xenbits.xen.org/xsa/advisory-432.html): See QSB-092 (https://www.qubes-os.org/news/2023/08/08/qsb-092/) for details.
XSA-434 (https://xenbits.xen.org/xsa/advisory-434.html): See QSB-093 (https://www.qubes-os.org/news/2023/08/09/qsb-093/) for details.
XSA-435 (https://xenbits.xen.org/xsa/advisory-435.html): See QSB-093 (https://www.qubes-os.org/news/2023/08/09/qsb-093/) for details.
XSAs that DO NOT affect the security of Qubes OS
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
(none)
About this announcement
Qubes OS uses the Xen hypervisor (https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as part of its architecture (https://www.qubes-os.org/doc/architecture/). When the Xen Project (https://xenproject.org/) publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA) (https://xenproject.org/developers/security-policy/). Vulnerabilities in the Xen hypervisor sometimes have security implications for Qubes OS. When they do, we issue a notice called a Qubes security bulletin (QSB) (https://www.qubes-os.org/security/qsb/). (QSBs are also issued for non-Xen vulnerabilities.) However, QSBs can provide only positive confirmation that certain XSAs do affect the security of Qubes OS. QSBs cannot provide negative confirmation that other XSAs do not affect the security of Qubes OS. Therefore, we also maintain an XSA tracker (https://www.qubes-os.org/security/xsa/), which is a comprehensive list of all XSAs publicly disclosed to date, including whether each one affects the security of Qubes OS. When new XSAs are published, we add them to the XSA tracker and publish a notice like this one in order to inform Qubes users that a new batch of XSAs has been released and whether each one affects the security of Qubes OS.
https://www.qubes-os.org/news/2023/08/09/xsas-released-on-2023-08-08/
The Xen Project (https://xenproject.org/) has released one or more Xen security advisories (XSAs) (https://xenbits.xen.org/xsa/).
The security of Qubes OS is affected.
Therefore, user action is required.
XSAs that DO affect the security of Qubes OS
The following XSAs do affect the security of Qubes OS:
XSA-432 (https://xenbits.xen.org/xsa/advisory-432.html): See QSB-092 (https://www.qubes-os.org/news/2023/08/08/qsb-092/) for details.
XSA-434 (https://xenbits.xen.org/xsa/advisory-434.html): See QSB-093 (https://www.qubes-os.org/news/2023/08/09/qsb-093/) for details.
XSA-435 (https://xenbits.xen.org/xsa/advisory-435.html): See QSB-093 (https://www.qubes-os.org/news/2023/08/09/qsb-093/) for details.
XSAs that DO NOT affect the security of Qubes OS
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
(none)
About this announcement
Qubes OS uses the Xen hypervisor (https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as part of its architecture (https://www.qubes-os.org/doc/architecture/). When the Xen Project (https://xenproject.org/) publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA) (https://xenproject.org/developers/security-policy/). Vulnerabilities in the Xen hypervisor sometimes have security implications for Qubes OS. When they do, we issue a notice called a Qubes security bulletin (QSB) (https://www.qubes-os.org/security/qsb/). (QSBs are also issued for non-Xen vulnerabilities.) However, QSBs can provide only positive confirmation that certain XSAs do affect the security of Qubes OS. QSBs cannot provide negative confirmation that other XSAs do not affect the security of Qubes OS. Therefore, we also maintain an XSA tracker (https://www.qubes-os.org/security/xsa/), which is a comprehensive list of all XSAs publicly disclosed to date, including whether each one affects the security of Qubes OS. When new XSAs are published, we add them to the XSA tracker and publish a notice like this one in order to inform Qubes users that a new batch of XSAs has been released and whether each one affects the security of Qubes OS.
QSB-093: Transient execution vulnerabilities in AMD and Intel CPUs
https://www.qubes-os.org/news/2023/08/09/qsb-093/
We have published Qubes Security Bulletin 093: Transient execution vulnerabilities in AMD and Intel CPUs (https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-093-2023.txt). The text of this QSB and its accompanying cryptographic signatures are reproduced below. For an explanation of this announcement and instructions for authenticating this QSB, please see the end of this announcement.
Qubes Security Bulletin 093
---===[ Qubes Security Bulletin 093 ]===---
2023-08-09
Transient execution vulnerabilities in AMD and Intel CPUs
(CVE-2023-20569/XSA-434, CVE-2022-40982/XSA-435)
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.6-1
- microcode_ctl, version 2.1-55
For Qubes 4.2, in dom0:
- Xen packages, version 4.17.2-1
- microcode_ctl, version 2.1-55
Note on AMD Zen 1 and Zen 2 CPUs: The packages we previously released
for QSB-086 [1] already contain mitigations that are sufficient to
protect these CPUs from CVE-2023-20569/XSA-434. Consequently,
fully-updated [2] Qubes OS installations running on systems with these
CPUs are not affected by the vulnerabilities discussed in this bulletin.
Note on AMD Zen 3 and Zen 4 CPUs: AMD has stated that they plan to
distribute microcode updates for these CPUs to original equipment
manufacturers (OEMs), original design manufacturers (ODMs), and
motherboard manufacturers (MB). [3] These microcode updates are shipped
only as part of system firmware; loading them from the operating system
is not supported. Therefore, until the relevant OEM, ODM, or MB provides
a suitable BIOS or (U)EFI update for a system, the package updates
listed above will not be sufficient to address CVE-2023-20569/XSA-434 on
that system.
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. [4] 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 Xen Project published the following security advisories on
2023-08-08:
XSA-434 [5] "x86/AMD: Speculative Return Stack Overflow"
(CVE-2023-20569):
| Researchers from ETH Zurich have extended their prior research
| (XSA-422, Branch Type Confusion, a.k.a Retbleed) and have discovered
| INCEPTION, also know as RAS (Return Address Stack) Poisoning, and
| Speculative Return Stack Overflow.
|
| The RAS is updated when a CALL instruction is predicted, rather than
| at a later point in the pipeline. However, the RAS is still
| fundamentally a circular stack.
|
| It is possible to poison the branch type and target predictions such
| that, at a point of the attackers choosing, the branch predictor
| predicts enough CALLs back-to-back to wrap around the entire RAS and
| overwrite a correct return prediction with one of the attackers
| choosing.
|
| This allows the attacker to control RET speculation in a victim
| context, and leak arbitrary data as a result.
|
| For more details, see:
| https://comsec.ethz.ch/inception
| https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-7005
XSA-435 [6] "x86/Intel: Gather Data Sampling" (CVE-2022-40982):
| A researcher has discovered Gather Data Sampling, a transient
| execution side-channel whereby the AVX GATHER instructions can forward
| the content of stale vector registers to dependent instructions.
|
https://www.qubes-os.org/news/2023/08/09/qsb-093/
We have published Qubes Security Bulletin 093: Transient execution vulnerabilities in AMD and Intel CPUs (https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-093-2023.txt). The text of this QSB and its accompanying cryptographic signatures are reproduced below. For an explanation of this announcement and instructions for authenticating this QSB, please see the end of this announcement.
Qubes Security Bulletin 093
---===[ Qubes Security Bulletin 093 ]===---
2023-08-09
Transient execution vulnerabilities in AMD and Intel CPUs
(CVE-2023-20569/XSA-434, CVE-2022-40982/XSA-435)
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.6-1
- microcode_ctl, version 2.1-55
For Qubes 4.2, in dom0:
- Xen packages, version 4.17.2-1
- microcode_ctl, version 2.1-55
Note on AMD Zen 1 and Zen 2 CPUs: The packages we previously released
for QSB-086 [1] already contain mitigations that are sufficient to
protect these CPUs from CVE-2023-20569/XSA-434. Consequently,
fully-updated [2] Qubes OS installations running on systems with these
CPUs are not affected by the vulnerabilities discussed in this bulletin.
Note on AMD Zen 3 and Zen 4 CPUs: AMD has stated that they plan to
distribute microcode updates for these CPUs to original equipment
manufacturers (OEMs), original design manufacturers (ODMs), and
motherboard manufacturers (MB). [3] These microcode updates are shipped
only as part of system firmware; loading them from the operating system
is not supported. Therefore, until the relevant OEM, ODM, or MB provides
a suitable BIOS or (U)EFI update for a system, the package updates
listed above will not be sufficient to address CVE-2023-20569/XSA-434 on
that system.
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. [4] 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 Xen Project published the following security advisories on
2023-08-08:
XSA-434 [5] "x86/AMD: Speculative Return Stack Overflow"
(CVE-2023-20569):
| Researchers from ETH Zurich have extended their prior research
| (XSA-422, Branch Type Confusion, a.k.a Retbleed) and have discovered
| INCEPTION, also know as RAS (Return Address Stack) Poisoning, and
| Speculative Return Stack Overflow.
|
| The RAS is updated when a CALL instruction is predicted, rather than
| at a later point in the pipeline. However, the RAS is still
| fundamentally a circular stack.
|
| It is possible to poison the branch type and target predictions such
| that, at a point of the attackers choosing, the branch predictor
| predicts enough CALLs back-to-back to wrap around the entire RAS and
| overwrite a correct return prediction with one of the attackers
| choosing.
|
| This allows the attacker to control RET speculation in a victim
| context, and leak arbitrary data as a result.
|
| For more details, see:
| https://comsec.ethz.ch/inception
| https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-7005
XSA-435 [6] "x86/Intel: Gather Data Sampling" (CVE-2022-40982):
| A researcher has discovered Gather Data Sampling, a transient
| execution side-channel whereby the AVX GATHER instructions can forward
| the content of stale vector registers to dependent instructions.
|
|
| For more details, see:
| https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/gather-data-sampling.html
Impact
-------
An attacker who compromises one qube can attempt to exploit one of these
vulnerabilities (the one corresponding to the system's CPU) in order to
infer the contents of data belonging to other qubes. In systems with AMD
CPUs, successfully exploiting CVE-2023-20569/XSA-434 would allow an
attacker to infer the contents of arbitrary host memory. In systems with
Intel CPUs, successfully exploiting CVE-2022-40982/XSA-435 would allow
an attacker to infer data from different CPU contexts on the same core.
Credits
--------
See the original Xen Security Advisories.
References
-----------
[1] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-086-2022.txt
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7005.html
[4] https://www.qubes-os.org/doc/testing/
[5] https://xenbits.xen.org/xsa/advisory-434.html
[6] https://xenbits.xen.org/xsa/advisory-435.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Source: https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-093-2023.txt
Marek Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki)’s PGP signature
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEELRdx/k12ftx2sIn61lWk8hgw4GoFAmTTgM0ACgkQ1lWk8hgw
4GrX6BAAjMRMjHNLGc9BwVQASyLYJCatF/JFqIwvw/BvZZ1RV49zUg/sVUz1rlBX
ttjWi1htnPKja+O3LYAMAe68Lxtiaz4a8asrVVq3sEqp+3KcGH2QRTdik8WJTxwf
iGtE8Tr0WNk7OEv8mj+NmcgWNYaYKL3aH1KHf0iDk888xLTnENgYGiSrZ7ODzn3Q
RNnK1O1gP/h3zQzGsUR0OPOBQsu5i9eOq3/a5XafaKfsUPIssF6/u8ES/buDWu22
4CG3dNEq3YZGfAS2CWdq5uxD5D+WRQSJ1q0Nvf89EOFhx+2bgip3BunbECfoA3y6
aB1+/gqzuvHEVsU4gssXQHDKKq5KZ/DZU6cr9Yg6c32EEH+eO0HgCfJE0/dM2UkF
KVp/4YWW9l4vef8O7WwRfx7OugS9nCjVv61SkCGfys5Vsf4naEIJYXQ1A+r7w0R4
9cX1s8h7Eh6lbooabD+lRkXQrtyXD9TuKtLemo0cBvr9FVuzehrGzEhaUKWqlg5U
0VPchpKjeV5WpEuy6mCqIxNbYq5xGUZke25X1sYy7r6E1AJGRbdgBRt1ik5lVZdL
sW/6xxg58cEgf5cKG/q1H1zZnPKxY4C8fhB8QR16rBwJKoFNvoIy2e8X+hX9Fy7L
0Ear78Gk8WCKIhsJxkTHqsqIbaQY2WBWKONVvOtFBXy//4Acrio=
=Tbh7
-----END PGP SIGNATURE-----
Source: https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-093-2023.txt.sig.marmarek
Simon Gaiser (aka HW42) (https://www.qubes-os.org/team/#simon-gaiser-aka-hw42)’s PGP signature
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6hjn8EDEHdrv6aoPSsGN4REuFJAFAmTTgf8ACgkQSsGN4REu
FJAnfQ//a8MPYFLtDZXNchDaKfLr7bSJzLBgSCps2gii9bVJT7Zu1CYGswLJaAmW
iN+DD8T6E4UjN476hRzt0nvztzWW6j6EHzD7rwi8doKE/fSM3PLoaulHKIWRWLs3
EFJzrxnvgCw7NIz2P/POyHmYH6jwLlW+5qbPsmc0GLl0OV1kxUaJGi1YcgzKuoU5
tCXpol3KHkc3/XC5ehMrleY9xMNdotRGnRRN/20NJT9cgZIQiHR3cDnMyt5aZM9E
t8KirkLR/qh1f58f+5zSGl2Tf54GsbPakiooyT2O3aWw+eE6Gx8W+NGOv3b69G8p
ar0TtQxRvMcJPBmeQn02yvSK+ftTln2UU0cb6+kCk/GsKYJ2NxxKYu2JYV4aHda/
lwaDkCFTyBJcu4rVhjTRlo99sQ2PUa0rz9tYZSZhbNVkmJe31CAa0hAIlL2fKCls
fqDQVp7LHd4YqUaF4NNba1iPsAyuLDz/Y7HqkW677Jr4CEe0wLbyG9+0zE+Nbmsy
3hB6OVYweuZEjAyVjjVrESAxJsyO7sH4o0oaA9y0t0sqB5z7z3105t/xSJlGYe7L
qascfButzrE8lICbiUTSAt/jICVvu2Gjgom8wwsKotffUinq1KJdefybZu+PmaS6
Ljjj3mPRbT9ktLyQPl1Zi//Ur5N0GI6d8gzKvWLDR2pOMwlBq2M=
=zUnR
-----END PGP SIGNATURE-----
Source: https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-093-2023.txt.sig.simon
What is the purpose of this announcement?
The purpose of this announcement is to inform the Qubes community that a new Qubes security bulletin (QSB) has been published.
What is a Qubes security bulletin (QSB)?
A Qubes security bulletin (QSB) is a security announcement issued by the Qubes security team (https://www.qubes-os.org/security/#qubes-security-team). A QSB typically provides a summary and impact analysis of one or more recently-discovered software vulnerabilities, including details about patching to address them. A list of all QSBs is available here (https://www.qubes-os.org/security/qsb/).
Why should I care about QSBs?
| For more details, see:
| https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/gather-data-sampling.html
Impact
-------
An attacker who compromises one qube can attempt to exploit one of these
vulnerabilities (the one corresponding to the system's CPU) in order to
infer the contents of data belonging to other qubes. In systems with AMD
CPUs, successfully exploiting CVE-2023-20569/XSA-434 would allow an
attacker to infer the contents of arbitrary host memory. In systems with
Intel CPUs, successfully exploiting CVE-2022-40982/XSA-435 would allow
an attacker to infer data from different CPU contexts on the same core.
Credits
--------
See the original Xen Security Advisories.
References
-----------
[1] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-086-2022.txt
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7005.html
[4] https://www.qubes-os.org/doc/testing/
[5] https://xenbits.xen.org/xsa/advisory-434.html
[6] https://xenbits.xen.org/xsa/advisory-435.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Source: https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-093-2023.txt
Marek Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki)’s PGP signature
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEELRdx/k12ftx2sIn61lWk8hgw4GoFAmTTgM0ACgkQ1lWk8hgw
4GrX6BAAjMRMjHNLGc9BwVQASyLYJCatF/JFqIwvw/BvZZ1RV49zUg/sVUz1rlBX
ttjWi1htnPKja+O3LYAMAe68Lxtiaz4a8asrVVq3sEqp+3KcGH2QRTdik8WJTxwf
iGtE8Tr0WNk7OEv8mj+NmcgWNYaYKL3aH1KHf0iDk888xLTnENgYGiSrZ7ODzn3Q
RNnK1O1gP/h3zQzGsUR0OPOBQsu5i9eOq3/a5XafaKfsUPIssF6/u8ES/buDWu22
4CG3dNEq3YZGfAS2CWdq5uxD5D+WRQSJ1q0Nvf89EOFhx+2bgip3BunbECfoA3y6
aB1+/gqzuvHEVsU4gssXQHDKKq5KZ/DZU6cr9Yg6c32EEH+eO0HgCfJE0/dM2UkF
KVp/4YWW9l4vef8O7WwRfx7OugS9nCjVv61SkCGfys5Vsf4naEIJYXQ1A+r7w0R4
9cX1s8h7Eh6lbooabD+lRkXQrtyXD9TuKtLemo0cBvr9FVuzehrGzEhaUKWqlg5U
0VPchpKjeV5WpEuy6mCqIxNbYq5xGUZke25X1sYy7r6E1AJGRbdgBRt1ik5lVZdL
sW/6xxg58cEgf5cKG/q1H1zZnPKxY4C8fhB8QR16rBwJKoFNvoIy2e8X+hX9Fy7L
0Ear78Gk8WCKIhsJxkTHqsqIbaQY2WBWKONVvOtFBXy//4Acrio=
=Tbh7
-----END PGP SIGNATURE-----
Source: https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-093-2023.txt.sig.marmarek
Simon Gaiser (aka HW42) (https://www.qubes-os.org/team/#simon-gaiser-aka-hw42)’s PGP signature
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6hjn8EDEHdrv6aoPSsGN4REuFJAFAmTTgf8ACgkQSsGN4REu
FJAnfQ//a8MPYFLtDZXNchDaKfLr7bSJzLBgSCps2gii9bVJT7Zu1CYGswLJaAmW
iN+DD8T6E4UjN476hRzt0nvztzWW6j6EHzD7rwi8doKE/fSM3PLoaulHKIWRWLs3
EFJzrxnvgCw7NIz2P/POyHmYH6jwLlW+5qbPsmc0GLl0OV1kxUaJGi1YcgzKuoU5
tCXpol3KHkc3/XC5ehMrleY9xMNdotRGnRRN/20NJT9cgZIQiHR3cDnMyt5aZM9E
t8KirkLR/qh1f58f+5zSGl2Tf54GsbPakiooyT2O3aWw+eE6Gx8W+NGOv3b69G8p
ar0TtQxRvMcJPBmeQn02yvSK+ftTln2UU0cb6+kCk/GsKYJ2NxxKYu2JYV4aHda/
lwaDkCFTyBJcu4rVhjTRlo99sQ2PUa0rz9tYZSZhbNVkmJe31CAa0hAIlL2fKCls
fqDQVp7LHd4YqUaF4NNba1iPsAyuLDz/Y7HqkW677Jr4CEe0wLbyG9+0zE+Nbmsy
3hB6OVYweuZEjAyVjjVrESAxJsyO7sH4o0oaA9y0t0sqB5z7z3105t/xSJlGYe7L
qascfButzrE8lICbiUTSAt/jICVvu2Gjgom8wwsKotffUinq1KJdefybZu+PmaS6
Ljjj3mPRbT9ktLyQPl1Zi//Ur5N0GI6d8gzKvWLDR2pOMwlBq2M=
=zUnR
-----END PGP SIGNATURE-----
Source: https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-093-2023.txt.sig.simon
What is the purpose of this announcement?
The purpose of this announcement is to inform the Qubes community that a new Qubes security bulletin (QSB) has been published.
What is a Qubes security bulletin (QSB)?
A Qubes security bulletin (QSB) is a security announcement issued by the Qubes security team (https://www.qubes-os.org/security/#qubes-security-team). A QSB typically provides a summary and impact analysis of one or more recently-discovered software vulnerabilities, including details about patching to address them. A list of all QSBs is available here (https://www.qubes-os.org/security/qsb/).
Why should I care about QSBs?
QSBs tell you what actions you must take in order to protect yourself from recently-discovered security vulnerabilities. In most cases, security vulnerabilities are addressed by updating normally (https://www.qubes-os.org/doc/how-to-update/). However, in some cases, special user action is required. In all cases, the required actions are detailed in QSBs.
What are the PGP signatures that accompany QSBs?
A PGP (https://en.wikipedia.org/wiki/Pretty_Good_Privacy) signature is a cryptographic digital signature (https://en.wikipedia.org/wiki/Digital_signature) made in accordance with the OpenPGP (https://en.wikipedia.org/wiki/Pretty_Good_Privacy#OpenPGP) standard. PGP signatures can be cryptographically verified with programs like GNU Privacy Guard (GPG) (https://gnupg.org/). The Qubes security team cryptographically signs all QSBs so that Qubes users have a reliable way to check whether QSBs are genuine. The only way to be certain that a QSB is authentic is by verifying its PGP signatures.
Why should I care whether a QSB is authentic?
A forged QSB could deceive you into taking actions that adversely affect the security of your Qubes OS system, such as installing malware or making configuration changes that render your system vulnerable to attack. Falsified QSBs could sow fear, uncertainty, and doubt about the security of Qubes OS or the status of the Qubes OS Project.
How do I verify the PGP signatures on a QSB?
The following command-line instructions assume a Linux system with git and gpg installed. (See here (https://www.qubes-os.org/security/verifying-signatures/#openpgp-software) for Windows and Mac options.)
Obtain the Qubes Master Signing Key (QMSK), e.g.:
$ gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-master-signing-key.asc
gpg: directory '/home/user/.gnupg' created
gpg: keybox '/home/user/.gnupg/pubring.kbx' created
gpg: requesting key from 'https://keys.qubes-os.org/keys/qubes-master-signing-key.asc'
gpg: /home/user/.gnupg/trustdb.gpg: trustdb created
gpg: key DDFA1A3E36879494: public key "Qubes Master Signing Key" imported
gpg: Total number processed: 1
gpg: imported: 1
(See here (https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-the-qubes-master-signing-key) for more ways to obtain the QMSK.)
View the fingerprint of the PGP key you just imported. (Note: gpg> indicates a prompt inside of the GnuPG program. Type what appears after it when prompted.)
$ gpg --edit-key 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494
gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
pub rsa4096/DDFA1A3E36879494
created: 2010-04-01 expires: never usage: SC
trust: unknown validity: unknown
[ unknown] (1). Qubes Master Signing Key
gpg> fpr
pub rsa4096/DDFA1A3E36879494 2010-04-01 Qubes Master Signing Key
Primary key fingerprint: 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
Important: At this point, you still don’t know whether the key you just imported is the genuine QMSK or a forgery. In order for this entire procedure to provide meaningful security benefits, you must authenticate the QMSK out-of-band. Do not skip this step! The standard method is to obtain the QMSK fingerprint from multiple independent sources in several different ways and check to see whether they match the key you just imported. See here (https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-the-qubes-master-signing-key) for more details and ideas for how to do that.
Tip: Record the genuine QMSK fingerprint in a safe place (or several) so that you don’t have to repeat this step in the future.
Once you are satisfied that you have the genuine QMSK, set its trust level to 5 (“ultimate”), then quit GnuPG with q.
gpg> trust
What are the PGP signatures that accompany QSBs?
A PGP (https://en.wikipedia.org/wiki/Pretty_Good_Privacy) signature is a cryptographic digital signature (https://en.wikipedia.org/wiki/Digital_signature) made in accordance with the OpenPGP (https://en.wikipedia.org/wiki/Pretty_Good_Privacy#OpenPGP) standard. PGP signatures can be cryptographically verified with programs like GNU Privacy Guard (GPG) (https://gnupg.org/). The Qubes security team cryptographically signs all QSBs so that Qubes users have a reliable way to check whether QSBs are genuine. The only way to be certain that a QSB is authentic is by verifying its PGP signatures.
Why should I care whether a QSB is authentic?
A forged QSB could deceive you into taking actions that adversely affect the security of your Qubes OS system, such as installing malware or making configuration changes that render your system vulnerable to attack. Falsified QSBs could sow fear, uncertainty, and doubt about the security of Qubes OS or the status of the Qubes OS Project.
How do I verify the PGP signatures on a QSB?
The following command-line instructions assume a Linux system with git and gpg installed. (See here (https://www.qubes-os.org/security/verifying-signatures/#openpgp-software) for Windows and Mac options.)
Obtain the Qubes Master Signing Key (QMSK), e.g.:
$ gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-master-signing-key.asc
gpg: directory '/home/user/.gnupg' created
gpg: keybox '/home/user/.gnupg/pubring.kbx' created
gpg: requesting key from 'https://keys.qubes-os.org/keys/qubes-master-signing-key.asc'
gpg: /home/user/.gnupg/trustdb.gpg: trustdb created
gpg: key DDFA1A3E36879494: public key "Qubes Master Signing Key" imported
gpg: Total number processed: 1
gpg: imported: 1
(See here (https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-the-qubes-master-signing-key) for more ways to obtain the QMSK.)
View the fingerprint of the PGP key you just imported. (Note: gpg> indicates a prompt inside of the GnuPG program. Type what appears after it when prompted.)
$ gpg --edit-key 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494
gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
pub rsa4096/DDFA1A3E36879494
created: 2010-04-01 expires: never usage: SC
trust: unknown validity: unknown
[ unknown] (1). Qubes Master Signing Key
gpg> fpr
pub rsa4096/DDFA1A3E36879494 2010-04-01 Qubes Master Signing Key
Primary key fingerprint: 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
Important: At this point, you still don’t know whether the key you just imported is the genuine QMSK or a forgery. In order for this entire procedure to provide meaningful security benefits, you must authenticate the QMSK out-of-band. Do not skip this step! The standard method is to obtain the QMSK fingerprint from multiple independent sources in several different ways and check to see whether they match the key you just imported. See here (https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-the-qubes-master-signing-key) for more details and ideas for how to do that.
Tip: Record the genuine QMSK fingerprint in a safe place (or several) so that you don’t have to repeat this step in the future.
Once you are satisfied that you have the genuine QMSK, set its trust level to 5 (“ultimate”), then quit GnuPG with q.
gpg> trust
pub rsa4096/DDFA1A3E36879494
created: 2010-04-01 expires: never usage: SC
trust: unknown validity: unknown
[ unknown] (1). Qubes Master Signing Key
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
pub rsa4096/DDFA1A3E36879494
created: 2010-04-01 expires: never usage: SC
trust: ultimate validity: unknown
[ unknown] (1). Qubes Master Signing Key
Please note that the shown key validity is not necessarily correct
unless you restart the program.
gpg> q
Use Git to clone the qubes-secpack repo.
$ git clone https://github.com/QubesOS/qubes-secpack.git
Cloning into 'qubes-secpack'...
remote: Enumerating objects: 4065, done.
remote: Counting objects: 100% (1474/1474), done.
remote: Compressing objects: 100% (742/742), done.
remote: Total 4065 (delta 743), reused 1413 (delta 731), pack-reused 2591
Receiving objects: 100% (4065/4065), 1.64 MiB | 2.53 MiB/s, done.
Resolving deltas: 100% (1910/1910), done.
Import the included PGP keys. (See our PGP key policies (https://www.qubes-os.org/security/pack/#pgp-key-policies) for important information about these keys.)
$ gpg --import qubes-secpack/keys/*/*
gpg: key 063938BA42CFA724: public key "Marek Marczykowski-Górecki (Qubes OS signing key)" imported
gpg: qubes-secpack/keys/core-devs/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key 8C05216CE09C093C: 1 signature not checked due to a missing key
gpg: key 8C05216CE09C093C: public key "HW42 (Qubes Signing Key)" imported
gpg: key DA0434BC706E1FCF: public key "Simon Gaiser (Qubes OS signing key)" imported
gpg: key 8CE137352A019A17: 2 signatures not checked due to missing keys
gpg: key 8CE137352A019A17: public key "Andrew David Wong (Qubes Documentation Signing Key)" imported
gpg: key AAA743B42FBC07A9: public key "Brennan Novak (Qubes Website & Documentation Signing)" imported
gpg: key B6A0BB95CA74A5C3: public key "Joanna Rutkowska (Qubes Documentation Signing Key)" imported
gpg: key F32894BE9684938A: public key "Marek Marczykowski-Górecki (Qubes Documentation Signing Key)" imported
gpg: key 6E7A27B909DAFB92: public key "Hakisho Nukama (Qubes Documentation Signing Key)" imported
gpg: key 485C7504F27D0A72: 1 signature not checked due to a missing key
gpg: key 485C7504F27D0A72: public key "Sven Semmler (Qubes Documentation Signing Key)" imported
gpg: key BB52274595B71262: public key "unman (Qubes Documentation Signing Key)" imported
gpg: key DC2F3678D272F2A8: 1 signature not checked due to a missing key
gpg: key DC2F3678D272F2A8: public key "Wojtek Porczyk (Qubes OS documentation signing key)" imported
gpg: key FD64F4F9E9720C4D: 1 signature not checked due to a missing key
gpg: key FD64F4F9E9720C4D: public key "Zrubi (Qubes Documentation Signing Key)" imported
gpg: key DDFA1A3E36879494: "Qubes Master Signing Key" not changed
gpg: key 1848792F9E2795E9: public key "Qubes OS Release 4 Signing Key" imported
gpg: qubes-secpack/keys/release-keys/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key D655A4F21830E06A: public key "Marek Marczykowski-Górecki (Qubes security pack)" imported
gpg: key ACC2602F3F48CB21: public key "Qubes OS Security Team" imported
gpg: qubes-secpack/keys/security-team/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key 4AC18DE1112E1490: public key "Simon Gaiser (Qubes Security Pack signing key)" imported
gpg: Total number processed: 17
gpg: imported: 16
gpg: unchanged: 1
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
created: 2010-04-01 expires: never usage: SC
trust: unknown validity: unknown
[ unknown] (1). Qubes Master Signing Key
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
pub rsa4096/DDFA1A3E36879494
created: 2010-04-01 expires: never usage: SC
trust: ultimate validity: unknown
[ unknown] (1). Qubes Master Signing Key
Please note that the shown key validity is not necessarily correct
unless you restart the program.
gpg> q
Use Git to clone the qubes-secpack repo.
$ git clone https://github.com/QubesOS/qubes-secpack.git
Cloning into 'qubes-secpack'...
remote: Enumerating objects: 4065, done.
remote: Counting objects: 100% (1474/1474), done.
remote: Compressing objects: 100% (742/742), done.
remote: Total 4065 (delta 743), reused 1413 (delta 731), pack-reused 2591
Receiving objects: 100% (4065/4065), 1.64 MiB | 2.53 MiB/s, done.
Resolving deltas: 100% (1910/1910), done.
Import the included PGP keys. (See our PGP key policies (https://www.qubes-os.org/security/pack/#pgp-key-policies) for important information about these keys.)
$ gpg --import qubes-secpack/keys/*/*
gpg: key 063938BA42CFA724: public key "Marek Marczykowski-Górecki (Qubes OS signing key)" imported
gpg: qubes-secpack/keys/core-devs/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key 8C05216CE09C093C: 1 signature not checked due to a missing key
gpg: key 8C05216CE09C093C: public key "HW42 (Qubes Signing Key)" imported
gpg: key DA0434BC706E1FCF: public key "Simon Gaiser (Qubes OS signing key)" imported
gpg: key 8CE137352A019A17: 2 signatures not checked due to missing keys
gpg: key 8CE137352A019A17: public key "Andrew David Wong (Qubes Documentation Signing Key)" imported
gpg: key AAA743B42FBC07A9: public key "Brennan Novak (Qubes Website & Documentation Signing)" imported
gpg: key B6A0BB95CA74A5C3: public key "Joanna Rutkowska (Qubes Documentation Signing Key)" imported
gpg: key F32894BE9684938A: public key "Marek Marczykowski-Górecki (Qubes Documentation Signing Key)" imported
gpg: key 6E7A27B909DAFB92: public key "Hakisho Nukama (Qubes Documentation Signing Key)" imported
gpg: key 485C7504F27D0A72: 1 signature not checked due to a missing key
gpg: key 485C7504F27D0A72: public key "Sven Semmler (Qubes Documentation Signing Key)" imported
gpg: key BB52274595B71262: public key "unman (Qubes Documentation Signing Key)" imported
gpg: key DC2F3678D272F2A8: 1 signature not checked due to a missing key
gpg: key DC2F3678D272F2A8: public key "Wojtek Porczyk (Qubes OS documentation signing key)" imported
gpg: key FD64F4F9E9720C4D: 1 signature not checked due to a missing key
gpg: key FD64F4F9E9720C4D: public key "Zrubi (Qubes Documentation Signing Key)" imported
gpg: key DDFA1A3E36879494: "Qubes Master Signing Key" not changed
gpg: key 1848792F9E2795E9: public key "Qubes OS Release 4 Signing Key" imported
gpg: qubes-secpack/keys/release-keys/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key D655A4F21830E06A: public key "Marek Marczykowski-Górecki (Qubes security pack)" imported
gpg: key ACC2602F3F48CB21: public key "Qubes OS Security Team" imported
gpg: qubes-secpack/keys/security-team/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key 4AC18DE1112E1490: public key "Simon Gaiser (Qubes Security Pack signing key)" imported
gpg: Total number processed: 17
gpg: imported: 16
gpg: unchanged: 1
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 1 signed: 6 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1 valid: 6 signed: 0 trust: 6-, 0q, 0n, 0m, 0f, 0u
Verify signed Git tags.
$ cd qubes-secpack/
$ git tag -v `git describe`
object 266e14a6fae57c9a91362c9ac784d3a891f4d351
type commit
tag marmarek_sec_266e14a6
tagger Marek Marczykowski-Górecki 1677757924 +0100
Tag for commit 266e14a6fae57c9a91362c9ac784d3a891f4d351
gpg: Signature made Thu 02 Mar 2023 03:52:04 AM PST
gpg: using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]
The exact output will differ, but the final line should always start with gpg: Good signature from... followed by an appropriate key. The [full] indicates full trust, which this key inherits in virtue of being validly signed by the QMSK.
Verify PGP signatures, e.g.:
$ cd QSBs/
$ gpg --verify qsb-087-2022.txt.sig.marmarek qsb-087-2022.txt
gpg: Signature made Wed 23 Nov 2022 04:05:51 AM PST
gpg: using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]
$ gpg --verify qsb-087-2022.txt.sig.simon qsb-087-2022.txt
gpg: Signature made Wed 23 Nov 2022 03:50:42 AM PST
gpg: using RSA key EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490
gpg: Good signature from "Simon Gaiser (Qubes Security Pack signing key)" [full]
$ cd ../canaries/
$ gpg --verify canary-034-2023.txt.sig.marmarek canary-034-2023.txt
gpg: Signature made Thu 02 Mar 2023 03:51:48 AM PST
gpg: using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]
$ gpg --verify canary-034-2023.txt.sig.simon canary-034-2023.txt
gpg: Signature made Thu 02 Mar 2023 01:47:52 AM PST
gpg: using RSA key EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490
gpg: Good signature from "Simon Gaiser (Qubes Security Pack signing key)" [full]
Again, the exact output will differ, but the final line of output from each gpg --verify command should always start with gpg: Good signature from... followed by an appropriate key.
For this announcement (QSB-093), the commands are:
$ gpg --verify qsb-093-2023.txt.sig.marmarek qsb-093-2023.txt
$ gpg --verify qsb-093-2023.txt.sig.simon qsb-093-2023.txt
You can also verify the signatures directly from this announcement in addition to or instead of verifying the files from the qubes-secpack. Simply copy and paste the QSB-093 text into a plain text file and do the same for both signature files. Then, perform the same authentication steps as listed above, substituting the filenames above with the names of the files you just created.
gpg: depth: 1 valid: 6 signed: 0 trust: 6-, 0q, 0n, 0m, 0f, 0u
Verify signed Git tags.
$ cd qubes-secpack/
$ git tag -v `git describe`
object 266e14a6fae57c9a91362c9ac784d3a891f4d351
type commit
tag marmarek_sec_266e14a6
tagger Marek Marczykowski-Górecki 1677757924 +0100
Tag for commit 266e14a6fae57c9a91362c9ac784d3a891f4d351
gpg: Signature made Thu 02 Mar 2023 03:52:04 AM PST
gpg: using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]
The exact output will differ, but the final line should always start with gpg: Good signature from... followed by an appropriate key. The [full] indicates full trust, which this key inherits in virtue of being validly signed by the QMSK.
Verify PGP signatures, e.g.:
$ cd QSBs/
$ gpg --verify qsb-087-2022.txt.sig.marmarek qsb-087-2022.txt
gpg: Signature made Wed 23 Nov 2022 04:05:51 AM PST
gpg: using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]
$ gpg --verify qsb-087-2022.txt.sig.simon qsb-087-2022.txt
gpg: Signature made Wed 23 Nov 2022 03:50:42 AM PST
gpg: using RSA key EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490
gpg: Good signature from "Simon Gaiser (Qubes Security Pack signing key)" [full]
$ cd ../canaries/
$ gpg --verify canary-034-2023.txt.sig.marmarek canary-034-2023.txt
gpg: Signature made Thu 02 Mar 2023 03:51:48 AM PST
gpg: using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]
$ gpg --verify canary-034-2023.txt.sig.simon canary-034-2023.txt
gpg: Signature made Thu 02 Mar 2023 01:47:52 AM PST
gpg: using RSA key EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490
gpg: Good signature from "Simon Gaiser (Qubes Security Pack signing key)" [full]
Again, the exact output will differ, but the final line of output from each gpg --verify command should always start with gpg: Good signature from... followed by an appropriate key.
For this announcement (QSB-093), the commands are:
$ gpg --verify qsb-093-2023.txt.sig.marmarek qsb-093-2023.txt
$ gpg --verify qsb-093-2023.txt.sig.simon qsb-093-2023.txt
You can also verify the signatures directly from this announcement in addition to or instead of verifying the files from the qubes-secpack. Simply copy and paste the QSB-093 text into a plain text file and do the same for both signature files. Then, perform the same authentication steps as listed above, substituting the filenames above with the names of the files you just created.
❤3
Qubes OS Summit 2023: October 6-8 in Berlin
https://www.qubes-os.org/news/2023/08/25/qubes-os-summit-2023/
In conjunction with 3mdeb (https://3mdeb.com/), the fifth edition of our Qubes OS Summit will be held live this year from October 6 to 8 in Berlin, Germany! For more information about this event, including the CFP (which is open until October 2), please see: https://cfp.3mdeb.com/qubes-os-summit-2023/cfp
https://www.qubes-os.org/news/2023/08/25/qubes-os-summit-2023/
In conjunction with 3mdeb (https://3mdeb.com/), the fifth edition of our Qubes OS Summit will be held live this year from October 6 to 8 in Berlin, Germany! For more information about this event, including the CFP (which is open until October 2), please see: https://cfp.3mdeb.com/qubes-os-summit-2023/cfp
❤1
Debian 12 templates available
https://www.qubes-os.org/news/2023/08/27/debian-12-templates-available/
The following new templates are now available:
Qube OS 4.1
Debian 12
Debian 12 minimal (https://www.qubes-os.org/doc/templates/minimal/)
Qubes OS 4.2-rc1
Debian 12
Debian 12 minimal (https://www.qubes-os.org/doc/templates/minimal/)
Debian 12 Xfce (https://www.qubes-os.org/doc/templates/xfce/)
There are two ways to upgrade your template to a new Debian release:
Recommended: Install a fresh template to replace the existing one. (https://www.qubes-os.org/doc/templates/debian/#installing) This option may be simpler for less experienced users. After you install the new template, redo all desired template modifications and switch everything that was set to the old template to the new template (https://www.qubes-os.org/doc/templates/#switching). You may want to write down the modifications you make to your templates so that you remember what to redo on each fresh install. In the old Debian template, see /var/log/dpkg.log and /var/log/apt/history.log for logs of package manager actions.
Advanced: Perform an in-place upgrade of an existing Debian template. (https://www.qubes-os.org/doc/templates/debian/in-place-upgrade/) This option will preserve any modifications you’ve made to the template, but it may be more complicated for less experienced users.
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 (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/2023/08/27/debian-12-templates-available/
The following new templates are now available:
Qube OS 4.1
Debian 12
Debian 12 minimal (https://www.qubes-os.org/doc/templates/minimal/)
Qubes OS 4.2-rc1
Debian 12
Debian 12 minimal (https://www.qubes-os.org/doc/templates/minimal/)
Debian 12 Xfce (https://www.qubes-os.org/doc/templates/xfce/)
There are two ways to upgrade your template to a new Debian release:
Recommended: Install a fresh template to replace the existing one. (https://www.qubes-os.org/doc/templates/debian/#installing) This option may be simpler for less experienced users. After you install the new template, redo all desired template modifications and switch everything that was set to the old template to the new template (https://www.qubes-os.org/doc/templates/#switching). You may want to write down the modifications you make to your templates so that you remember what to redo on each fresh install. In the old Debian template, see /var/log/dpkg.log and /var/log/apt/history.log for logs of package manager actions.
Advanced: Perform an in-place upgrade of an existing Debian template. (https://www.qubes-os.org/doc/templates/debian/in-place-upgrade/) This option will preserve any modifications you’ve made to the template, but it may be more complicated for less experienced users.
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 (see our note on dom0 and EOL (https://www.qubes-os.org/doc/supported-releases/#note-on-dom0-and-eol)).
👍3
Qubes OS 4.2.0-rc2 is available for testing
https://www.qubes-os.org/news/2023/08/28/qubes-os-4-2-0-rc2-available-for-testing/
We’re pleased to announce that the second release candidate (https://www.qubes-os.org/news/2023/08/28/qubes-os-4-2-0-rc2-available-for-testing/#what-is-a-release-candidate) (RC) for Qubes OS 4.2.0 is now available for testing (https://www.qubes-os.org/doc/testing/). Qubes 4.2.0-rc2 is available on the downloads (https://www.qubes-os.org/downloads/) page.
What’s new in Qubes 4.2.0-rc2?
Dom0 upgraded to Fedora 37
Xen updated to version 4.17
Default Debian template upgraded to Debian 12
Default Fedora and Debian templates use Xfce instead of GNOME
SELinux support in Fedora templates
Several GUI applications rewritten, including:
Applications Menu
Qubes Global Settings
Create New Qube
Qubes Update
Unified grub.cfg location for both UEFI and legacy boot
PipeWire support
fwupd integration for firmware updates
Optional automatic clipboard clearing
Official packages built using Qubes Builder v2
Split GPG and Split SSH management in Qubes Global Settings
Please see the Qubes OS 4.2.0 release notes (https://www.qubes-os.org/doc/releases/4.2/release-notes/) for details.
When is the stable release?
That depends on the number of bugs discovered in this release candidate and their severity. As explained in our release schedule (https://www.qubes-os.org/doc/version-scheme/#release-schedule) documentation, our usual process after issuing a new release candidate is to collect bug reports, triage the bugs, and fix them. This usually takes around five weeks, depending on the bugs discovered. If warranted, we then issue a new release candidate that includes the fixes and repeat the whole process again. We continue this iterative procedure until we’re left with a release candidate that’s good enough to be declared the stable release. No one can predict, at the outset, how many iterations will be required (and hence how many release candidates will be needed before a stable release), but we tend to get a clearer picture of this with each successive release candidate, which we’ll share in this section in future release candidate announcements. The feedback we receive on this release candidate will determine whether another one is required.
Testing Qubes 4.2.0-rc2
Thank you to everyone who tested 4.2.0-rc1! Due to your efforts, this new release candidate includes fixes for several bugs that were present in the first release candidate.
If you’re willing to test (https://www.qubes-os.org/doc/testing/) this new release candidate, you can help us improve the eventual stable release by reporting any bugs you encounter (https://www.qubes-os.org/doc/issue-tracking/). We encourage experienced users to join the testing team (https://forum.qubes-os.org/t/joining-the-testing-team/5190).
A full list of issues affecting Qubes 4.2.0 is available here (https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+label%3Aaffects-4.2). We strongly recommend updating Qubes OS (https://www.qubes-os.org/doc/how-to-update/) immediately after installation in order to apply all available bug fixes.
Upgrading to Qubes 4.2.0-rc2
In-place upgrades from Qubes 4.1 to Qubes 4.2 (https://www.qubes-os.org/doc/upgrade/4.2/) are now implemented and ready for testing! As always, we strongly recommend making a full backup (https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/) beforehand.
Current Qubes 4.2.0-rc1 systems should be updated normally (https://www.qubes-os.org/doc/how-to-update/), but please note that some templates have changed from the first release candidate. These changes are listed above (https://www.qubes-os.org/news/2023/08/28/qubes-os-4-2-0-rc2-available-for-testing/#whats-new-in-qubes-420-rc2).
Reminder: new signing key for Qubes OS 4.2
https://www.qubes-os.org/news/2023/08/28/qubes-os-4-2-0-rc2-available-for-testing/
We’re pleased to announce that the second release candidate (https://www.qubes-os.org/news/2023/08/28/qubes-os-4-2-0-rc2-available-for-testing/#what-is-a-release-candidate) (RC) for Qubes OS 4.2.0 is now available for testing (https://www.qubes-os.org/doc/testing/). Qubes 4.2.0-rc2 is available on the downloads (https://www.qubes-os.org/downloads/) page.
What’s new in Qubes 4.2.0-rc2?
Dom0 upgraded to Fedora 37
Xen updated to version 4.17
Default Debian template upgraded to Debian 12
Default Fedora and Debian templates use Xfce instead of GNOME
SELinux support in Fedora templates
Several GUI applications rewritten, including:
Applications Menu
Qubes Global Settings
Create New Qube
Qubes Update
Unified grub.cfg location for both UEFI and legacy boot
PipeWire support
fwupd integration for firmware updates
Optional automatic clipboard clearing
Official packages built using Qubes Builder v2
Split GPG and Split SSH management in Qubes Global Settings
Please see the Qubes OS 4.2.0 release notes (https://www.qubes-os.org/doc/releases/4.2/release-notes/) for details.
When is the stable release?
That depends on the number of bugs discovered in this release candidate and their severity. As explained in our release schedule (https://www.qubes-os.org/doc/version-scheme/#release-schedule) documentation, our usual process after issuing a new release candidate is to collect bug reports, triage the bugs, and fix them. This usually takes around five weeks, depending on the bugs discovered. If warranted, we then issue a new release candidate that includes the fixes and repeat the whole process again. We continue this iterative procedure until we’re left with a release candidate that’s good enough to be declared the stable release. No one can predict, at the outset, how many iterations will be required (and hence how many release candidates will be needed before a stable release), but we tend to get a clearer picture of this with each successive release candidate, which we’ll share in this section in future release candidate announcements. The feedback we receive on this release candidate will determine whether another one is required.
Testing Qubes 4.2.0-rc2
Thank you to everyone who tested 4.2.0-rc1! Due to your efforts, this new release candidate includes fixes for several bugs that were present in the first release candidate.
If you’re willing to test (https://www.qubes-os.org/doc/testing/) this new release candidate, you can help us improve the eventual stable release by reporting any bugs you encounter (https://www.qubes-os.org/doc/issue-tracking/). We encourage experienced users to join the testing team (https://forum.qubes-os.org/t/joining-the-testing-team/5190).
A full list of issues affecting Qubes 4.2.0 is available here (https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+label%3Aaffects-4.2). We strongly recommend updating Qubes OS (https://www.qubes-os.org/doc/how-to-update/) immediately after installation in order to apply all available bug fixes.
Upgrading to Qubes 4.2.0-rc2
In-place upgrades from Qubes 4.1 to Qubes 4.2 (https://www.qubes-os.org/doc/upgrade/4.2/) are now implemented and ready for testing! As always, we strongly recommend making a full backup (https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/) beforehand.
Current Qubes 4.2.0-rc1 systems should be updated normally (https://www.qubes-os.org/doc/how-to-update/), but please note that some templates have changed from the first release candidate. These changes are listed above (https://www.qubes-os.org/news/2023/08/28/qubes-os-4-2-0-rc2-available-for-testing/#whats-new-in-qubes-420-rc2).
Reminder: new signing key for Qubes OS 4.2
🔥5
As a reminder, we published the following special announcement in Qubes Canary 032 (https://www.qubes-os.org/news/2022/09/14/canary-032/) on 2022-09-14:
We plan to create a new Release Signing Key (RSK) for Qubes OS 4.2. Normally, we have only one RSK for each major release. However, for the 4.2 release, we will be using Qubes Builder version 2, which is a complete rewrite of the Qubes Builder. Out of an abundance of caution, we would like to isolate the build processes of the current stable 4.1 release and the upcoming 4.2 release from each other at the cryptographic level in order to minimize the risk of a vulnerability in one affecting the other. We are including this notice as a canary special announcement since introducing a new RSK for a minor release is an exception to our usual RSK management policy.
As always, we encourage you to authenticate (https://www.qubes-os.org/security/pack/#how-to-obtain-and-authenticate) this canary by verifying its PGP signatures (https://www.qubes-os.org/security/verifying-signatures/). Specific instructions are also included in the canary announcement (https://www.qubes-os.org/news/2022/09/14/canary-032/).
As with all Qubes signing keys, we also encourage you to authenticate (https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-release-signing-keys) the new Qubes OS Release 4.2 Signing Key, which is available in the Qubes Security Pack (qubes-secpack) (https://www.qubes-os.org/security/pack/) as well as on the downloads (https://www.qubes-os.org/downloads/) page under the Qubes OS 4.2.0-rc2 ISO.
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 Qubes OS supported releases (https://www.qubes-os.org/doc/supported-releases/) and the version scheme (https://www.qubes-os.org/doc/version-scheme/) in our documentation.
What is a minor release?
The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version numbers are written as ... Hence, releases that increment the second value are known as “minor releases.” Minor releases generally include new features, improvements, and bug fixes that are backward-compatible with earlier versions of the same major release. See our supported releases (https://www.qubes-os.org/doc/supported-releases/) for a comprehensive list of major and minor releases and our version scheme (https://www.qubes-os.org/doc/version-scheme/) documentation for more information about how Qubes OS releases are versioned.
We plan to create a new Release Signing Key (RSK) for Qubes OS 4.2. Normally, we have only one RSK for each major release. However, for the 4.2 release, we will be using Qubes Builder version 2, which is a complete rewrite of the Qubes Builder. Out of an abundance of caution, we would like to isolate the build processes of the current stable 4.1 release and the upcoming 4.2 release from each other at the cryptographic level in order to minimize the risk of a vulnerability in one affecting the other. We are including this notice as a canary special announcement since introducing a new RSK for a minor release is an exception to our usual RSK management policy.
As always, we encourage you to authenticate (https://www.qubes-os.org/security/pack/#how-to-obtain-and-authenticate) this canary by verifying its PGP signatures (https://www.qubes-os.org/security/verifying-signatures/). Specific instructions are also included in the canary announcement (https://www.qubes-os.org/news/2022/09/14/canary-032/).
As with all Qubes signing keys, we also encourage you to authenticate (https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-release-signing-keys) the new Qubes OS Release 4.2 Signing Key, which is available in the Qubes Security Pack (qubes-secpack) (https://www.qubes-os.org/security/pack/) as well as on the downloads (https://www.qubes-os.org/downloads/) page under the Qubes OS 4.2.0-rc2 ISO.
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 Qubes OS supported releases (https://www.qubes-os.org/doc/supported-releases/) and the version scheme (https://www.qubes-os.org/doc/version-scheme/) in our documentation.
What is a minor release?
The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version numbers are written as ... Hence, releases that increment the second value are known as “minor releases.” Minor releases generally include new features, improvements, and bug fixes that are backward-compatible with earlier versions of the same major release. See our supported releases (https://www.qubes-os.org/doc/supported-releases/) for a comprehensive list of major and minor releases and our version scheme (https://www.qubes-os.org/doc/version-scheme/) documentation for more information about how Qubes OS releases are versioned.
❤2👍2🤮1
Qubes OS 4.2.0-rc3 is available for testing
https://www.qubes-os.org/news/2023/09/03/qubes-os-4-2-0-rc3-available-for-testing/
We’re pleased to announce that the third release candidate (RC) (https://www.qubes-os.org/news/2023/09/03/qubes-os-4-2-0-rc3-available-for-testing/#what-is-a-release-candidate) for Qubes OS 4.2.0 is now available for testing (https://www.qubes-os.org/doc/testing/). The ISO and associated verification files (https://www.qubes-os.org/security/verifying-signatures/) are available on the downloads (https://www.qubes-os.org/downloads/) page.
Explanation for the early RC
We announced RC2 (https://www.qubes-os.org/news/2023/08/28/qubes-os-4-2-0-rc2-available-for-testing/) approximately one week ago. Normally, RC2 would have been tested for approximately five weeks (https://www.qubes-os.org/doc/version-scheme/#release-schedule) before we announced RC3. However, RC2 contained several bugs (listed below), some of which prevented certain users from testing it. These bugs have been fixed in RC3. We’ve decided to release RC3 early, as an exception to our usual policy, in order to get these fixes out as quickly as possible so that more users can test 4.2 for longer before the eventual stable release.
Main changes from RC2 to RC3
Fixed: “Installer in R4.2 does not warn about incompatible hardware” (#8345) (https://github.com/QubesOS/qubes-issues/issues/8345)
Fixed: “Wi-Fi firmware missing from default templates on 4.2.0-rc2 ISO” (#8452) (https://github.com/QubesOS/qubes-issues/issues/8452)
Fixed: “Qubes R4.2.0-rc2 cannot be installed on legacy BIOS system” (#8462) (https://github.com/QubesOS/qubes-issues/issues/8462)
Fixed: “R4.2 (rc1, rc2) unable to boot on Thinkpad T430 when UEFI is enabled” (#8464) (https://github.com/QubesOS/qubes-issues/issues/8464)
For an overview of major changes from Qubes 4.1 to 4.2, please see the Qubes OS 4.2.0 release notes (https://www.qubes-os.org/doc/releases/4.2/release-notes/).
When is the stable release?
That depends on the number of bugs discovered in this RC and their severity. As explained in our release schedule (https://www.qubes-os.org/doc/version-scheme/#release-schedule) documentation, our usual process after issuing a new RC is to collect bug reports, triage the bugs, and fix them. This usually takes around five weeks, depending on the bugs discovered. If warranted, we then issue a new RC that includes the fixes and repeat the whole process again. We continue this iterative procedure until we’re left with an RC that’s good enough to be declared the stable release. No one can predict, at the outset, how many iterations will be required (and hence how many RCs will be needed before a stable release), but we tend to get a clearer picture of this with each successive RC, which we share in this section in each RC announcement.
At this point, we can say that there will be at least one more RC after this one.
Testing Qubes 4.2.0-rc3
Thank you to everyone who tested the previous Qubes 4.2.0 RCs! Due to your efforts, this new RC includes fixes for several bugs that were present in the previous RCs.
If you’re willing to test (https://www.qubes-os.org/doc/testing/) this new RC, you can help us improve the eventual stable release by reporting any bugs you encounter (https://www.qubes-os.org/doc/issue-tracking/). We encourage experienced users to join the testing team (https://forum.qubes-os.org/t/joining-the-testing-team/5190).
A full list of issues affecting Qubes 4.2.0 is available here (https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+label%3Aaffects-4.2). We strongly recommend updating Qubes OS (https://www.qubes-os.org/doc/how-to-update/) immediately after installation in order to apply all available bug fixes.
Upgrading to Qubes 4.2.0-rc3
https://www.qubes-os.org/news/2023/09/03/qubes-os-4-2-0-rc3-available-for-testing/
We’re pleased to announce that the third release candidate (RC) (https://www.qubes-os.org/news/2023/09/03/qubes-os-4-2-0-rc3-available-for-testing/#what-is-a-release-candidate) for Qubes OS 4.2.0 is now available for testing (https://www.qubes-os.org/doc/testing/). The ISO and associated verification files (https://www.qubes-os.org/security/verifying-signatures/) are available on the downloads (https://www.qubes-os.org/downloads/) page.
Explanation for the early RC
We announced RC2 (https://www.qubes-os.org/news/2023/08/28/qubes-os-4-2-0-rc2-available-for-testing/) approximately one week ago. Normally, RC2 would have been tested for approximately five weeks (https://www.qubes-os.org/doc/version-scheme/#release-schedule) before we announced RC3. However, RC2 contained several bugs (listed below), some of which prevented certain users from testing it. These bugs have been fixed in RC3. We’ve decided to release RC3 early, as an exception to our usual policy, in order to get these fixes out as quickly as possible so that more users can test 4.2 for longer before the eventual stable release.
Main changes from RC2 to RC3
Fixed: “Installer in R4.2 does not warn about incompatible hardware” (#8345) (https://github.com/QubesOS/qubes-issues/issues/8345)
Fixed: “Wi-Fi firmware missing from default templates on 4.2.0-rc2 ISO” (#8452) (https://github.com/QubesOS/qubes-issues/issues/8452)
Fixed: “Qubes R4.2.0-rc2 cannot be installed on legacy BIOS system” (#8462) (https://github.com/QubesOS/qubes-issues/issues/8462)
Fixed: “R4.2 (rc1, rc2) unable to boot on Thinkpad T430 when UEFI is enabled” (#8464) (https://github.com/QubesOS/qubes-issues/issues/8464)
For an overview of major changes from Qubes 4.1 to 4.2, please see the Qubes OS 4.2.0 release notes (https://www.qubes-os.org/doc/releases/4.2/release-notes/).
When is the stable release?
That depends on the number of bugs discovered in this RC and their severity. As explained in our release schedule (https://www.qubes-os.org/doc/version-scheme/#release-schedule) documentation, our usual process after issuing a new RC is to collect bug reports, triage the bugs, and fix them. This usually takes around five weeks, depending on the bugs discovered. If warranted, we then issue a new RC that includes the fixes and repeat the whole process again. We continue this iterative procedure until we’re left with an RC that’s good enough to be declared the stable release. No one can predict, at the outset, how many iterations will be required (and hence how many RCs will be needed before a stable release), but we tend to get a clearer picture of this with each successive RC, which we share in this section in each RC announcement.
At this point, we can say that there will be at least one more RC after this one.
Testing Qubes 4.2.0-rc3
Thank you to everyone who tested the previous Qubes 4.2.0 RCs! Due to your efforts, this new RC includes fixes for several bugs that were present in the previous RCs.
If you’re willing to test (https://www.qubes-os.org/doc/testing/) this new RC, you can help us improve the eventual stable release by reporting any bugs you encounter (https://www.qubes-os.org/doc/issue-tracking/). We encourage experienced users to join the testing team (https://forum.qubes-os.org/t/joining-the-testing-team/5190).
A full list of issues affecting Qubes 4.2.0 is available here (https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+label%3Aaffects-4.2). We strongly recommend updating Qubes OS (https://www.qubes-os.org/doc/how-to-update/) immediately after installation in order to apply all available bug fixes.
Upgrading to Qubes 4.2.0-rc3
👍3
If you’re currently running any Qubes 4.2.0 RC, you can upgrade to the latest RC by updating normally (https://www.qubes-os.org/doc/how-to-update/). However, please note that there have been some recent template changes, which are detailed in the Qubes OS 4.2.0 release notes (https://www.qubes-os.org/doc/releases/4.2/release-notes/).
If you’re currently on Qubes 4.1 and wish to test 4.2, please see how to upgrade to Qubes 4.2 (https://www.qubes-os.org/doc/upgrade/4.2/), which details both clean installation and in-place upgrade options. As always, we strongly recommend making a full backup (https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/) beforehand.
Reminder: new signing key for Qubes OS 4.2
As a reminder, we published the following special announcement in Qubes Canary 032 (https://www.qubes-os.org/news/2022/09/14/canary-032/) on 2022-09-14:
We plan to create a new Release Signing Key (RSK) for Qubes OS 4.2. Normally, we have only one RSK for each major release. However, for the 4.2 release, we will be using Qubes Builder version 2, which is a complete rewrite of the Qubes Builder. Out of an abundance of caution, we would like to isolate the build processes of the current stable 4.1 release and the upcoming 4.2 release from each other at the cryptographic level in order to minimize the risk of a vulnerability in one affecting the other. We are including this notice as a canary special announcement since introducing a new RSK for a minor release is an exception to our usual RSK management policy.
As always, we encourage you to authenticate (https://www.qubes-os.org/security/pack/#how-to-obtain-and-authenticate) this canary by verifying its PGP signatures (https://www.qubes-os.org/security/verifying-signatures/). Specific instructions are also included in the canary announcement (https://www.qubes-os.org/news/2022/09/14/canary-032/).
As with all Qubes signing keys, we also encourage you to authenticate (https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-release-signing-keys) the new Qubes OS Release 4.2 Signing Key, which is available in the Qubes Security Pack (qubes-secpack) (https://www.qubes-os.org/security/pack/) as well as on the downloads (https://www.qubes-os.org/downloads/) page under the Qubes OS 4.2.0-rc3 ISO.
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. RCs 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 Qubes OS supported releases (https://www.qubes-os.org/doc/supported-releases/) and the version scheme (https://www.qubes-os.org/doc/version-scheme/) in our documentation.
If you’re currently on Qubes 4.1 and wish to test 4.2, please see how to upgrade to Qubes 4.2 (https://www.qubes-os.org/doc/upgrade/4.2/), which details both clean installation and in-place upgrade options. As always, we strongly recommend making a full backup (https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/) beforehand.
Reminder: new signing key for Qubes OS 4.2
As a reminder, we published the following special announcement in Qubes Canary 032 (https://www.qubes-os.org/news/2022/09/14/canary-032/) on 2022-09-14:
We plan to create a new Release Signing Key (RSK) for Qubes OS 4.2. Normally, we have only one RSK for each major release. However, for the 4.2 release, we will be using Qubes Builder version 2, which is a complete rewrite of the Qubes Builder. Out of an abundance of caution, we would like to isolate the build processes of the current stable 4.1 release and the upcoming 4.2 release from each other at the cryptographic level in order to minimize the risk of a vulnerability in one affecting the other. We are including this notice as a canary special announcement since introducing a new RSK for a minor release is an exception to our usual RSK management policy.
As always, we encourage you to authenticate (https://www.qubes-os.org/security/pack/#how-to-obtain-and-authenticate) this canary by verifying its PGP signatures (https://www.qubes-os.org/security/verifying-signatures/). Specific instructions are also included in the canary announcement (https://www.qubes-os.org/news/2022/09/14/canary-032/).
As with all Qubes signing keys, we also encourage you to authenticate (https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-release-signing-keys) the new Qubes OS Release 4.2 Signing Key, which is available in the Qubes Security Pack (qubes-secpack) (https://www.qubes-os.org/security/pack/) as well as on the downloads (https://www.qubes-os.org/downloads/) page under the Qubes OS 4.2.0-rc3 ISO.
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. RCs 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 Qubes OS supported releases (https://www.qubes-os.org/doc/supported-releases/) and the version scheme (https://www.qubes-os.org/doc/version-scheme/) in our documentation.
👍5
XSAs released on 2023-09-05
https://www.qubes-os.org/news/2023/09/05/xsas-released-on-2023-09-05/
The Xen Project (https://xenproject.org/) has released one or more Xen security advisories (XSAs) (https://xenbits.xen.org/xsa/).
The security of Qubes OS is not affected.
Therefore, no user action is required.
XSAs that DO affect the security of Qubes OS
The following XSAs do affect the security of Qubes OS:
(none)
XSAs that DO NOT affect the security of Qubes OS
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-437 (https://xenbits.xen.org/xsa/advisory-437.html)
This affects only 32-bit ARM processors, which Qubes OS does not support.
About this announcement
Qubes OS uses the Xen hypervisor (https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as part of its architecture (https://www.qubes-os.org/doc/architecture/). When the Xen Project (https://xenproject.org/) publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA) (https://xenproject.org/developers/security-policy/). Vulnerabilities in the Xen hypervisor sometimes have security implications for Qubes OS. When they do, we issue a notice called a Qubes security bulletin (QSB) (https://www.qubes-os.org/security/qsb/). (QSBs are also issued for non-Xen vulnerabilities.) However, QSBs can provide only positive confirmation that certain XSAs do affect the security of Qubes OS. QSBs cannot provide negative confirmation that other XSAs do not affect the security of Qubes OS. Therefore, we also maintain an XSA tracker (https://www.qubes-os.org/security/xsa/), which is a comprehensive list of all XSAs publicly disclosed to date, including whether each one affects the security of Qubes OS. When new XSAs are published, we add them to the XSA tracker and publish a notice like this one in order to inform Qubes users that a new batch of XSAs has been released and whether each one affects the security of Qubes OS.
https://www.qubes-os.org/news/2023/09/05/xsas-released-on-2023-09-05/
The Xen Project (https://xenproject.org/) has released one or more Xen security advisories (XSAs) (https://xenbits.xen.org/xsa/).
The security of Qubes OS is not affected.
Therefore, no user action is required.
XSAs that DO affect the security of Qubes OS
The following XSAs do affect the security of Qubes OS:
(none)
XSAs that DO NOT affect the security of Qubes OS
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-437 (https://xenbits.xen.org/xsa/advisory-437.html)
This affects only 32-bit ARM processors, which Qubes OS does not support.
About this announcement
Qubes OS uses the Xen hypervisor (https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as part of its architecture (https://www.qubes-os.org/doc/architecture/). When the Xen Project (https://xenproject.org/) publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA) (https://xenproject.org/developers/security-policy/). Vulnerabilities in the Xen hypervisor sometimes have security implications for Qubes OS. When they do, we issue a notice called a Qubes security bulletin (QSB) (https://www.qubes-os.org/security/qsb/). (QSBs are also issued for non-Xen vulnerabilities.) However, QSBs can provide only positive confirmation that certain XSAs do affect the security of Qubes OS. QSBs cannot provide negative confirmation that other XSAs do not affect the security of Qubes OS. Therefore, we also maintain an XSA tracker (https://www.qubes-os.org/security/xsa/), which is a comprehensive list of all XSAs publicly disclosed to date, including whether each one affects the security of Qubes OS. When new XSAs are published, we add them to the XSA tracker and publish a notice like this one in order to inform Qubes users that a new batch of XSAs has been released and whether each one affects the security of Qubes OS.
👍1
The NitroPC Pro is Qubes-certified!
https://www.qubes-os.org/news/2023/09/06/nitropc-pro-qubes-certified/
It is our pleasure to announce that the NitroPC Pro (https://shop.nitrokey.com/shop/product/nitropc-pro-523) is officially certified (https://www.qubes-os.org/doc/certified-hardware/) for Qubes OS Release 4!
The NitroPC Pro: a secure, powerful workstation
The NitroPC Pro (https://shop.nitrokey.com/shop/product/nitropc-pro-523) is a workstation for high security and performance requirements. The open-source Dasharo coreboot (https://github.com/Dasharo/coreboot) firmware ensures high transparency and security while avoiding backdoors and security holes in the firmware. The device is certified for compatibility with Qubes OS 4.X by the Qubes developers. Carefully selected components ensure high performance, stability, and durability. The Dasharo Entry Subnoscription guarantees continuous firmware development and fast firmware updates.
https://www.qubes-os.org/news/2023/09/06/nitropc-pro-qubes-certified/
It is our pleasure to announce that the NitroPC Pro (https://shop.nitrokey.com/shop/product/nitropc-pro-523) is officially certified (https://www.qubes-os.org/doc/certified-hardware/) for Qubes OS Release 4!
The NitroPC Pro: a secure, powerful workstation
The NitroPC Pro (https://shop.nitrokey.com/shop/product/nitropc-pro-523) is a workstation for high security and performance requirements. The open-source Dasharo coreboot (https://github.com/Dasharo/coreboot) firmware ensures high transparency and security while avoiding backdoors and security holes in the firmware. The device is certified for compatibility with Qubes OS 4.X by the Qubes developers. Carefully selected components ensure high performance, stability, and durability. The Dasharo Entry Subnoscription guarantees continuous firmware development and fast firmware updates.
👍2
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
Integrated graphics
Intel UHD 770
Discrete graphics (optional)
Nvidia Geforce RTX 4070 or 4090
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 Subnoscription,” 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 Subnoscription (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.
Special note regarding the need for kernel-latest
Beginning with Qubes OS 4.1.2, the Qubes installer includes the kernel-latest package and allows users to select this kernel option from the GRUB menu when booting the installer. At the time of this announcement, kernel-latest is required for the NitroPC Pro’s graphics drivers to function properly. Therefore, all potential purchasers and users of this model should be aware that they will have to select a non-default option (Install Qubes OS RX using kernel-latest) from the GRUB menu when booting the installer. However, since Linux 6.1 has officially been promoted to being a long-term support (LTS) kernel, it will become the default kernel at some point, which means that the need for this non-default selection is only temporary.
About Nitrokey
Nitrokey (https://www.nitrokey.com/) is a world-leading company in open-source security hardware. Nitrokey develops IT security hardware for data encryption, key management and user authentication, as well as secure network devices, PCs, laptops, and smartphones. The company was founded in Berlin, Germany in 2015 and already counts tens of thousands of users from more than 120 countries, including numerous well-known international enterprises from various industries, among its customers. Learn more. (https://www.nitrokey.com/about)
About Dasharo
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
Integrated graphics
Intel UHD 770
Discrete graphics (optional)
Nvidia Geforce RTX 4070 or 4090
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 Subnoscription,” 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 Subnoscription (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.
Special note regarding the need for kernel-latest
Beginning with Qubes OS 4.1.2, the Qubes installer includes the kernel-latest package and allows users to select this kernel option from the GRUB menu when booting the installer. At the time of this announcement, kernel-latest is required for the NitroPC Pro’s graphics drivers to function properly. Therefore, all potential purchasers and users of this model should be aware that they will have to select a non-default option (Install Qubes OS RX using kernel-latest) from the GRUB menu when booting the installer. However, since Linux 6.1 has officially been promoted to being a long-term support (LTS) kernel, it will become the default kernel at some point, which means that the need for this non-default selection is only temporary.
About Nitrokey
Nitrokey (https://www.nitrokey.com/) is a world-leading company in open-source security hardware. Nitrokey develops IT security hardware for data encryption, key management and user authentication, as well as secure network devices, PCs, laptops, and smartphones. The company was founded in Berlin, Germany in 2015 and already counts tens of thousands of users from more than 120 countries, including numerous well-known international enterprises from various industries, among its customers. Learn more. (https://www.nitrokey.com/about)
About Dasharo
👍1
“Dasharo is an open-source firmware distribution focusing on seamless deployment, clean and simple code, long-term maintenance, professional support, transparent validation, superior documentation, privacy-respecting implementation, liberty for the owners and trustworthiness for all.” —the Dasharo documentation (https://docs.dasharo.com/)
Dasharo (https://www.dasharo.com/) is a registered trademark of and a product developed by 3mdeb (https://3mdeb.com/).
What is Qubes-certified hardware?
Qubes-certified hardware (https://www.qubes-os.org/doc/certified-hardware/) is hardware that has been certified by the Qubes developers as compatible with a specific major release (https://www.qubes-os.org/doc/version-scheme/) of Qubes OS. All Qubes-certified devices are available for purchase with Qubes OS preinstalled. Beginning with Qubes 4.0, in order to achieve certification, the hardware must satisfy a rigorous set of [requirements], and the vendor must commit to offering customers the very same configuration (same motherboard, same screen, same BIOS version, same Wi-Fi module, etc.) for at least one year.
Qubes-certified computers (https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-computers) are specific models that are regularly tested by the Qubes developers to ensure compatibility with all of Qubes’ features. The developers test all new major versions and updates to ensure that no regressions are introduced.
It is important to note, however, that Qubes hardware certification certifies only that a particular hardware configuration is supported by Qubes. The Qubes OS Project takes no responsibility for any vendor’s manufacturing, shipping, payment, or other practices, nor can we control whether physical hardware is modified (whether maliciously or otherwise) en route to the user.
Dasharo (https://www.dasharo.com/) is a registered trademark of and a product developed by 3mdeb (https://3mdeb.com/).
What is Qubes-certified hardware?
Qubes-certified hardware (https://www.qubes-os.org/doc/certified-hardware/) is hardware that has been certified by the Qubes developers as compatible with a specific major release (https://www.qubes-os.org/doc/version-scheme/) of Qubes OS. All Qubes-certified devices are available for purchase with Qubes OS preinstalled. Beginning with Qubes 4.0, in order to achieve certification, the hardware must satisfy a rigorous set of [requirements], and the vendor must commit to offering customers the very same configuration (same motherboard, same screen, same BIOS version, same Wi-Fi module, etc.) for at least one year.
Qubes-certified computers (https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-computers) are specific models that are regularly tested by the Qubes developers to ensure compatibility with all of Qubes’ features. The developers test all new major versions and updates to ensure that no regressions are introduced.
It is important to note, however, that Qubes hardware certification certifies only that a particular hardware configuration is supported by Qubes. The Qubes OS Project takes no responsibility for any vendor’s manufacturing, shipping, payment, or other practices, nor can we control whether physical hardware is modified (whether maliciously or otherwise) en route to the user.
👍1
If anyone is looking to donate to QubesOS to help the project you can visit their official donation page here > qubes-os.org/donate
Anything helps! They accept Bitcoin, Ethereum and Monero as well as credit card or PayPal.
This message is not from QubesOS Team
Anything helps! They accept Bitcoin, Ethereum and Monero as well as credit card or PayPal.
This message is not from QubesOS Team
Qubes OS
Donate to Qubes
Qubes is a security-oriented, free and open-source operating system for personal computers that allows you to securely compartmentalize your digital life.
🔥4