[qubes-devel] Qubes OS 4.1 to receive extended security support until 2024-07-31

[Andrew David Wong]

Dear Qubes Community,

Qubes OS 4.1 will reach official end-of-life (EOL) on 2024-06-18. After this 
date, Qubes OS 4.1 will continue to receive extended security support until 
2024-07-31. This security support extension is sponsored by [Freedom of the 
Press Foundation (FPF)](https://freedom.press/) in support of the 
[SecureDrop](https://securedrop.org/) project.

## What's happening?

According to the Qubes OS Project's [release support 
policy](https://www.qubes-os.org/doc/supported-releases/), 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.1 will reach EOL six months after Qubes 4.2 was released. Since Qubes 4.2 was 
[released](https://www.qubes-os.org/news/2023/12/18/qubes-os-4-2-0-has-been-released/)
 on 2023-12-18, Qubes 4.1 is 
[scheduled](https://www.qubes-os.org/news/2024/03/26/qubes-os-4-1-reaches-eol-on-2024-06-18/)
 to reach EOL six months later on 2024-06-18.

[SecureDrop](https://securedrop.org/) currently relies on Qubes 4.1 for the 
[SecureDrop Workstation](https://workstation.securedrop.org/). To allow for 
additional time to ensure full compatibility of the SecureDrop Workstation with 
Qubes 4.2, and to help existing users migrate, FPF has offered to sponsor an 
extension of post-EOL Qubes 4.1 security support until 2024-07-31, and the 
Qubes OS Project has agreed.

## What does extended security support cover?

The [Qubes security 
team](https://www.qubes-os.org/security/#qubes-security-team) will continue to 
publish [Qubes security bulletins 
(QSBs)](https://www.qubes-os.org/security/qsb/) and release security updates 
for security vulnerabilities affecting Qubes 4.1, as it deems appropriate, 
until 2024-07-31. Extended security support does *not* cover regular bug fixes, 
improvements, or the implementation of new features.

In short, if you currently have a Qubes 4.1 installation that serves your 
needs, you may safely continue to use it until 2024-07-31, but we strongly 
recommend [upgrading to Qubes 4.2](https://www.qubes-os.org/doc/upgrade/4.2/) 
by that date.

## What's involved in extending security support for Qubes 4.1?

Extending support for a Qubes release is more challenging than it might seem on 
the surface. Here are some of the main considerations involved:

1. *Xen support*: Official support for Xen 4.14 has already ended, which means 
that backporting Xen-related security fixes will require more work than usual.

2. *Template support*: Qubes 4.1 supports Debian 11, which has quite old 
software. This is known to cause problems and to require workarounds (e.g., 
with `salt` and `app-u2f`). There will be no Fedora 40 template for Qubes 4.1, 
but that's okay since Fedora 39 doesn't reach EOL until November.

3. *Other dom0 software*: Qubes 4.1's dom0 is based on Fedora 32, which is now 
quite old. If we end up having to backport any fixes here (e.g., due to an RPM 
or GPG bug), it may be quite complicated.

4. *Whonix support*: Any extension of the support period for a Qubes release 
must also take into consideration Whonix support. Previously, [Whonix 16 
reached 
EOL](https://www.qubes-os.org/news/2023/12/22/whonix-16-approaching-eol/) even 
though Qubes 4.1 has not yet reached EOL. Whonix 17 did not support Qubes 4.1 
at the time, which meant users on Qubes 4.1 were at risk of being left without 
any supported way to continue using Whonix. The Whonix and Qubes teams 
successfully bridged this gap by [making Whonix 17 available on Qubes 
4.1](https://www.qubes-os.org/news/2024/02/05/whonix-17-templates-available-for-qubes-os-4-1/).
 Now, Qubes 4.1 will receive extended security support, which will require a 
commensurate extension of security support for Whonix 17 on Qubes 4.1. FPF and 
the Whonix Project have arranged for the required Whonix 17 support extension 
to be included with the Qubes 4.1 extension, so Whonix 17 security support on 
Qubes 4.1 will continue until 2024-07-31.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2024/05/10/qubes-os-4-1-to-receive-extended-support-until-2024-07-31/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/f3cbd722-20c8-4a0a-a437-f22be84ff585%40qubes-os.org.

[qubes-devel] XSAs released on 2024-05-07

[Andrew David Wong]

Dear Qubes Community,

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.

## 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-457](https://xenbits.xen.org/xsa/advisory-457.html)
  - Denial of service (DoS) only

## 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2024/05/08/xsas-released-on-2024-05-07/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/4c0c9522-7f24-489d-88cc-2aa807a01699%40qubes-os.org.

Re: [qubes-devel] Qubes R4.2 EOL: No upgrade path for installations with Windows and QWT

[Andrew David Wong]

On 4/13/24 8:56 AM, jmake2 via qubes-devel wrote:
> [...]
> 
> So, am I getting it right that QWT is not deprecated? I was afraid for a 
> moment.

As stated in the QSB, the developers are still working on QWT, so it is not 
deprecated.

> As it was discussed previously, the QWT package can be build from secure and 
> available sources and put to R4.2+ repos with different signatures, including 
> secure self-signed but not Microsoft-approved key. Requirement to allow 
> self-signed drivers is not perfect, but still a way better solution than 
> current situation, to my understanding.
> 
> [...]

I believe this is the relevant issue:

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/e60fe74c-3f6b-4cc0-a0f7-7344569ad364%40qubes-os.org.

Re: [qubes-devel] Qubes R4.2 EOL: No upgrade path for installations with Windows and QWT

[Andrew David Wong]

On 4/13/24 8:15 AM, jmake2 via qubes-devel wrote:
> Apr 13, 2024, 06:46 by a...@qubes-os.org:
> 
>> On 4/12/24 4:50 AM, Gerhard Weck wrote:
>>
>>> [...]
>>>
>>> - Things may look different, if an attacker could, via the Xen PV drivers, 
>>> break out of a Windows VM with QWT and compromise Xen, and therefore Qubes 
>>> itself. In this case, usage of a Windows VM with the insecure QWT may be 
>>> too risky in many, but not all circumstances. So far, I found no 
>>> information, if such a scenario is possible at all. What is the extent of 
>>> possible compromises of the Xen PV drivers - is it just local to the VM or 
>>> could it reach into Qubes itself? It would be helpful if this could be 
>>> clarified somehow.
>>>
>>> [...]
>>>
>>
>> This was already clearly addressed in QSB-091:
>>
>>> Impact
>>> ---
>>>
>>> If the Xen Project's Windows PV Drivers were compromised at build time,
>>> all Windows qubes that have Qubes Windows Tools (QWT) installed may also
>>> be compromised. If the drivers were not compromised at build time, then
>>> there is no known vulnerability.
>>>
>>> Dom0 is not affected, even though the `qubes-windows-tools` package is
>>> installed in dom0, since neither the dom0 package build process nor dom0
>>> itself interprets these driver files. Rather, the purpose of this
>>> package is merely to make the driver files available to the Windows
>>> qubes in which QWT are installed.
>>>
>>
>> In other words, only the Windows VMs using QWT are potentially at risk, not 
>> dom0, Xen, or Qubes OS itself.
>>
> 
> 
> @adw , thank you. So, QWT does not directly affect security of dom0 nor other 
> non-windows qubes.
> 
> Please also tell if QWT is deprecated, as unman kind of said, or not?
> 

This is also addressed in QSB-091:

> At the time of writing, the Xen Project has not published replacement
> binaries signed by a Microsoft-approved key. The process for doing this
> has changed since the last version of Windows PV Drivers was released,
> and we have no information as to whether or when new signed binaries
> will be available. [2]
> 
> In order to avoid similar problems in the future, we are working on a
> more permanent solution regarding the need for signed PV drivers in QWT.
> In the meantime, we will replace the `qubes-windows-tools` package with
> a dummy package containing only warning text.

https://www.qubes-os.org/news/2023/07/27/qsb-091/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/ac93e4c5-e279-404b-aff3-914a3c699271%40qubes-os.org.

Re: [qubes-devel] Qubes R4.2 EOL: No upgrade path for installations with Windows and QWT

[Andrew David Wong]

On 4/12/24 4:50 AM, Gerhard Weck wrote:
> [...]
> 
> - Things may look different, if an attacker could, via the Xen PV drivers, 
> break out of a Windows VM with QWT and compromise Xen, and therefore Qubes 
> itself. In this case, usage of a Windows VM with the insecure QWT may be 
> too risky in many, but not all circumstances. So far, I found no 
> information, if such a scenario is possible at all. What is the extent of 
> possible compromises of the Xen PV drivers - is it just local to the VM or 
> could it reach into Qubes itself? It would be helpful if this could be 
> clarified somehow.
> 
> [...]
> 

This was already clearly addressed in QSB-091:

> Impact
> ---
> 
> If the Xen Project's Windows PV Drivers were compromised at build time,
> all Windows qubes that have Qubes Windows Tools (QWT) installed may also
> be compromised. If the drivers were not compromised at build time, then
> there is no known vulnerability.
> 
> Dom0 is not affected, even though the `qubes-windows-tools` package is
> installed in dom0, since neither the dom0 package build process nor dom0
> itself interprets these driver files. Rather, the purpose of this
> package is merely to make the driver files available to the Windows
> qubes in which QWT are installed.

In other words, only the Windows VMs using QWT are potentially at risk, not 
dom0, Xen, or Qubes OS itself.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/a6af30cf-6c9e-4192-a37c-19a57b1df1c0%40qubes-os.org.

[qubes-devel] XSAs released on 2024-04-09

[Andrew David Wong]

Dear Qubes Community,

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*.

## XSAs that DO affect the security of Qubes OS

The following XSAs *do affect* the security of Qubes OS:

- [XSA-455](https://xenbits.xen.org/xsa/advisory-455.html)
  - See [QSB-102](https://www.qubes-os.org/news/2024/04/10/qsb-102/)
- [XSA-456](https://xenbits.xen.org/xsa/advisory-456.html) (At the time of 
publication, this page was missing from the Xen Project website, so we are also 
including a link to the [email announcement for 
XSA-456](https://lists.xenproject.org/archives/html/xen-announce/2024-04/msg4.html).)
  - See [QSB-102](https://www.qubes-os.org/news/2024/04/10/qsb-102/)

## 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-454](https://xenbits.xen.org/xsa/advisory-454.html)
  - Denial of service (DoS) only

## 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2024/04/10/xsas-released-on-2024-04-09/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/23faf24b-9c58-48ca-a496-3635efa667ac%40qubes-os.org.

[qubes-devel] QSB-102: Multiple speculative-execution vulnerabilities: Spectre-BHB, BTC/SRSO (XSA-455, XSA-456)

[Andrew David Wong]

(https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-the-qubes-master-signing-key).)

2. 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.)

   ```shell_session
   $ 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
   ```

3. *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. For more 
information, see [How to import and authenticate the Qubes Master Signing 
Key](https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-the-qubes-master-signing-key).

   *Tip*: After you have authenticated the QMSK out-of-band to your 
satisfaction, record the QMSK fingerprint in a safe place (or several) so that 
you don't have to repeat this step in the future.

4. Once you are satisfied that you have the genuine QMSK, set its trust level 
to 5 ("ultimate"), then quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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 BB522745

[qubes-devel] Qubes OS 4.1 reaches EOL on 2024-06-18

[Andrew David Wong]

Dear Qubes Community,

Qubes OS 4.1 is scheduled to reach end-of-life (EOL) on 2024-06-18, 
approximately three months from the date of this announcement.

## Recommended actions

If you're already using Qubes 4.2, then you don't have to do anything. This 
announcement doesn't affect you.

If you're still using Qubes 4.1, then now is the perfect opportunity to 
upgrade, since a brand new [Qubes OS 4.2.1 ISO was just released 
today](https://www.qubes-os.org/news/2024/03/26/qubes-os-4-2-1-has-been-released/)!
 (This is also the best way to get started with Qubes if you don't have it 
installed yet.)

If you'd prefer not to reinstall, you can instead perform an [in-place upgrade 
from Qubes 4.1 to 
4.2](https://www.qubes-os.org/doc/upgrade/4.2/#in-place-upgrade).

Whichever option you choose, we strongly recommend [making a full 
backup](https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/) 
beforehand and ensuring you're on Qubes 4.2 by 2024-06-18.

## What does end-of-life (EOL) mean?

When a Qubes OS release reaches end-of-life (EOL), it is no longer supported. 
This means that bugs discovered in that release will no longer be fixed, and 
enhancements will no longer be added. Most importantly, releases that have 
reached EOL no longer receive security updates, which is why it's critically 
important to upgrade to a supported release.

## 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.1" (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.1.0, 4.1.1, and 4.1.2 will all reach EOL at the same time (on 2024-06-18), 
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.1 reaches EOL six months after Qubes 4.2 was released. Since Qubes 4.2.0 was 
[released on 
2023-12-18](https://www.qubes-os.org/news/2023/12/18/qubes-os-4-2-0-has-been-released/),
 Qubes 4.1's EOL date is six months later, on 2024-06-18.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2024/03/26/qubes-os-4-1-reaches-eol-on-2024-06-18/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/0e20b8fa-8d37-485c-b747-8cf51010e31f%40qubes-os.org.

[qubes-devel] Qubes OS 4.2.1 has been released!

[Andrew David Wong]

Dear Qubes Community,

We're pleased to announce the stable release of Qubes OS 4.2.1! This [patch 
release](#what-is-a-patch-release) aims to consolidate all the security 
patches, bug fixes, and other updates that have occurred since the release of 
Qubes 4.2.0. 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. 
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.

## What's new in Qubes OS 4.2.1?

Qubes 4.2.1 includes numerous updates over the initial 4.2.0 release, in 
particular:

- All 4.2 dom0 updates to date
- Fedora 39 template
- Linux 6.6.x as the default kernel, significantly reducing the need for 
`kernel-latest` on newer systems

For more information about the changes included in this version, see the [full 
list of issues completed since the release of 
4.2.0](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+is%3Aclosed+reason%3Acompleted+closed%3A2023-12-18..2024-03-14+-label%3A%22R%3A+cannot+reproduce%22+-label%3A%22R%3A+declined%22+-label%3A%22R%3A+duplicate%22+-label%3A%22R%3A+not+applicable%22+-label%3A%22R%3A+self-closed%22+-label%3A%22R%3A+upstream+issue%22+).

## How to get Qubes OS 4.2.1

You have a few different options, depending on your situation:

- If you'd like to install Qubes OS for the first time or perform a clean 
reinstallation on an existing system, there's never been a better time to do 
so! Simply [download](https://www.qubes-os.org/downloads/) the Qubes 4.2.1 ISO 
and follow our [installation 
guide](https://www.qubes-os.org/doc/installation-guide/).

- If you're currently on Qubes 4.1, learn [how to upgrade to Qubes 
4.2](https://www.qubes-os.org/doc/upgrade/4.2/).

- If you're currently on Qubes 4.2 (including 4.2.0 and 4.2.1-rc1), [update 
normally](https://www.qubes-os.org/doc/how-to-update/) (which includes 
[upgrading any EOL 
templates](https://www.qubes-os.org/doc/how-to-update/#upgrading-to-avoid-eol) 
you might have) in order to make your system essentially equivalent to the 
stable Qubes 4.2.1 release. No reinstallation or other special action is 
required.

In all cases, 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.

## 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.2) 
inclusive of all updates up to a certain point. (See [supported 
releases](https://www.qubes-os.org/doc/supported-releases/) for a comprehensive 
list of major and minor releases.) Installing the initial Qubes 4.2.0 release 
and fully [updating](https://www.qubes-os.org/doc/how-to-update/) it results in 
essentially the same system as installing Qubes 4.2.1. You can learn more about 
how Qubes release versioning works in the [version 
scheme](https://www.qubes-os.org/doc/version-scheme/) documentation.


This announcement 

[qubes-devel] Update for QSB-101: Register File Data Sampling (XSA-452) and Intel Processor Return Predictions Advisory (INTEL-SA-00982)

[Andrew David Wong]

.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-the-qubes-master-signing-key).)

2. 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.)

   ```shell_session
   $ 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
   ```

3. *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. For more 
information, see [How to import and authenticate the Qubes Master Signing 
Key](https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-the-qubes-master-signing-key).

   *Tip*: After you have authenticated the QMSK out-of-band to your 
satisfaction, record the QMSK fingerprint in a safe place (or several) so that 
you don't have to repeat this step in the future.

4. Once you are satisfied that you have the genuine QMSK, set its trust level 
to 5 ("ultimate"), then quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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

[qubes-devel] Update for QSB-101: Register File Data Sampling (XSA-452) and Intel Processor Return Predictions Advisory (INTEL-SA-00982)

[Andrew David Wong]

ware: 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
   ```

3. *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. For more 
information, see [How to import and authenticate the Qubes Master Signing 
Key](https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-the-qubes-master-signing-key).

   *Tip*: After you have authenticated the QMSK out-of-band to your 
satisfaction, record the QMSK fingerprint in a safe place (or several) so that 
you don't have to repeat this step in the future.

4. Once you are satisfied that you have the genuine QMSK, set its trust level 
to 5 ("ultimate"), then quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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: "Qube

[qubes-devel] Qubes OS 4.2.1-rc1 is available for testing

[Andrew David Wong]

Dear Qubes Community,

We're pleased to announce that the first [release candidate 
(RC)](#what-is-a-release-candidate) for Qubes OS 4.2.1 is now available for 
[testing](https://www.qubes-os.org/doc/testing/). This [patch 
release](#what-is-a-patch-release) aims to consolidate all the security 
patches, bug fixes, and other updates that have occurred since the release of 
Qubes 4.2.0. 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. 
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. For more 
information about the changes included in this version, see the [full list of 
issues completed since the release of 
4.2.0](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+is%3Aclosed+reason%3Acompleted+closed%3A2023-12-18..2024-03-14+-label%3A%22R%3A+cannot+reproduce%22+-label%3A%22R%3A+declined%22+-label%3A%22R%3A+duplicate%22+-label%3A%22R%3A+not+applicable%22+-label%3A%22R%3A+self-closed%22+-label%3A%22R%3A+upstream+issue%22+).

## 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. If warranted, we then issue a new RC 
that includes the fixes and repeat the process. 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 as testing progresses. Here is the 
latest update:

At this point, we expect the stable release sometime around 2024-03-25.

## Testing Qubes 4.2.1-rc1

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). The best way 
to test Qubes 4.2.1-rc1 is by performing a [clean 
installation](https://www.qubes-os.org/doc/installation-guide/) with the new 
ISO. We strongly recommend [making a full 
backup](https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/) 
beforehand.

As an alternative to a clean installation, there is also the option of 
performing an in-place upgrade without reinstalling. However, since Qubes 4.2.1 
is simply Qubes 4.2.0 inclusive of all updates to date, this amounts to simply 
using a fully-updated 4.2.0 installation. In a sense, then, all current 4.2.0 
users who are keeping up with updates are already testing 4.2.1-rc1, but this 
testing is only partial, since it does not cover things like the installation 
procedure. 

## 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-rc5 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 

[qubes-devel] Qubes OS Summit 2024: September 20-22 in Berlin

[Andrew David Wong]

Dear Qubes Community,

In conjunction with [3mdeb](https://3mdeb.com/), the sixth edition of our Qubes 
OS Summit will be held live this year from September 20 to 22 in Berlin, 
Germany! For more information about this event, please see: 


If you would like to submit a proposal, the Call for Participation (CFP) is 
open until August 5: 


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2024/03/13/qubes-os-summit-2024/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/b9b4b9d7-7283-44c0-b1db-fe4264d71f6e%40qubes-os.org.

[qubes-devel] XSAs released on 2024-03-12

[Andrew David Wong]

Dear Qubes Community,

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*.

## XSAs that DO affect the security of Qubes OS

The following XSAs *do affect* the security of Qubes OS:

- [XSA-452](https://xenbits.xen.org/xsa/advisory-452.html)
  - See [QSB-101](https://www.qubes-os.org/news/2024/03/13/qsb-101/)

## 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-453](https://xenbits.xen.org/xsa/advisory-453.html)
  - The Qubes security team concurs with the Xen security team's assessment in 
the "VULNERABLE SYSTEMS" section of XSA-453.

## 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2024/03/13/xsas-released-on-2024-03-12/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/332b7027-9eae-4cb5-9b23-f4456d5f8204%40qubes-os.org.

[qubes-devel] QSB-101: Register File Data Sampling (XSA-452)

[Andrew David Wong]

ecord the QMSK fingerprint in a safe place (or several) so that 
you don't have to repeat this step in the future.

4. Once you are satisfied that you have the genuine QMSK, set its trust level 
to 5 ("ultimate"), then quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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
   ```

7. Verify signed Git tags.

   ```shell_session
   $ cd qubes-secpack/
   $ git tag -v `git describe`
   object 266e14a6fae57c9a91362c9ac784d3a891f4d351
   type commit
   tag marmarek_sec_266e14a6
   tagger Ma

[qubes-devel] Qubes Canary 038

[Andrew David Wong]

e 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. For more 
information, see [How to import and authenticate the Qubes Master Signing 
Key](https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-the-qubes-master-signing-key).

   *Tip*: After you have authenticated the QMSK out-of-band to your 
satisfaction, record the QMSK fingerprint in a safe place (or several) so that 
you don't have to repeat this step in the future.

4. Once you are satisfied that you have the genuine QMSK, set its trust level 
to 5 ("ultimate"), then quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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 OpenPG

[qubes-devel] Qubes-certified NovaCustom NV41 Series laptop now available with Heads firmware

[Andrew David Wong]

Dear Qubes Community,

Last year, we 
[announced](https://www.qubes-os.org/news/2023/05/03/novacustom-nv41-series-qubes-certified/)
 that the [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) 
became a [Qubes-certified 
computer](https://www.qubes-os.org/doc/certified-hardware) for Qubes OS 4. We 
noted in the announcement that the NV41 Series came with 
[Dasharo](https://www.dasharo.com/) [coreboot](https://www.coreboot.org/) 
open-source firmware.

We are now pleased to announce that the NV41 Series is also available with 
[Heads firmware](https://osresearch.net/). When you [configure your NV41 
Series](https://novacustom.com/product/nv41-series/), you can now choose either 
Dasharo coreboot+EDK-II (default) or Dasharo coreboot+Heads for the firmware. 
Both options are certified for Qubes OS 4. This makes the NV41 Series the first 
modern Qubes-certified computer available with Heads!

Current NV41 Series owners who wish to change from Dasharo coreboot+EDK-II to 
the Heads firmware version can [buy the Dasharo Entry 
Subscription](https://novacustom.com/product/dasharo-entry-subscription/) for 
an easy transition to Heads.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2024/03/03/novacustom-nv41-series-with-heads-certified/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/0a4b53ec-6449-4dec-a084-2c0f67ec1a1a%40qubes-os.org.

[qubes-devel] XSAs released on 2024-02-27

[Andrew David Wong]

Dear Qubes Community,

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*.

## 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-451](https://xenbits.xen.org/xsa/advisory-451.html)
  - Denial of service (DoS) only

## 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2024/02/27/xsas-released-on-2024-02-27/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/d21b067f-877f-4fb7-8625-8a31c04616a4%40qubes-os.org.

[qubes-devel] Re: Fedora 39 templates available; Fedora 38 approaching EOL

[Andrew David Wong]

On 2/13/24 4:17 AM, Andrew David Wong wrote:
> Dear Qubes Community,
> 
> New Fedora 39 templates are now available in standard, 
> [minimal](https://www.qubes-os.org/doc/templates/minimal/), and 
> [Xfce](https://www.qubes-os.org/doc/templates/xfce/) varieties. In addition, 
> Fedora 38 is currently 
> [scheduled](https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html)
>  to reach EOL ([end-of-life](https://fedoraproject.org/wiki/End_of_life)) on 
> 2024-05-14 (approximately three months from now). Please upgrade all of your 
> Fedora templates and standalones by that date. For more information, see 
> [Upgrading to avoid 
> EOL](https://www.qubes-os.org/doc/how-to-update/#upgrading-to-avoid-eol).
> 
> There are two ways to upgrade a template to a new Fedora release:
> 
> - *Recommended*: [Install a fresh template to replace an existing 
> one.](https://www.qubes-os.org/doc/templates/fedora/#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. To see a log of package manager actions, 
> open a terminal in the old Fedora template and use the `dnf history` command.
> 
> - *Advanced*: [Perform an in-place upgrade of an existing Fedora 
> template.](https://www.qubes-os.org/doc/templates/fedora/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.*
> 
> 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)).
> 

## Special note on updating Fedora 39 templates on Qubes 4.1

In order to update Fedora 39 templates on Qubes 4.1, the default management 
disposable template (`default-mgmt-dvm`) must also be based on a Fedora 39 
template. Here is the recommended order of events:

1. [Install](https://www.qubes-os.org/doc/templates/fedora/#installing) a fresh 
Fedora 39 template.
2. [Switch](https://www.qubes-os.org/doc/templates/#switching) 
`default-mgmt-dvm` to the new Fedora 39 template.
3. [Update](https://www.qubes-os.org/doc/how-to-update/) the Fedora 39 template.

By default, this applies only to Qubes 4.1, since the default update mechanism 
in Qubes 4.2 no longer relies on Salt. (However, if you have configured your 
Qubes 4.2 system so that it uses Salt for updates, then this still applies to 
you.)

> 
> This announcement is also available on the Qubes website:
> https://www.qubes-os.org/news/2024/02/13/fedora-39-templates-available-fedora-38-approaching-eol/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/ab13180e-e814-46dc-bfaf-58eda26e9a91%40qubes-os.org.

[qubes-devel] Fedora 39 templates available; Fedora 38 approaching EOL

[Andrew David Wong]

Dear Qubes Community,

New Fedora 39 templates are now available in standard, 
[minimal](https://www.qubes-os.org/doc/templates/minimal/), and 
[Xfce](https://www.qubes-os.org/doc/templates/xfce/) varieties. In addition, 
Fedora 38 is currently 
[scheduled](https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html) 
to reach EOL ([end-of-life](https://fedoraproject.org/wiki/End_of_life)) on 
2024-05-14 (approximately three months from now). Please upgrade all of your 
Fedora templates and standalones by that date. For more information, see 
[Upgrading to avoid 
EOL](https://www.qubes-os.org/doc/how-to-update/#upgrading-to-avoid-eol).

There are two ways to upgrade a template to a new Fedora release:

- *Recommended*: [Install a fresh template to replace an existing 
one.](https://www.qubes-os.org/doc/templates/fedora/#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. To see a log of package manager actions, 
open a terminal in the old Fedora template and use the `dnf history` command.

- *Advanced*: [Perform an in-place upgrade of an existing Fedora 
template.](https://www.qubes-os.org/doc/templates/fedora/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.*

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)).


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2024/02/13/fedora-39-templates-available-fedora-38-approaching-eol/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/8a18436a-3608-4617-a18f-9cb0b22883cc%40qubes-os.org.

[qubes-devel] Whonix 17 templates available for Qubes OS 4.1

[Andrew David Wong]

Dear Qubes Community,

Until now, Whonix 17 has been available only on Qubes OS 4.2. Since [Whonix 16 
reached EOL (end-of-life) on 
2024-01-18](https://www.qubes-os.org/news/2023/12/22/whonix-16-approaching-eol/),
 this left users still on Qubes OS 4.1 without a supported way to use Whonix. 
In an effort to accommodate this group of users, the Whonix and Qubes teams 
have now made Whonix 17 available for Qubes OS 4.1.

There are two ways to upgrade to Whonix 17 on Qubes OS 4.1:

- *Recommended*: [Install fresh Whonix templates to replace the existing 
ones.](https://www.whonix.org/wiki/Qubes/Install) After you install the new 
templates, redo all desired template modifications and [switch everything that 
was set to the old templates to the new 
templates](https://www.qubes-os.org/doc/templates/#switching).

- *Advanced*: Perform an [in-place upgrade from Whonix 16 to Whonix 
17](https://www.whonix.org/wiki/Release_Upgrade_16_to_17). This option will 
preserve any modifications you've made to the templates, *but it may be more 
complicated for less experienced users.*

If you wish, you also still have the option of performing a [clean 
installation](https://www.qubes-os.org/doc/installation-guide/) of [Qubes OS 
4.2.0](https://www.qubes-os.org/news/2023/12/18/qubes-os-4-2-0-has-been-released/),
 which comes with Whonix 17 templates preinstalled (if selected during 
installation).


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2024/02/05/whonix-17-templates-available-for-qubes-os-4-1/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/a7c340e7-a17d-449b-afad-8e60294d540d%40qubes-os.org.

[qubes-devel] XSAs released on 2024-01-30

[Andrew David Wong]

Dear Qubes Community,

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*.

## XSAs that DO affect the security of Qubes OS

The following XSAs *do affect* the security of Qubes OS:

- [XSA-449](https://xenbits.xen.org/xsa/advisory-449.html)
  - See [QSB-100](https://www.qubes-os.org/news/2024/01/30/qsb-100/).

## 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-450](https://xenbits.xen.org/xsa/advisory-450.html)
  - Affects only builds with HVM support disabled

## 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2024/02/05/xsas-released-on-2024-01-30/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/cc4bd956-3697-4c60-96d3-f08200e08edd%40qubes-os.org.

[qubes-devel] XSAs released on 2024-01-22

[Andrew David Wong]

Dear Qubes Community,

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*.

## 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-448](https://xenbits.xen.org/xsa/advisory-448.html)
  - Denial of service (DoS) only

## 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2024/02/05/xsas-released-on-2024-01-22/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/e0551668-8386-4abf-bf48-521d06185670%40qubes-os.org.

[qubes-devel] QSB-099: Qrexec policy leak via policy.RegisterArgument service

[Andrew David Wong]

ferent 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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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
   ```

7. Verify signed Git tags.

   ```shell_session
   $ 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.

8. Verify PGP signature

[qubes-devel] The Star Labs StarBook is Qubes-certified!

[Andrew David Wong]

Dear Qubes Community,

It is our pleasure to announce that the [Star Labs 
StarBook](https://starlabs.systems/pages/starbook) is [officially 
certified](https://www.qubes-os.org/doc/certified-hardware/) for Qubes OS 
Release 4!

## The Star Labs StarBook

The [Star Labs StarBook](https://starlabs.systems/pages/starbook) is a 14-inch 
laptop featuring open-source coreboot and EDK II firmware. In addition, the 
StarBook is currently the *only* Qubes-certified computer with out-of-the-box 
support for `qubes-fwupdmgr`, a new feature in Qubes OS 4.2 that allows Qubes 
OS to securely update the computer's firmware.

[![Photo of Star Labs 
StarBook](https://www.qubes-os.org/attachment/site/starlabs-starbook.png)](https://starlabs.systems/pages/starbook)

The Qubes developers have tested and certified the following StarBook 
configuration options for Qubes OS 4.X:

| Component| Qubes-certified options  |
|  |  |
| Processor| 13th Generation Intel Core i3-1315U or i7-1360P  |
| Memory   | 8 GB, 16 GB, 32 GB, or 64 GB RAM |
| Storage  | 512 GB, 1 TB, or 2 TB SSD|
| Graphics | Intel (integrated graphics)  |
| Networking   | Intel Wi-Fi 6 AX210 (no built-in wired Ethernet) |
| Firmware | coreboot 8.97 (2023-10-03)   |
| Operating system | Qubes OS (pre-installation optional) |

[![Photo of Star Labs 
StarBook](https://www.qubes-os.org/attachment/posts/starlabs-starbook_top.png)](https://starlabs.systems/pages/starbook)

The StarBook features a true matte 14-inch IPS display at 1920x1080 full HD 
resolution with 400cd/m² of brightness, 178° viewing angles, and a 180° hinge. 
The backlit keyboard is available in US English, UK English, French, German, 
Nordic, and Spanish layouts.

[![Photo of Star Labs 
StarBook](https://www.qubes-os.org/attachment/posts/starlabs-starbook_side.png)](https://starlabs.systems/pages/starbook)

The StarBook includes four USB ports (1x USB-C with Thunderbolt 4, 2x USB 3.0, 
and 1x USB 2.0), one HDMI port, a microSD slot, an audio input/output combo 
jack, and a DC jack for charging. For more information, see the official [Star 
Labs StarBook](https://starlabs.systems/pages/starbook) page.

[![Photo of Star Labs 
StarBook](https://www.qubes-os.org/attachment/posts/starlabs-starbook_back.png)](https://starlabs.systems/pages/starbook)

## Special note regarding the need for `kernel-latest` on Qubes OS 4.1

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. If you purchase a StarBook with Qubes OS 4.2 
preinstalled, you don't have to worry about this, as Qubes OS 4.2 is confirmed 
to work with the default kernel option and does not require `kernel-latest`. 
However, if you plan to install Qubes OS 4.1 on the StarBook, please be aware 
that you will have to select this non-default option.

## About Star Labs

In short, we're just a bunch of geeks. Back in 2016, Star Labs was formed in a 
pub. We all depended on using Linux, all with different laptops and all with 
different complaints about them. It always perplexed us that a laptop had never 
been made specifically for Linux. Whilst many had been "converted" to run Linux 
- they seldom offered the experience that macOS and Windows users had. So, 
after a few pints, we decided to make one. [Read the full story on the Star 
Labs website.](https://us.starlabs.systems/pages/about-us)

## 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 

[qubes-devel] Whonix 16 approaching EOL

[Andrew David Wong]

Dear Qubes Community,

Whonix 16 is currently 
[scheduled](https://www.whonix.org/wiki/About#Qubes_Hosts) to reach EOL 
(end-of-life) on 2024-01-18. We strongly recommend that all Whonix users 
upgrade to Whonix 17 before then. For more information, see [Upgrading to avoid 
EOL](https://www.qubes-os.org/doc/how-to-update/#upgrading-to-avoid-eol). 
Please note that Whonix 17 is available only on Qubes OS 4.2.

There are three ways to upgrade to Whonix 17:

- *Recommended*: Perform a [clean 
installation](https://www.qubes-os.org/doc/installation-guide/) of [Qubes OS 
4.2.0](https://www.qubes-os.org/news/2023/12/18/qubes-os-4-2-0-has-been-released/),
 which comes with Whonix 17 templates preinstalled (if selected during 
installation).

- *Recommended*: [Install fresh Whonix templates to replace the existing 
ones.](https://www.whonix.org/wiki/Qubes/Install) After you install the new 
templates, redo all desired template modifications and [switch everything that 
was set to the old templates to the new 
templates](https://www.qubes-os.org/doc/templates/#switching).

- *Advanced*: Perform an [in-place upgrade from Whonix 16 to Whonix 
17](https://www.whonix.org/wiki/Release_Upgrade_16_to_17). This option will 
preserve any modifications you've made to the templates, *but it may be more 
complicated for less experienced users.*


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/12/22/whonix-16-approaching-eol/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/75e1a980-1fb5-4b19-b59c-8de642e5707d%40qubes-os.org.

[qubes-devel] Qubes OS 4.2.0 has been released!

[Andrew David Wong]

Dear Qubes Community,

Qubes OS 4.2.0 brings a host of new features, major improvements, and numerous 
bug fixes. 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.

## What's new in Qubes OS 4.2.0?

- Dom0 upgraded to Fedora 37 
([#6982](https://github.com/QubesOS/qubes-issues/issues/6982))
- Xen upgraded to version 4.17
- Default Debian template upgraded to Debian 12
- Default Fedora and Debian templates use Xfce instead of GNOME 
([#7784](https://github.com/QubesOS/qubes-issues/issues/7784))
- SELinux support in Fedora templates 
([#4239](https://github.com/QubesOS/qubes-issues/issues/4239))
- Several GUI applications rewritten, including:
  - Applications Menu (also available as preview in R4.1) 
([#6665](https://github.com/QubesOS/qubes-issues/issues/6665)), 
([#5677](https://github.com/QubesOS/qubes-issues/issues/5677))
  - Qubes Global Settings 
([#6898](https://github.com/QubesOS/qubes-issues/issues/6898))
  - Create New Qube
  - Qubes Update ([#7443](https://github.com/QubesOS/qubes-issues/issues/7443))
- Unified `grub.cfg` location for both UEFI and legacy boot 
([#7985](https://github.com/QubesOS/qubes-issues/issues/7985))
- PipeWire support 
([#6358](https://github.com/QubesOS/qubes-issues/issues/6358))
- fwupd integration for firmware updates 
([#4855](https://github.com/QubesOS/qubes-issues/issues/4855))
- Optional automatic clipboard clearing 
([#3415](https://github.com/QubesOS/qubes-issues/issues/3415))
- Official packages built using Qubes Builder v2 
([#6486](https://github.com/QubesOS/qubes-issues/issues/6486))
- Split GPG management in Qubes Global Settings
- Qrexec services use new qrexec policy format by default (but old format is 
still supported) ([#8000](https://github.com/QubesOS/qubes-issues/issues/8000))

For further details, see the [Qubes 4.2 release 
notes](https://www.qubes-os.org/doc/releases/4.2/release-notes/) and the [full 
list of issues completed for Qubes 
4.2](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+is%3Aclosed+reason%3Acompleted+milestone%3A%22Release+4.2%22+-label%3A%22R%3A+cannot+reproduce%22+-label%3A%22R%3A+declined%22+-label%3A%22R%3A+duplicate%22+-label%3A%22R%3A+not+applicable%22+-label%3A%22R%3A+self-closed%22+-label%3A%22R%3A+upstream+issue%22+).

## Known issues in Qubes OS 4.2.0

DomU firewalls have completely switched to nftables. Users should add their 
custom rules to the `custom-input` and `custom-forward` chains. (For more 
information, see issues 
[#5031](https://github.com/QubesOS/qubes-issues/issues/5031) and 
[#6062](https://github.com/QubesOS/qubes-issues/issues/6062).)

Also see the [full list of open bug reports affecting Qubes 
4.2](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+label%3Aaffects-4.2+label%3A%22T%3A+bug%22+is%3Aopen).

We strongly recommend [updating Qubes 
OS](https://www.qubes-os.org/doc/how-to-update/) immediately after installation 
in order to apply all available bug fixes.

## How to get Qubes OS 4.2.0

- If you don't have Qubes OS installed, or if you're currently on Qubes 4.0 or 
earlier, follow the [installation 
guide](https://www.qubes-os.org/doc/installation-guide/).
- If you're currently on Qubes 4.1, learn [how to upgrade to Qubes 
4.2](https://www.qubes-os.org/doc/upgrade/4.2/).
- If you're currently on a Qubes 4.2 release candidate (RC), [update 
normally](https://www.qubes-os.org/doc/how-to-update/).

In all cases, we strongly recommend [making a full 
backup](https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/) 
beforehand.

## Reminder: new release signing key for Qubes 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 

[qubes-devel] QSB-098: CPU microcode updates not loaded with dom0 kernel version 6.6.x

[Andrew David Wong]

thod 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. For more 
information, see [How to import and authenticate the Qubes Master Signing 
Key](https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-the-qubes-master-signing-key).

   *Tip*: After you have authenticated the QMSK out-of-band to your 
satisfaction, record the QMSK fingerprint in a safe place (or several) so that 
you don't have to repeat this step in the future.

4. Once you are satisfied that you have the genuine QMSK, set its trust level 
to 5 ("ultimate"), then quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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
  

[qubes-devel] XSAs released on 2023-12-12

[Andrew David Wong]

Dear Qubes Community,

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*.

## 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-447](https://xenbits.xen.org/xsa/advisory-447.html)
  - Qubes OS does not support ARM.

## 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/12/12/xsas-released-on-2023-12-12/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/aa81e468-6e1c-4343-acaa-df59cc3e8d3a%40qubes-os.org.

[qubes-devel] Qubes Canary 037

[Andrew David Wong]

 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. For more 
information, see [How to import and authenticate the Qubes Master Signing 
Key](https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-the-qubes-master-signing-key).

   *Tip*: After you have authenticated the QMSK out-of-band to your 
satisfaction, record the QMSK fingerprint in a safe place (or several) so that 
you don't have to repeat this step in the future.

4. Once you are satisfied that you have the genuine QMSK, set its trust level 
to 5 ("ultimate"), then quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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: I

[qubes-devel] Qubes OS 4.2.0-rc5 is available for testing

[Andrew David Wong]

Dear Qubes Community,

We're pleased to announce that the fifth [release candidate 
(RC)](#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. For 
more information about the changes included in this version, see the [Qubes OS 
4.2.0 release notes](https://www.qubes-os.org/doc/releases/4.2/release-notes/) 
and the [full list of bugs affecting Qubes 4.2 that have been 
fixed](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+is%3Aclosed+reason%3Acompleted+label%3Aaffects-4.2+label%3A%22T%3A+bug%22+-label%3A%22R%3A+cannot+reproduce%22+-label%3A%22R%3A+declined%22+-label%3A%22R%3A+duplicate%22+-label%3A%22R%3A+not+applicable%22+-label%3A%22R%3A+self-closed%22+-label%3A%22R%3A+upstream+issue%22).

## 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. Here is 
the latest update:

At this point, we are hopeful that RC5 will be the final RC.

## Testing Qubes 4.2.0-rc5

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-rc5

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 

[qubes-devel] QSB-097: "Reptar" Intel redundant prefix vulnerability

[Andrew David Wong]

: 427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494
   ```

3. *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. For more 
information, see [How to import and authenticate the Qubes Master Signing 
Key](https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-the-qubes-master-signing-key).

   *Tip*: After you have authenticated the QMSK out-of-band to your 
satisfaction, record the QMSK fingerprint in a safe place (or several) so that 
you don't have to repeat this step in the future.

4. Once you are satisfied that you have the genuine QMSK, set its trust level 
to 5 ("ultimate"), then quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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: pub

[qubes-devel] XSAs released on 2023-11-14

[Andrew David Wong]

Dear Qubes Community,

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* by at least one of these XSAs.

## XSAs that DO affect the security of Qubes OS

The following XSAs *do affect* the security of Qubes OS:

- [XSA-446](https://xenbits.xen.org/xsa/advisory-446.html)
  - For more information, see 
[QSB-096](https://www.qubes-os.org/news/2023/11/14/qsb-096/).

## 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-445](https://xenbits.xen.org/xsa/advisory-445.html)
  - Qubes OS uses only "basic" quarantine mode.

## 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/11/14/xsas-released-on-2023-11-14/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/a6750749-011a-4bbc-be8c-c5f1963c59b9%40qubes-os.org.

[qubes-devel] QSB-096: BTC/SRSO fixes not fully effective (XSA-446)

[Andrew David Wong]

tures/#how-to-import-and-authenticate-the-qubes-master-signing-key).

   *Tip*: After you have authenticated the QMSK out-of-band to your 
satisfaction, record the QMSK fingerprint in a safe place (or several) so that 
you don't have to repeat this step in the future.

4. Once you are satisfied that you have the genuine QMSK, set its trust level 
to 5 ("ultimate"), then quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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
   ```

7. Verify signed Git tags.

[qubes-devel] Re: Changing the way we use milestones in the issue tracker

[Andrew David Wong]

On 8/8/23 11:06 PM, Andrew David Wong wrote:
> ## Summary
> 
> Issues will no longer be assigned to milestones by default. Most issues won't 
> have milestones. The Qubes developers will manually assign issues to 
> milestones. We'll use labels like "affects-4.1" and "affects-4.2" to 
> represent affected releases instead of milestones. The "Release TBD" and 
> "Non-release" milestones are being phased out, as are milestones of the form 
> "Release X.Y updates." Read on for a more detailed explanation.
> 
> [...]

Okay, after trying this new system for a while, I see that there are still some 
problems:

1. Milestones are still confusing. It's still not intuitive to some people what 
it means for an issue to be on a milestone and when an issue should be added to 
a milestone.

2. Adding issues to milestones doesn't fit into the dev workflow. For some 
devs, adding the issues they plan to do to a milestone doesn't come naturally. 
Others add issues to milestones before checking with the release manager. I 
often end up having to remove issues from milestones that aren't approved and 
having to add closed issues to milestones that should have been there. All of 
this tells me that the milestone system isn't working well. That's okay. If it 
doesn't come naturally, it shouldn't be forced. This system is designed to help 
the devs, so we should tailor it to their workflow rather than the other way 
around.

3. Milestones are too similar to `affects-*` labels. The intended distinction 
is: `affects-*` = affects that release. Milestone = plan to do for that 
release. The former seems to be a lot more intuitive for people than the latter.

So, what should we do about it? I propose we just get rid of milestones. Stop 
using them completely. (Just because a feature exists doesn't mean we have to 
use it.)

What will we lose if we stop using milestones? From my perspective, not much:

4. It would be harder for the general public to see "how much work remains" 
before a given release. However, given (2) above, milestones aren't accurately 
representing this in the first place, so there's no real loss here.

5. It would be harder for us to see which issues we have done for a given 
release. For example, I used a search of all completed issues on the 4.2 
milestone since RC3 to come up with the list of changes between RC3 and RC4. 
But there are potentially better ways to handle this. For example, we could 
just have an additional label like `merged-for-4.2` or something, which might 
be more intuitively understandable.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/680decf2-69bf-4b08-9550-52ad48d20fac%40qubes-os.org.

[qubes-devel] Qubes OS 4.2.0-rc4 is available for testing

[Andrew David Wong]

Dear Qubes Community,

We're pleased to announce that the fourth [release candidate 
(RC)](#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.

## Main changes from RC3 to RC4

- Fixed: ["qvm-move fails, deletes origin file anyway" 
(#8516)](https://github.com/QubesOS/qubes-issues/issues/8516)
- Fixed: ["`90-default.policy` not upgraded after in-place upgrade from 4.1 to 
4.2" (#8458)](https://github.com/QubesOS/qubes-issues/issues/8458)
- Fixed: ["Qube Manager freezes while opening settings" 
(#8387)](https://github.com/QubesOS/qubes-issues/issues/8387)
- Fixed: ["Error when attempting to update dom0 in the Qube Manager" 
(#8117)](https://github.com/QubesOS/qubes-issues/issues/8117)
- Fixed: ["XScreenSaver & XScreenSaver Settings not opening window" 
(#8266)](https://github.com/QubesOS/qubes-issues/issues/8266)
- Fixed: ["Setting no-strict-reset option via salt on already attached devices 
doesn't work" (#8514)](https://github.com/QubesOS/qubes-issues/issues/8514)
- Fixed: ["qvm-copy-to-vm incorrect progress report" 
(#1519)](https://github.com/QubesOS/qubes-issues/issues/1519)
- Fixed: ["qubes-video-companion-receiver missing dependency on acl package" 
(#8426)](https://github.com/QubesOS/qubes-issues/issues/8426)
- Fixed: ["OpenBSD 7.3 ISO doesn't boot anymore" 
(#8502)](https://github.com/QubesOS/qubes-issues/issues/8502)
- Fixed: ["Kernel compile bogs down rest of system" 
(#8176)](https://github.com/QubesOS/qubes-issues/issues/8176)
- Fixed: ["rpm-oxide makes unjustified assumptions about RPM ABI" 
(#8522)](https://github.com/QubesOS/qubes-issues/issues/8522)
- Fixed: ["yk-auth YubiKey PAM script incorrectly expects \0 to be appended to 
hash" (#8517)](https://github.com/QubesOS/qubes-issues/issues/8517)
- Fixed: ["Qubes Application Menu isn't updated when using salt to modify 
menu-items" (#8494)](https://github.com/QubesOS/qubes-issues/issues/8494)
- Fixed: ["Different values for `menu-items` and `default-menu-items` are not 
preserved when cloning templates" 
(#8518)](https://github.com/QubesOS/qubes-issues/issues/8518)
- Fixed: ["Fix handling of menu items in GUI VM" 
(#8528)](https://github.com/QubesOS/qubes-issues/issues/8528)
- Fixed: ["Firefox does not start on 4.2-rc3 after upgrading template" 
(#8571)](https://github.com/QubesOS/qubes-issues/issues/8571)
- Fixed: ["Qubes R4.2.0-rc2 Qubes OS Global Config tool not see qubes-u2f 
installed in sys-usb" 
(#8463)](https://github.com/QubesOS/qubes-issues/issues/8463)
- Fixed: ["global config: policy rules for U2F incorrectly assume wildcard 
argument" (#8525)](https://github.com/QubesOS/qubes-issues/issues/8525)
- Fixed: ["Pipewire on some systems causes a lot of underruns" 
(#8576)](https://github.com/QubesOS/qubes-issues/issues/8576)
- Fixed: ["Listing PCI devices breaks when there is some with non- PCI 
domain" (#6932)](https://github.com/QubesOS/qubes-issues/issues/6932)
- Done: ["Prepare R4.1 -> R4.2 upgrade tool" 
(#7832)](https://github.com/QubesOS/qubes-issues/issues/7832)
- Done: ["Phase out legacy qrexec policy files" 
(#8000)](https://github.com/QubesOS/qubes-issues/issues/8000)
- Done: ["Better qrexec service configuration format" 
(#8153)](https://github.com/QubesOS/qubes-issues/issues/8153)
- Done: ["QRexec services should be able to specify the user they must run as" 
(#6354)](https://github.com/QubesOS/qubes-issues/issues/6354)
- Done: ["Qube Manager: Enable the 'restart qube' button for named disposables" 
(#8382)](https://github.com/QubesOS/qubes-issues/issues/8382)
- Done: ["Utilize memory hotplug to add VM memory by qmemman" 
(#7956)](https://github.com/QubesOS/qubes-issues/issues/7956)

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. Here is 
the latest update:

At this point, we are hopeful 

[qubes-devel] Fedora 37 approaching EOL

[Andrew David Wong]

Dear Qubes Community,

Fedora 37 is currently 
[scheduled](https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html) 
to reach EOL ([end-of-life](https://fedoraproject.org/wiki/End_of_life)) on 
2023-11-21. We strongly recommend that all users 
[upgrade](https://www.qubes-os.org/doc/templates/fedora/#upgrading) their 
Fedora templates and standalones to [Fedora 
38](https://www.qubes-os.org/news/2023/05/26/fedora-38-templates-available/) 
before then. For more information, see [Upgrading to avoid 
EOL](https://www.qubes-os.org/doc/how-to-update/#upgrading-to-avoid-eol).

There are two ways to upgrade your template to a new Fedora release:

- *Recommended*: [Install a fresh template to replace the existing 
one.](https://www.qubes-os.org/doc/templates/fedora/#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. To see a log of package manager actions, 
open a terminal in the old Fedora template and use the `dnf history` command.

- *Advanced*: [Perform an in-place upgrade of an existing Fedora 
template.](https://www.qubes-os.org/doc/templates/fedora/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)).


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/10/12/fedora-37-approaching-eol/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/24a1cbd8-c6e8-46fb-839b-57af7a3086f2%40qubes-os.org.

[qubes-devel] XSAs released on 2023-10-10

[Andrew David Wong]

Dear Qubes Community,

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-442](https://xenbits.xen.org/xsa/advisory-442.html)
  - Please see [QSB-095](https://www.qubes-os.org/news/2023/10/10/qsb-095/) 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:

- [XSA-440](https://xenbits.xen.org/xsa/advisory-440.html)
  - Denial of service (DoS) only
- [XSA-441](https://xenbits.xen.org/xsa/advisory-441.html)
  - Denial of service (DoS) only
- [XSA-443](https://xenbits.xen.org/xsa/advisory-443.html)
  - Qubes OS does not use pygrub.
- [XSA-444](https://xenbits.xen.org/xsa/advisory-444.html)
  - Denial of service (DoS) only

## 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/10/10/xsas-released-on-2023-10-10/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/7cdb04e5-735c-4eb9-bdf5-9f77b48d1127%40qubes-os.org.

[qubes-devel] QSB-095: Missing IOMMU TLB flushing on x86 AMD systems

[Andrew David Wong]

n quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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
   ```

7. Verify signed Git tags.

   ```shell_session
   $ 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 2D1771FE4D767EDC76B089FAD655A4

[qubes-devel] XSAs released on 2023-09-25

[Andrew David Wong]

Dear Qubes Community,

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-439](https://xenbits.xen.org/xsa/advisory-439.html)
  - Please see [QSB-094](https://www.qubes-os.org/news/2023/09/27/qsb-094/) 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/09/27/xsas-released-on-2023-09-25/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/5c334e27-25fb-4b75-16da-def3dbf8a298%40qubes-os.org.

[qubes-devel] XSAs released on 2023-09-20

[Andrew David Wong]

Dear Qubes Community,

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-438](https://xenbits.xen.org/xsa/advisory-438.html)
  - Shadow paging is not built-in.

## 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/09/20/xsas-released-on-2023-09-20/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/6fc17a42-23b1-dc44-1886-48c6c0e7e174%40qubes-os.org.

[qubes-devel] Tickets for Qubes OS Summit 2023 are now available!

[Andrew David Wong]

Dear Qubes Community,

The following announcement is from 3mdeb:

[![Tickets are available for Qubes OS Summit 
2023](https://www.qubes-os.org/attachment/posts/qubes-os-summit-2023-tickets.png)](https://www.qubes-os.org/attachment/posts/qubes-os-summit-2023-tickets.png)

We have options for everyone:

- Virtual Qubes Pass for online attendees
- On-site Qubes Pass for those ready to join us in Berlin

Number of the On-site Qubes Passes is limited, so book only if you will be 
there. Both tickets are free. Read more at: 


Have insights to share?   
Want to be a sponsor? 


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/09/19/tickets-for-qubes-os-summit-2023-now-available/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/67264932-83a1-a0f8-390a-a117cfc5423a%40qubes-os.org.

[qubes-devel] Qubes Canary 036

[Andrew David Wong]

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.

4. Once you are satisfied that you have the genuine QMSK, set its trust level 
to 5 ("ultimate"), then quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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

[qubes-devel] Re: The NitroPC Pro is Qubes-certified!

[Andrew David Wong]

On 9/6/23 10:57 AM, Andrew David Wong wrote:
> Dear Qubes Community,
> 
> 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 Subscription guarantees 
> continuous firmware development and fast firmware updates. 
> 
> [![Photo of NitroPC 
> Pro](https://www.qubes-os.org/attachment/posts/nitropc-pro.jpg)](https://shop.nitrokey.com/shop/product/nitropc-pro-523)
> 
> Here's a summary of the main component options available for this mid-tower 
> desktop PC:
> 
> | Component| Options  
> |
> |- | 
>  |
> | Motherboard  | MSI PRO Z690-A DDR5 (Wi-Fi optional) 
> |
> | Processor| 12th Generation Intel Core i5-12600K or 
> i9-12900K|
> | Memory   | 16 GB to 128 GB DDR5 
> |
> | NVMe storage (optional)  | Up to two NVMe PCIe 4.0 x4 SSDs, up to 2 TB 
> each |
> | SATA storage (optional)  | Up to two SATA SSDs, up to 7.68 TB each  
> |
> | 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 
> |
> 
> [...]
> 

*Important addendum*: As indicated in the table above, when configuring your 
NitroPC Pro on the Nitrokey website, there is an option for a discrete graphics 
card (e.g., Nvidia GeForce RTX 4070 or 4090) in addition to integrated graphics 
(e.g., Intel UHD 770, which is always included because it is physically built 
into the CPU). Please note that NitroPC Pro configurations that include 
discrete graphics cards are *not* Qubes-certified. The only NitroPC Pro 
configurations that are Qubes-certified are those that contain *only* 
integrated graphics.

> 
> This announcement is also available on the Qubes website:
> https://www.qubes-os.org/news/2023/09/06/nitropc-pro-qubes-certified/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/43000146-1ac7-8419-0e9f-9565f970db97%40qubes-os.org.

[qubes-devel] XSAs released on 2023-09-05

[Andrew David Wong]

Dear Qubes Community,

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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/09/05/xsas-released-on-2023-09-05/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/39fa7f7b-7920-c77e-18e5-4ffac09ea7a2%40qubes-os.org.

[qubes-devel] Qubes OS 4.2.0-rc3 is available for testing

[Andrew David Wong]

Dear Qubes Community,

We're pleased to announce that the third [release candidate 
(RC)](#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

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 

[qubes-devel] Qubes OS 4.2.0-rc2 is available for testing

[Andrew David Wong]

Dear Qubes Community,

We're pleased to announce that the second [release 
candidate](#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](#whats-new-in-qubes-420-rc2).

## 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 

[qubes-devel] Re: Debian 12 templates available

[Andrew David Wong]

> [supported template releases]

Link: https://www.qubes-os.org/doc/supported-releases/#templates

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/d7c83cfc-b52c-3edb-4edd-1b174d658fb9%40qubes-os.org.

[qubes-devel] Debian 12 templates available

[Andrew David Wong]

Dear Qubes Community,

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]. 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)).


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/08/27/debian-12-templates-available/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/dd4c2c8f-a747-be3c-63b4-5eacf2365dc8%40qubes-os.org.

[qubes-devel] CORRECTION: Qubes OS Summit 2023: OCTOBER 6-8 in Berlin

[Andrew David Wong]

Dear Qubes Community,

_My apologies for the incorrect subject line in my previous email. The correct 
month is OCTOBER, not September!_

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: 

[![Qubes OS Summit 2023 
poster](https://www.qubes-os.org/attachment/posts/qubes-os-summit-2023.png)](https://www.qubes-os.org/attachment/posts/qubes-os-summit-2023.png)


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/08/25/qubes-os-summit-2023/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/5d1e397d-9d25-d6a7-9be9-9a30a9d2db81%40qubes-os.org.

[qubes-devel] Qubes OS Summit 2023: September 6-8 in Berlin

[Andrew David Wong]

Dear Qubes Community,

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: 

[![Qubes OS Summit 2023 
poster](https://www.qubes-os.org/attachment/posts/qubes-os-summit-2023.png)](https://www.qubes-os.org/attachment/posts/qubes-os-summit-2023.png)


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/08/25/qubes-os-summit-2023/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/8bdb30a5-93cb-fb09-5d60-d62005cf37e0%40qubes-os.org.

Re: [qubes-devel] Changing the way we use milestones in the issue tracker

[Andrew David Wong]

On 8/10/23 3:45 AM, jma...@tutanota.com wrote:
> Aug 10, 2023, 07:18 by a...@qubes-os.org:
> 
>> On 8/9/23 8:22 AM, jmake2 via qubes-devel wrote:
>>
>>> [...]
>>> Well, I see Marek's point. I agree, that if the problem happens to be 
>>> upstream it should be closed with not-our-bug or something. And it happens 
>>> this way now quite often.
>>> But note that Qubes OS users search for their issue and it's better they 
>>> find closed ticket than no ticket at all. And when people report, most of 
>>> them are not able to reliably check what happens in the original Fedora 
>>> that they do not have. That is why all major GNU/Linux distos still keep 
>>> issues in software that is made by third-party developers, it is a common 
>>> practice after all.
>>>
>>
>> If you really want to open issues that you know are not Qubes bugs in the 
>> Qubes issue tracker for this reason, I suppose you can just make it clear 
>> when you open such issues that they should be closed as "not our bug," and 
>> I'll just immediately close them with that resolution. Seems a bit odd to 
>> me, but I suppose it's relatively harmless.
>>
>>> [...]
>>> One the other hand, if the issue is related to f38 only, does it affect 
>>> R4.2? Currently it does, and it also does affect R4.1, but what will happen 
>>> when f39 comes out and f38 is EOL? How will it be removed from the 
>>> affects-4.2 group? Only manually for each of them.
>>>
>>
>> In that scenario, we would simply close that F38-specific issue, since F38 
>> has reached EOL. We wouldn't have to worry about removing the "affects-4.2" 
>> label, because the issue would be closed now anyway. (I think it's fine to 
>> have the "affects-4.2" label on a closed issue that once affected 4.2.)
>>
> Well, maybe I am wrong, maybe it is not a good idea to track third-party 
> issues that affect Qubes OS (even closed). I do not know.
> 
> GNU/Linux distributions do it, but most of them are bigger, not a problem for 
> them to allow such issues.
> 

We also allow them, but we close them as "not our bug" because that's what they 
are, and because they're not actionable for us.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/1abbd6a1-7f1b-4364-2e31-f25f3737e0be%40qubes-os.org.

Re: [qubes-devel] Changing the way we use milestones in the issue tracker

[Andrew David Wong]

On 8/9/23 8:22 AM, jmake2 via qubes-devel wrote:
> [...]
> Well, I see Marek's point. I agree, that if the problem happens to be 
> upstream it should be closed with not-our-bug or something. And it happens 
> this way now quite often.
> But note that Qubes OS users search for their issue and it's better they find 
> closed ticket than no ticket at all. And when people report, most of them are 
> not able to reliably check what happens in the original Fedora that they do 
> not have. That is why all major GNU/Linux distos still keep issues in 
> software that is made by third-party developers, it is a common practice 
> after all.
> 

If you really want to open issues that you know are not Qubes bugs in the Qubes 
issue tracker for this reason, I suppose you can just make it clear when you 
open such issues that they should be closed as "not our bug," and I'll just 
immediately close them with that resolution. Seems a bit odd to me, but I 
suppose it's relatively harmless.

> [...]
> One the other hand, if the issue is related to f38 only, does it affect R4.2? 
> Currently it does, and it also does affect R4.1, but what will happen when 
> f39 comes out and f38 is EOL? How will it be removed from the affects-4.2 
> group? Only manually for each of them.
> 

In that scenario, we would simply close that F38-specific issue, since F38 has 
reached EOL. We wouldn't have to worry about removing the "affects-4.2" label, 
because the issue would be closed now anyway. (I think it's fine to have the 
"affects-4.2" label on a closed issue that once affected 4.2.)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/bdc42c65-17c2-da3a-280c-c99aa4891c29%40qubes-os.org.

Re: [qubes-devel] Changing the way we use milestones in the issue tracker

[Andrew David Wong]

On 8/9/23 7:13 AM, Marek Marczykowski-Górecki wrote:
> On Wed, Aug 09, 2023 at 03:36:03PM +0200, jmake2 via qubes-devel wrote:
>> I think that the new tag/milestone system is way better and logical, well 
>> done. And arguments are quite convincing to me.
> 
>> I would like to add an idea about official templates. We know that there are 
>> bugs in the templates, including the latest one fedora-38 or 
>> fedora-38-minimal. Maybe you can consider tags (labels) in the same manner 
>> as with released, e.g.: `affects-f37`, `affects-f38`, `affects-f38min`, 
>> `affects-d11` (for Debian) and etc.
>> The reason - bug or problem in the official template is the same for R4.1 
>> and R4.2 (or am I wrong?) and, thus, is not a release-version-depended bug.
> 
> Generally, we don't track non-qubes bugs in our tracker (there are
> exceptions, but still). And qubes packages are specific to qubes release
> in most cases (so, a fix in one release doesn't make it automatically
> fixed in another). So, such label would still need to be combined with
> affects-4.1 or similar. We also have "C: Fedora"/"C: Debian" labels
> which serve similar purpose (but without specific version).
> So, generally an issue that would affect just a single version of a
> template (for example f37 but not f38) is either:
>  - an issue in a software [version] specific to that template, not to
>qubes - in which case it should be tracked in that distribution
>tracker
>  - a compatibility issue in qubes package connected with specific
>template version (like, some qubes package misbehave when using
>libfoo version 2.0, but works fine with version 1.0)
> 
> The latter case might warrant label specific to template version, but
> would still require also a label specific to qubes version. It might be
> useful for testing template versions (like debian-12 right now), but
> in that case we encourage to simply mention template-tracking issue, so
> it gets linked by github. As for bugs affecting only older template
> versions but not newer (so, they stop being relevant when said template
> goes EOL), I have an impression those are rare, but maybe I'm wrong?
> Andrew, do you think it's worth it? 
> 

Oh, my mistake. It sounds like templates are more Qubes-version-dependent than 
I realized. In that case, I think you're right that it may not be worth it, 
given we already track both Qubes release and general template type with 
existing labels.

>> When new release of official fedora template comes out it changes the 
>> situation every time: some new bugs are introduced, some are fixed without 
>> afford of the Team by Fedora/Debian guys. Tracking this could be useful.
> 
>> Templates also have EOL, which could lead to closing outdated inactive 
>> tickets in the same manner as with `affected-4.0` tags. And template's EOL 
>> is not directly connected to Qubes OS version but more with Fedora project 
>> and their EOL rules.
> 
> 
>> --
>> Best regards,
>> jamke
> 
> 
> 
>> Aug 9, 2023, 06:06 by a...@qubes-os.org:
> 
>>> ## Summary
>>>
>>> Issues will no longer be assigned to milestones by default. Most issues 
>>> won't have milestones. The Qubes developers will manually assign issues to 
>>> milestones. We'll use labels like "affects-4.1" and "affects-4.2" to 
>>> represent affected releases instead of milestones. The "Release TBD" and 
>>> "Non-release" milestones are being phased out, as are milestones of the 
>>> form "Release X.Y updates." Read on for a more detailed explanation.
>>>
>>> ## How milestones work right now
>>>
>>> Currently, our milestone guidelines are as follows:
>>>
>>> - Every issue should be assigned to *exactly one* milestone.
>>> - For *bug reports*, the milestone designates the *earliest supported 
>>> release* in which that bug is believed to exist.
>>> - For *enhancements* and *tasks*, the milestone indicates that the goal is 
>>> to implement or do that thing *in* or *for* that release.
>>>
>>> For example, if you were to report a bug that affects both 4.1 and 4.2 
>>> right now, it would be assigned to the "Release 4.1 updates" milestone, 
>>> because 4.1 is the earliest supported release that the bug is believed to 
>>> affect. As another example, if you were to open an enhancement issue right 
>>> now, it would most likely be assigned to the "Release TBD" milestone, which 
>>> means something like, "This enhancement, if it is ever implemented, will be 
>>> implement in some Qubes release or other, but it has not yet been 
>>> determined which specific Qubes release that will be." If it were decided 
>>> that this enhancement would be implemented for 4.2, for example, then the 
>>> issue's milestone would be changed to "Release 4.2."
>>>
>>> ## Problems with the current system
>>>
>>> Some people find our current use of milestones to be counterintuitive. For 
>>> example, suppose that a bug is reported that affects both 4.1 and 4.2. The 
>>> Qubes devs decide that it's not too serious, so it's okay just to fix 

Re: [qubes-devel] Changing the way we use milestones in the issue tracker

[Andrew David Wong]

On 8/9/23 6:36 AM, jmake2 via qubes-devel wrote:
> I think that the new tag/milestone system is way better and logical, well 
> done. And arguments are quite convincing to me.
> 
> I would like to add an idea about official templates. We know that there are 
> bugs in the templates, including the latest one fedora-38 or 
> fedora-38-minimal. Maybe you can consider tags (labels) in the same manner as 
> with released, e.g.: `affects-f37`, `affects-f38`, `affects-f38min`, 
> `affects-d11` (for Debian) and etc.
> The reason - bug or problem in the official template is the same for R4.1 and 
> R4.2 (or am I wrong?) and, thus, is not a release-version-depended bug.
> 
> When new release of official fedora template comes out it changes the 
> situation every time: some new bugs are introduced, some are fixed without 
> afford of the Team by Fedora/Debian guys. Tracking this could be useful.
> 
> Templates also have EOL, which could lead to closing outdated inactive 
> tickets in the same manner as with `affected-4.0` tags. And template's EOL is 
> not directly connected to Qubes OS version but more with Fedora project and 
> their EOL rules.
> 
> 
> --
> Best regards,
> jamke
> 

Good point! I agree; it makes sense to track whether a bug affects a specific 
template version independently of the Qubes OS release on which that template 
happens to be used, especially when that template is supported on multiple 
Qubes OS releases.

(P.S. -- The convention on these mailing lists is to used interleaved or 
bottom-posting rather than top-posting.)

> 
> Aug 9, 2023, 06:06 by a...@qubes-os.org:
> 
>> ## Summary
>>
>> Issues will no longer be assigned to milestones by default. Most issues 
>> won't have milestones. The Qubes developers will manually assign issues to 
>> milestones. We'll use labels like "affects-4.1" and "affects-4.2" to 
>> represent affected releases instead of milestones. The "Release TBD" and 
>> "Non-release" milestones are being phased out, as are milestones of the form 
>> "Release X.Y updates." Read on for a more detailed explanation.
>>
>> ## How milestones work right now
>>
>> Currently, our milestone guidelines are as follows:
>>
>> - Every issue should be assigned to *exactly one* milestone.
>> - For *bug reports*, the milestone designates the *earliest supported 
>> release* in which that bug is believed to exist.
>> - For *enhancements* and *tasks*, the milestone indicates that the goal is 
>> to implement or do that thing *in* or *for* that release.
>>
>> For example, if you were to report a bug that affects both 4.1 and 4.2 right 
>> now, it would be assigned to the "Release 4.1 updates" milestone, because 
>> 4.1 is the earliest supported release that the bug is believed to affect. As 
>> another example, if you were to open an enhancement issue right now, it 
>> would most likely be assigned to the "Release TBD" milestone, which means 
>> something like, "This enhancement, if it is ever implemented, will be 
>> implement in some Qubes release or other, but it has not yet been determined 
>> which specific Qubes release that will be." If it were decided that this 
>> enhancement would be implemented for 4.2, for example, then the issue's 
>> milestone would be changed to "Release 4.2."
>>
>> ## Problems with the current system
>>
>> Some people find our current use of milestones to be counterintuitive. For 
>> example, suppose that a bug is reported that affects both 4.1 and 4.2. The 
>> Qubes devs decide that it's not too serious, so it's okay just to fix it in 
>> 4.2 and leave it be in 4.1. Some people have the intuition that the issue 
>> should be reassigned to the 4.2 milestone, since the devs just decided 
>> that's where it'll be fixed. However, under the current rules, that would be 
>> wrong, since the bug still affects 4.1, and 4.1 is the earliest affected 
>> supported release.
>>
>> Similarly, suppose that someone reported a bug against 4.0, but it's one of 
>> those "we'll get around to fixing it someday, maybe" sort of bugs. Some 
>> people would be tempted to assign this issue to the "Release TBD" milestone 
>> on the grounds that the plan is to fix it at some yet-to-be-determined point 
>> in the distant future. However, this would again be wrong under the current 
>> rules, since the milestone for a bug report is supposed to represent the 
>> earliest supported release in which the bug is believed to exist, which is 
>> 4.0.
>>
>> The current method also presents problems when it comes time to close old 
>> issues. As many of you have probably noticed, I recently closed a large 
>> number of issues that were on the "Release 4.0 updates" milestone, since 4.0 
>> reached EOL over one year ago, and those issues had not seen any activity in 
>> over a year. The problem arises when an issue affects more than one release. 
>> For example, there were some issues that affected both 4.0 and 4.1. In 
>> accordance with our milestone rules, those issues were assigned to the 4.0 

[qubes-devel] XSAs released on 2023-08-08

[Andrew David Wong]

Dear Qubes Community,

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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/08/09/xsas-released-on-2023-08-08/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/1977072f-92f4-40da-811e-953472551c73%40qubes-os.org.

[qubes-devel] QSB-093: Transient execution vulnerabilities in AMD and Intel CPUs

[Andrew David Wong]

ated
   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.)

2. 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.)

   ```shell_session
   $ 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
   ```

3. *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.

4. Once you are satisfied that you have the genuine QMSK, set its trust level 
to 5 ("ultimate"), then quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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

[qubes-devel] Changing the way we use milestones in the issue tracker

[Andrew David Wong]

## Summary

Issues will no longer be assigned to milestones by default. Most issues won't 
have milestones. The Qubes developers will manually assign issues to 
milestones. We'll use labels like "affects-4.1" and "affects-4.2" to represent 
affected releases instead of milestones. The "Release TBD" and "Non-release" 
milestones are being phased out, as are milestones of the form "Release X.Y 
updates." Read on for a more detailed explanation.

## How milestones work right now

Currently, our milestone guidelines are as follows:

- Every issue should be assigned to *exactly one* milestone.
- For *bug reports*, the milestone designates the *earliest supported release* 
in which that bug is believed to exist.
- For *enhancements* and *tasks*, the milestone indicates that the goal is to 
implement or do that thing *in* or *for* that release.

For example, if you were to report a bug that affects both 4.1 and 4.2 right 
now, it would be assigned to the "Release 4.1 updates" milestone, because 4.1 
is the earliest supported release that the bug is believed to affect. As 
another example, if you were to open an enhancement issue right now, it would 
most likely be assigned to the "Release TBD" milestone, which means something 
like, "This enhancement, if it is ever implemented, will be implement in some 
Qubes release or other, but it has not yet been determined which specific Qubes 
release that will be." If it were decided that this enhancement would be 
implemented for 4.2, for example, then the issue's milestone would be changed 
to "Release 4.2."

## Problems with the current system

Some people find our current use of milestones to be counterintuitive. For 
example, suppose that a bug is reported that affects both 4.1 and 4.2. The 
Qubes devs decide that it's not too serious, so it's okay just to fix it in 4.2 
and leave it be in 4.1. Some people have the intuition that the issue should be 
reassigned to the 4.2 milestone, since the devs just decided that's where it'll 
be fixed. However, under the current rules, that would be wrong, since the bug 
still affects 4.1, and 4.1 is the earliest affected supported release.

Similarly, suppose that someone reported a bug against 4.0, but it's one of 
those "we'll get around to fixing it someday, maybe" sort of bugs. Some people 
would be tempted to assign this issue to the "Release TBD" milestone on the 
grounds that the plan is to fix it at some yet-to-be-determined point in the 
distant future. However, this would again be wrong under the current rules, 
since the milestone for a bug report is supposed to represent the earliest 
supported release in which the bug is believed to exist, which is 4.0.

The current method also presents problems when it comes time to close old 
issues. As many of you have probably noticed, I recently closed a large number 
of issues that were on the "Release 4.0 updates" milestone, since 4.0 reached 
EOL over one year ago, and those issues had not seen any activity in over a 
year. The problem arises when an issue affects more than one release. For 
example, there were some issues that affected both 4.0 and 4.1. In accordance 
with our milestone rules, those issues were assigned to the 4.0 milestone. When 
it came time to bulk-close the old 4.0 issues, issues were closed even though 
they also affect 4.1, which is still supported. The fact that those issues also 
affect 4.1 wasn't represented in a label or milestone (just in a free-text 
comment), so I had no way to filter them out when performing the bulk close 
action.

Finally, each milestone has a progress indicator that shows the percentage of 
completed issues on that milestone, but this indicator isn't very useful when 
every issue that affects a given release gets assigned to that milestone, 
regardless of whether the devs actually plan to act on it. When every release 
ships with a partially-completed milestone, it becomes an unreliable indicator.

## Analyzing the nature of milestones

Let's step back for a moment and think about what milestones are and what 
purpose they're supposed to serve. An issue tracking system doesn't actually 
*have* to have milestones at all. They're an optional feature. All an issue 
tracking system really needs is a single type of "tag" functionality (what 
GitHub calls "labels"). You can re-create almost any other type of issue 
tracking functionality (including milestones) with just tags. From this 
perspective, GitHub's milestones are basically the same as labels, except for 
two distinctive features:

- Unlike labels, milestones are mutually exclusive. An issue can have an 
unlimited number of labels, but it can be assigned to at most one milestone.
- Unlike labels, milestones have progress indicators.

So, if we're going to use milestones, it makes sense to use them in a way that 
takes advantage of these distinctive features.

## How we plan to use milestones going forward

Issues will no longer immediately be assigned to milestones. 

[qubes-devel] QSB-092: Buffer overrun in Linux netback driver (XSA-432)

[Andrew David Wong]

ore ways to obtain the QMSK.)

2. 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.)

   ```shell_session
   $ 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
   ```

3. *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.

4. Once you are satisfied that you have the genuine QMSK, set its trust level 
to 5 ("ultimate"), then quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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 DC2F3678D272F2A

[qubes-devel] Update for QSB-090: Zenbleed (CVE-2023-20593, XSA-433)

[Andrew David Wong]

 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.

4. Once you are satisfied that you have the genuine QMSK, set its trust level 
to 5 ("ultimate"), then quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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 nu

[qubes-devel] XSAs released on 2023-08-01

[Andrew David Wong]

Dear Qubes Community,

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-436](https://xenbits.xen.org/xsa/advisory-436.html)
  - This affects only 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/08/01/xsas-released-on-2023-08-01/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/d78c1ed3-28ce-6134-1ad9-074cdc1f477d%40qubes-os.org.

[qubes-devel] QSB-091: Windows PV drivers potentially compromised

[Andrew David Wong]

: 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
   ```

3. *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.

4. Once you are satisfied that you have the genuine QMSK, set its trust level 
to 5 ("ultimate"), then quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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 &q

[qubes-devel] XSAs released on 2023-07-24

[Andrew David Wong]

Dear Qubes Community,

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-433](https://xenbits.xen.org/xsa/advisory-433.html)
  - See [QSB-090](https://www.qubes-os.org/news/2023/07/24/qsb-090/) 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/07/24/xsas-released-on-2023-07-24/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/e9bc749c-703f-8c92-7e41-52f5e118bfa8%40qubes-os.org.

[qubes-devel] QSB-090: Zenbleed (CVE-2023-20593, XSA-433)

[Andrew David Wong]

thod 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.

4. Once you are satisfied that you have the genuine QMSK, set its trust level 
to 5 ("ultimate"), then quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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

Re: [qubes-devel] Reconsider obligatory encryption for qvm-backup to make backups much smaller and more flexible

[Andrew David Wong]

On 7/12/23 8:47 AM, Metatron wrote:
> [...]
> 
> An additonal use case is that I occationaly build a qube for friends and
> then send to them, again the mandatory encryption is an annoyance. I
> could also imagine that at some point qubes users may even want to
> "publish" a qube publicly. 
> 
> [...]
> 

It's worth noting that every Qubes backup includes a qubes.xml file that lists 
all the qubes in the system at the time the backup was created regardless of 
whether those qubes were selected for inclusion in the backup. This is an 
intentional aspect of the design of qvm-backup[-restore], the goal of which is 
to preserve the system's data and configuration as well as possible, which 
requires the inclusion of data about the dependencies of each qube in the 
backup on other qubes. [1] There's an open issue for the development of a 
separate export tool intended for the specific use case you describe. [2]


[1] https://github.com/QubesOS/qubes-issues/issues/2645#issuecomment-281720735
[2] https://github.com/QubesOS/qubes-issues/issues/1747

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/fe0e522d-9588-babe-cfa7-28258ab6643a%40qubes-os.org.

[qubes-devel] Qubes OS 4.2.0-rc1 is available for testing

[Andrew David Wong]

Dear Qubes Community,

We're pleased to announce that the first [release 
candidate](#what-is-a-release-candidate) for Qubes OS 4.2.0 is now available 
for [testing](https://www.qubes-os.org/doc/testing/). This [minor 
release](#what-is-a-minor-release) includes several new features and 
improvements over Qubes OS 4.1.0. Qubes 4.2.0-rc1 is available on the 
[downloads](https://www.qubes-os.org/downloads/) page.

## What's new in Qubes 4.2.0?

- Dom0 upgraded to Fedora 37
- Xen updated to version 4.17
- 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

Please see the [Qubes OS 4.2.0 release 
notes](https://www.qubes-os.org/doc/releases/4.2/release-notes/) for details.

## 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-rc1 ISO.

## Testing Qubes 4.2.0-rc1

If you're willing to [test](https://www.qubes-os.org/doc/testing/) this 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 known bugs in Qubes 4.2.0 is available 
[here](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+4.2%22+label%3A%22T%3A+bug%22).
 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-rc1

It is not yet possible to perform an in-place upgrade from Qubes 4.1 to Qubes 
4.2. For this initial release candidate, a clean installation is required. An 
in-place upgrade tool is in development.

## 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.

In the case of Qubes 4.2.0 specifically, we already know that there will be a 
second release candidate (in order to test the in-place upgrade procedure, if 
nothing else). As mentioned above, we expect to announce that second release 
candidate in approximately five weeks. The results of that second release 
candidate will determine 

[qubes-devel] XSAs released on 2023-05-16

[Andrew David Wong]

Dear Qubes Community,

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-431](https://xenbits.xen.org/xsa/advisory-431.html)
  - Qubes OS 4.1 uses an unaffected version of Xen (4.14).

## 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/05/16/xsas-released-on-2023-05-16/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/034437ff-1944-fa19-76c9-fd4f673b509a%40qubes-os.org.

[qubes-devel] Fedora 36 reaches EOL on 2023-05-16

[Andrew David Wong]

Dear Qubes Community,

The Fedora Project has 
[announced](https://lists.fedoraproject.org/archives/list/annou...@lists.fedoraproject.org/thread/4GXBZJSGQ2PEKIBM2APCTLXBS6IDKSOP/)
 that Fedora 36 will reach EOL 
([end-of-life](https://fedoraproject.org/wiki/End_of_life)) on 2023-05-16. We 
strongly recommend that all users 
[upgrade](https://www.qubes-os.org/doc/templates/fedora/#upgrading) their 
Fedora templates and standalones to [Fedora 
37](https://www.qubes-os.org/news/2023/03/03/fedora-37-templates-available/) no 
later than 2023-05-16.

We provide fresh Fedora 37 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).


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/05/11/fedora-36-reaches-eol-on-2023-05-16/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/1201eea6-25ed-8305-a050-d9638c57c29d%40qubes-os.org.

[qubes-devel] QSB-089: Qrexec: Memory corruption in service request handling

[Andrew David Wong]

out these keys.)

   ```shell_session
   $ 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
   ```

7. Verify signed Git tags.

   ```shell_session
   $ 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.

8. Verify PGP signatures, e.g.:

   ```shell_session
   $ 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]
   ```

   Aga

[qubes-devel] XSAs released on 2023-04-25

[Andrew David Wong]

Dear Qubes Community,

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-430](https://xenbits.xen.org/xsa/advisory-430.html)
  - Shadow paging is disabled in Qubes OS at build time.
  - Qubes OS 4.1 uses an unaffected version of Xen (4.14).

## 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/04/25/xsas-released-on-2023-04-25/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/084e12d4-d234-5989-d08d-faea0aafa8e0%40qubes-os.org.

[qubes-devel] QSB-088: Two Xen issues affecting PV (stub-)domains (XSA-428, XSA-429)

[Andrew David Wong]

cates a prompt inside of the GnuPG program. Type what appears after it when 
prompted.)

   ```shell_session
   $ 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
   ```

3. *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.

4. Once you are satisfied that you have the genuine QMSK, set its trust level 
to 5 ("ultimate"), then quit GnuPG with `q`.

   ```shell_session
   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
   ```

5. Use Git to clone the qubes-secpack repo.

   ```shell_session
   $ 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.
   ```

6. 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.)

   ```shell_session
   $ 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:

[qubes-devel] Marek Marczykowski-Górecki to be interviewed at Dasharo virtual event

[Andrew David Wong]

Dear Qubes Community,

Our project lead, [Marek 
Marczykowski-Górecki](https://www.qubes-os.org/team/#marek-marczykowski-górecki)
 will be interviewed tomorrow during the [Dasharo Developers 
vPub](https://vpub.dasharo.com/e/1/dasharo-user-group-1). This is a virtual 
event hosted by the [Dasharo](https://www.dasharo.com/) team, who just 
introduced [the first Qubes-certified desktop 
computer](https://www.qubes-os.org/news/2023/03/15/dasharo-fidelisguard-z690-first-qubes-certified-desktop).

[![Dasharo User Group (DUG) #1 and Dasharo Developers vPub 0x6 informational 
poster](https://www.qubes-os.org/attachment/posts/dasharo-event-1.png)](https://vpub.dasharo.com/e/1/dasharo-user-group-1)

The Dasharo Developers vPub will be preceded by the first Dasharo User Group 
meeting, which may be of interest for Qubes users who wish to learn more about 
open-source firmware or are curious about the [Dasharo FidelisGuard 
Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
 Qubes-certified computer.

[Read the full announcement for more 
information.](https://vpub.dasharo.com/e/1/dasharo-user-group-1)

## About Dasharo

"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." [Learn 
more about Dasharo.](https://docs.dasharo.com/osf-trivia-list/dasharo/)

Dasharo is a registered trademark of and a product developed by 
[3mdeb](https://3mdeb.com/).

## About 3mdeb

3mdeb and the Qubes OS Project have been partnering together for years to hold 
Qubes OS Summits. Michał Żygowski shared the story with us in [Qubes OS Summit: 
History from organizer's 
perspective](https://www.qubes-os.org/news/2022/09/07/qubes-os-summit-history/).
 You can watch videos from the 2022 summit 
[here](https://www.youtube.com/watch?v=hkWWz3xGqS8) and 
[here](https://www.youtube.com/watch?v=A9GrlQsQc7Q). 3mdeb has also been 
instrumental in recent work on [TrenchBoot Anti Evil Maid for Qubes 
OS](https://www.qubes-os.org/news/2023/01/31/trenchboot-aem-for-qubes-os/). 
[Learn more about 3mdeb.](https://3mdeb.com/about-us/)


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/03/15/marek-marczykowski-gorecki-interviewed-dasharo-virtual-event/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/9e775f93-aa64-eb50-b215-12125183563b%40qubes-os.org.

[qubes-devel] The Dasharo FidelisGuard Z690 is the first Qubes-certified desktop computer!

[Andrew David Wong]

Dear Qubes Community,

It is our pleasure to announce that the [Dasharo FidelisGuard 
Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
 has become the fourth [Qubes-certified 
computer](https://www.qubes-os.org/doc/certified-hardware/) for Qubes 4.X and 
the *first* Qubes-certified desktop computer *ever*!

(In related news, the [Dasharo User Group #1 and Dasharo Developers vPub 
0x6)](https://www.qubes-os.org/news/2023/03/15/marek-marczykowski-gorecki-interviewed-dasharo-virtual-event)
 virtual event is tomorrow and will include an interview with our project lead, 
[Marek 
Marczykowski-Górecki](https://www.qubes-os.org/team/#marek-marczykowski-górecki)!)

## About the Dasharo FidelisGuard Z690

[![Photo of MSI PRO Z690-A DDR4 
motherboard](https://www.qubes-os.org/attachment/posts/dasharo-fidelisguard-z690_1.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)

The [Dasharo FidelisGuard 
Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
 is a full desktop PC build that brings the [Dasharo](https://dasharo.com/) 
open-source firmware distribution to the MSI PRO Z690-A DDR4 motherboard with 
Qubes OS preinstalled. The full configuration includes:

| Part | Model Name 
|
|- | -- 
|
| CPU  | Intel Core i5-12600K, 3.7GHz   
|
| Cooling  | Noctua CPU NH-U12S Redux   
|
| RAM  | Kingston Fury Beast, DDR4, 4x8GB (32 GB Total), 3600 MHz, CL17 
|
| Power Supply | Seasonic Focus PX 750W 80 Plus Platinum
|
| Storage  | SSD Intel 670p 512 GB M.2 2280 PCI-E x4 Gen3 NVMe  
|
| Enclosure| SilentiumPC Armis AR1  
|

[![Photo of Dasharo FidelisGuard Z690 with open 
case](https://www.qubes-os.org/attachment/posts/dasharo-fidelisguard-z690_2.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)

This computer comes with a "Dasharo Supporters Entrance Subscription," which 
includes the following:

- Full access to [Dasharo Tools Suite 
(DTS)](https://docs.dasharo.com/dasharo-tools-suite/overview/)
- The latest Dasharo releases issued by the Dasharo Team
- Special Dasharo updates for supporters
- Dasharo Premier Support through an invite-only Matrix channel
- Influence on the Dasharo feature roadmap

[![Photo of Dasharo FidelisGuard Z690 with open 
case](https://www.qubes-os.org/attachment/posts/dasharo-fidelisguard-z690_3.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)

For further details, please see the [Dasharo FidelisGuard 
Z690](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)
 product page.

[![Photo of the outside of the Dasharo FidelisGuard 
Z690](https://www.qubes-os.org/attachment/posts/dasharo-fidelisguard-z690_4.jpg)](https://3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/)

## 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 Dasharo FidelisGuard Z690'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 Dasharo

"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." [Learn 
more about Dasharo.](https://docs.dasharo.com/osf-trivia-list/dasharo/)

Dasharo is a registered trademark of and a product developed by 
[3mdeb](https://3mdeb.com/).

## About 3mdeb

3mdeb and the Qubes OS Project have been partnering together for years to hold 
Qubes OS Summits. Michał Żygowski shared the story with us in [Qubes OS Summit: 
History from organizer's 
perspective](https://www.qubes-os.org/news/2022/09/07/qubes-os-summit-history/).
 You can watch videos from the 2022 summit 
[here](https://www.youtube.com/watch?v=hkWWz3xGqS8) and 
[here](https://www.youtube.com/watch?v=A9GrlQsQc7Q). 3mdeb has also been 

[qubes-devel] Qubes OS 4.1.2 has been released!

[Andrew David Wong]

Dear Qubes Community,

We're pleased to announce the stable release of Qubes 4.1.2! 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. 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.2 is available on the 
[downloads](https://www.qubes-os.org/downloads/) page.


## Existing installations

If you are already using any version of Qubes 4.1 (including 4.1.0, 4.1.1, 
4.1.2-rc1, and 4.1.2-rc2), then you should simply [update 
normally](https://www.qubes-os.org/doc/how-to-update/) (which includes 
[upgrading any EOL 
templates](https://www.qubes-os.org/doc/how-to-update/#upgrading-to-avoid-eol) 
you might have) in order to make your system effectively equivalent to this 
stable Qubes 4.1.2 release. No reinstallation or other special action is 
required.


## New installations

If you would like to install Qubes OS for the first time or perform a clean 
reinstallation on an existing system, there has never been a better time to do 
so! Simply [download](https://www.qubes-os.org/downloads/) the Qubes 4.1.2 ISO 
and follow our [installation 
guide](https://www.qubes-os.org/doc/installation-guide/).


## What's new in Qubes 4.1.2?

Qubes 4.1.2 includes numerous updates over the initial 4.1.0 release, in 
particular:

- All 4.1 dom0 updates to date
- Fedora 37 template
- USB keyboard support in the installer 
([#7674](https://github.com/QubesOS/qubes-issues/issues/7674))
- `kernel-latest` available as a boot option when starting the installer 
([#5900](https://github.com/QubesOS/qubes-issues/issues/5900))


## 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) 
inclusive of all updates up to a certain point. (See [supported 
releases](https://www.qubes-os.org/doc/supported-releases/) for a comprehensive 
list of major and minor releases.) Installing any prior Qubes 4.1 release and 
fully [updating](https://www.qubes-os.org/doc/how-to-update/) it results in 
essentially the same system as installing Qubes 4.1.2. You can learn more about 
how Qubes release versioning works in the [version 
scheme](https://www.qubes-os.org/doc/version-scheme/) documentation.


## Reminder: Qubes 4.0 has reached end-of-life

Qubes 4.0 [reached EOL (end-of-life) on 
2022-08-04](https://www.qubes-os.org/news/2022/07/04/qubes-os-4-0-eol-on-2022-08-04/).
 If you're still using Qubes 4.0, we strongly recommend upgrading to Qubes 4.1.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/03/15/qubes-4-1-2/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/23dc76fa-d8e6-1374-7f61-3eeb15b9576e%40qubes-os.org.

[qubes-devel] Re: [CORRECTED] Qubes Canary 034

[Andrew David Wong]

Dear Qubes Community,

*Editor's note*: An earlier version of this announcement mistakenly contained 
the text of an older canary. This has been corrected below. As always, we 
encourage readers to verify the cryptographic signatures on canaries, which can 
always be found in the [Qubes security pack 
(qubes-secpack)](https://www.qubes-os.org/security/pack/).

We have published a new [Qubes 
canary](https://www.qubes-os.org/security/canary/). The text of this canary is 
reproduced below. This canary and its accompanying cryptographic signatures 
will always be available in the [Qubes security pack 
(qubes-secpack)](https://www.qubes-os.org/security/pack/).

```

---===[ Qubes Canary 034 ]===---


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 March 02, 2023.

2. There have been 87 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 last
   fourteen days of May 2023. 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
---

Thu, 02 Mar 2023 09:45:31 +

Source: DER SPIEGEL - International 
(https://www.spiegel.de/international/index.rss)
Dubious Alliance: How Present Is the Far Right in Germany's New Peace Movement?
Kaja Kallas: Estonia's High-Profile Prime Minister - a Star in the Making
The Special Tribunal Debate: "An Arrest Warrant Against Putin Would Be Immense"
The War in Ukraine: China Is Reportedly Negotiating with Russia To Supply 
Kamikaze Drones
Volodymyr Zelenskyy's Heroes: Ukraine's Best Respond to the Earthquake in Turkey

Source: NYT > World News 
(https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
How Russia Lost an Epic Tank Battle, Repeating Earlier Mistakes
Kyiv Sends Reinforcements to Besieged Bakhmut
Bola Tinubu Elected to Be Nigeria’s Next President
Video: How an Israeli Raid on a Safe House Ended With Civilians Killed
Bola Tinubu’s Victory Extends His Party’s Time in Power in Nigeria

Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Greece train crash: Angry protests erupt after disaster
India PM Modi urges G20 foreign ministers to overcome differences
How fake copyright complaints are muzzling journalists
Whiskey fungus lawsuit forces Jack Daniels to halt building project
Indian guru's fictional country attended UN events

Source: Blockchain.info
00037ab2816f3100fc37acee47a63571b5d3b7ca72145906


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/
```


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/03/02/canary-034/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

[qubes-devel] XSAs released on 2023-02-14

[Andrew David Wong]

Dear Qubes Community,

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-426 (SMT is disabled in Qubes OS by default)


## 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/02/15/xsas-released-on-2023-02-14/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/e0f5f316-3706-ec86-6a96-ddee80c6f812%40qubes-os.org.

[qubes-devel] Qubes OS 4.1.2-rc1 has been released!

[Andrew David Wong]

Dear Qubes Community,

We're pleased to announce the first [release 
candidate](#what-is-a-release-candidate) for Qubes 4.1.2! This [patch 
release](#what-is-a-patch-release) aims to consolidate all the security 
patches, bug fixes, and upstream template OS upgrades that have occurred since 
prior Qubes 4.1 releases. 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.2-rc1 is available on the 
[downloads](https://www.qubes-os.org/downloads/) page.


## What's new in Qubes 4.1.2?

Qubes 4.1.2-rc1 includes numerous updates over the initial 4.1.0 release, in 
particular:

- All 4.1 dom0 updates to date
- Fedora 37 template
- USB keyboard support in the installer 
([#7674](https://github.com/QubesOS/qubes-issues/issues/7674))
- `kernel-latest` available as a boot option when starting the installer 
([#5900](https://github.com/QubesOS/qubes-issues/issues/5900))


## Testing Qubes 4.1.2-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 experienced users to join the [testing 
team](https://forum.qubes-os.org/t/joining-the-testing-team/5190)!


## Existing Qubes 4.1 users

If you're not interested in testing this release candidate, and you're already 
using Qubes 4.1, then you should simply [update 
normally](https://www.qubes-os.org/doc/how-to-update/) (which includes 
[upgrading any EOL 
templates](https://www.qubes-os.org/doc/how-to-update/#upgrading-to-avoid-eol) 
you might have) in order to make your system essentially equivalent to this 
patch release. No special action is required on your part.


## Release candidate planning

If no significant bugs are discovered in 4.1.2-rc1, we expect to announce the 
stable release of 4.1.2 in two to three weeks.


## 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 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) 
inclusive of all updates up to a certain point. (See [supported 
releases](https://www.qubes-os.org/doc/supported-releases/) for a comprehensive 
list of major and minor releases.) Installing any prior Qubes 4.1 release and 
fully [updating](https://www.qubes-os.org/doc/how-to-update/) it results in 
essentially the same system as installing Qubes 4.1.2. You can learn more about 
how Qubes release versioning works in the [version 
scheme](https://www.qubes-os.org/doc/version-scheme/) documentation.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/02/09/qubes-4-1-2-rc1/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/f968bb2b-3947-74b8-3a95-7b240951b338%40qubes-os.org.

[qubes-devel] Guest post: "TrenchBoot Anti Evil Maid for Qubes OS" by Michal Zygowski of 3mdeb

[Andrew David Wong]

Dear Qubes Community,

The following is a guest post by Michal Zygowski from 
[3mdeb](https://3mdeb.com/) on the work they've been doing to upgrade [Anti 
Evil Maid (AEM)](https://www.qubes-os.org/doc/anti-evil-maid/). The original 
post can be found on the [3mdeb 
blog](https://blog.3mdeb.com/2023/2023-01-31-trenchboot-aem-for-qubesos/). This 
work was made possible through generous 
[donations](https://www.qubes-os.org/donate/) from the Qubes community via 
[OpenCollective](https://opencollective.com/qubes-os). We are immensely 
grateful to the Qubes community for your continued support and to 3mdeb for 
contributing this valuable work.

"TrenchBoot Anti Evil Maid for Qubes OS"
by Michal Zygowski
https://blog.3mdeb.com/2023/2023-01-31-trenchboot-aem-for-qubesos/
https://www.qubes-os.org/news/2023/01/31/trenchboot-aem-for-qubes-os/

As a courtesy to plain text email users, the Markdown source of the article 
body is reproduced below.

8<--

## Abstract

Qubes OS Anti Evil Maid (AEM) software heavily depends on the
availability of the DRTM technologies to prevent the Evil Maid
attacks. However, the project has not evolved much since the
beginning of 2018 and froze on the support of TPM 1.2 with Intel TXT
in legacy boot mode (BIOS). In the post we show how existing
solution can be replaced with TrenchBoot and how one can install it
on the Qubes OS. Also the post will also briefly explain how
TrenchBoot opens the door for future TPM 2.0 and UEFI support for
AEM.

## Introduction

As Qubes OS users, promoters, and developers, we understand how essential it is
to be aware of the latest developments in maintaining the security of your
favorite operating system. We're excited to share our plans to integrate the
TrenchBoot Project into Qubes OS's new Anti-Evil Maid (AEM) implementation. As
you may know, traditional firmware security measures like UEFI Secure Boot and
measured boot, even with a Static Root of Trust (SRT), may only sometimes be
enough to ensure a completely secure environment for your operating system.
Compromised firmware may allow for the injection of malicious software into
your system, making it difficult to detect. To overcome these limitations, many
silicon vendors have started implementing Dynamic Root of Trust (DRT)
technologies to establish a secure environment for operating system launch and
integrity measurements. We're excited to take advantage of these advancements
through integration with the [TrenchBoot Project](https://trenchboot.org/).

The usage of DRT technologies like Intel Trusted Execution Technology (TXT) or
AMD Secure Startup is becoming more and more significant; for example, Dynamic
Root of Trust for Measurement (DRTM) requirements of [Microsoft Secured Core 
PCs](https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-highly-secure#what-makes-a-secured-core-pc).
DRTM has yet to find its place in open-source projects, but that gradually
changes. The demand for having firmware-independent Roots of Trust is
increasing, and projects that satisfy this demand are growing TrenchBoot is a
framework that allows individuals and projects to build security engines to
perform launch integrity actions for their systems. The framework builds upon
Boot Integrity Technologies (BITs) that establish one or more Roots of Trust
(RoT) from which a degree of confidence that integrity actions were not
subverted.

[Qubes OS Anti Evil Maid 
(AEM)](https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html)
software heavily depends on the availability of DRTM technologies to prevent
Evil Maid attacks. However, the project hasn't evolved much since the beginning
of 2018 and froze on the support of TPM 1.2 with Intel TXT in legacy boot mode
(BIOS). Because of that, the usage of this security software is effectively
limited to older Intel machines only. TPM 1.2 implemented SHA1 hashing
algorithm, which is nowadays considered weak in the era of forever-increasing
computer performance and quantum computing. The solution to this problem comes
with a newer TPM 2.0 with more agile cryptographic algorithms and SHA256
implementation by default.

The post will present the TrenchBoot solution for Qubes OS AEM replacing the
current TPM 1.2 and Intel TXT-only implementation. The advantage of TrenchBoot
solution over existing [Trusted 
Boot](https://sourceforge.net/p/tboot/wiki/Home/)
is the easier future integration of AMD platform support, as well as TPM 2.0
and UEFI mode support.

Before we dive into the technical details, it is important to highlight that
this achievement was made possible through the generous contributions of Qubes
OS community via OpenCollective. We would like to express our gratitude and
extend a special thank you to all who have supported our favourite operating
system. To continue supporting Qubes OS, please consider donating through
[OpenCollective 

[qubes-devel] XSAs released on 2023-01-25

[Andrew David Wong]

Dear Qubes Community,

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-425 (Qubes 4.1 does not use the affected Xen version; denial-of-service 
only)


## 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2023/01/27/xsas-released-on-2023-01-25/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/0dcb1285-9783-d528-c06e-5db13aae167f%40qubes-os.org.

Re: [qubes-devel] Qubes is compatible with Gnome (A report & request)

[Andrew David Wong]

On 12/22/22 5:11 PM, Howard Chen (HowardPlayzOfAdmin Gaming) wrote:
> To the Devs:
> 
> As you may see, Qubes is compatible with Gnome desktop; however, it does 
> not have Qubes settings icons in it may be because it's only works with 
> XFCE and KDE. As in the image, everything is working fine, but the images 
> of Qubes settings are missing. I have some questions: could you guys make a 
> gnome-shell extension so that Qubes can be compatible with Gnome DE and 
> with workspace ease adding module within the extension? Thanks.
> 
> -HC (@hpoa...@forum.qubes-os.org)

FYI, there is an open issue for this:

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/3d5f-8a47-233f-b1df-3c49c388322f%40qubes-os.org.

[qubes-devel] Support the Qubes OS Project via Proton's charity fundraiser!

[Andrew David Wong]

Dear Qubes Community,

The Qubes OS Project is grateful to have been selected as one of the 
beneficiaries of this year's Proton charity fundraiser alongside so many other 
wonderful organizations. The continued support of the privacy community means 
the world to us! For details about the fundraiser and how you can participate, 
please see the official Proton blog post: 

https://proton.me/blog/2022-lifetime-account-charity-fundraiser

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/c763720a-102b-5a14-07f5-7c2873f2c237%40qubes-os.org.

[qubes-devel] Fedora 35 reaches EOL on 2022-12-13

[Andrew David Wong]

Dear Qubes Community,

The Fedora Project has 
[announced](https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/OGTVKLX7OXBYCEUQ66UY4YK3T6QHAYW5/)
 that Fedora 35 will reach EOL 
([end-of-life](https://fedoraproject.org/wiki/End_of_life)) on 2022-12-13. We 
strongly recommend that all users 
[upgrade](https://www.qubes-os.org/doc/templates/fedora/#upgrading) their 
Fedora templates and standalones to Fedora 36 no later than 2022-12-13.

We provide fresh Fedora 36 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).


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/12/08/fedora-35-reaches-eol-on-2022-12-13/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/635e14c4-d155-7af8-5dbd-702f45fe6532%40qubes-os.org.

[qubes-devel] XSAs released on 2022-12-06

[Andrew David Wong]

Dear Qubes Community,

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-423 (denial-of-service only)
- XSA-424 (denial-of-service only)


## 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/12/06/xsas-released-on-2022-12-06/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/c6071065-1ba9-7c68-bdb5-967b875e4ee3%40qubes-os.org.

[qubes-devel] Qubes Canary 033

[Andrew David Wong]

Dear Qubes Community,

We have published Qubes Canary 033. 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 033 in the qubes-secpack:



Learn how to obtain and authenticate the qubes-secpack and all the
signatures it contains:



View all past canaries:



```

---===[ Qubes Canary 033 ]===---


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 December 04, 2022.

2. There have been 87 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 March 2023. 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
---

Sun, 04 Dec 2022 03:11:56 +

Source: DER SPIEGEL - International 
(https://www.spiegel.de/international/index.rss)
Friends or Frenemies?: Significant Trans-Atlantic Divides Emerge in Global Chip 
War
The Russian Mobilization: One Soldier's Effort to Avoid the War
Tragedy in Mariupol: The Boy Who Lost His Family But Not His Hope
A Year with Angela Merkel: "You're Done with Power Politics"
Fears of Chinese Aggression Grow in Taiwan: "Where Are We Supposed to Go?"

Source: NYT > World News 
(https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
He Returned a Dazed Soldier to the Russians. Ukraine Calls It Treason.
Landslide Tragedy Turns Italy’s Focus to Illegal Construction
Why Is Rahul Gandhi Walking 2,000 Miles Across India?
How China’s Police Used Phones and Faces to Track Protesters
Ukraine Calls for Evacuations From a Russian-Controlled Area

Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Cyril Ramaphosa: South Africa leader won't resign, says spokesman
Ukraine war: Zelensky calls West's Russian oil cap 'weak'
Ukraine war: New images show Russian army base built in occupied Mariupol
Elnaz Rekabi: Family home of Iranian climber demolished
Columbia peace talks with leftist ELN rebels make progress

Source: Blockchain.info
955f2976b1fbff0d0c47c262ea3ae6410e43f8218fb7


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/
```


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/12/04/canary-033/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/eefc55d9-32c9-3753-055d-1b75d56db194%40qubes-os.org.

Re: [qubes-devel] qubes-doc & rtd

[Andrew David Wong]

On 11/28/22 8:05 AM, Marek Marczykowski-Górecki wrote:
> On Tue, Nov 01, 2022 at 12:45:33PM +0100, mm wrote:
>> Hi Marek, hi Andrew, hi Tobias,
> 
>> Marek, I merged your pull request, also merged your changes into master and
>> added some enhancements and created a pull request.
> 
>> Here you could review it
>> https://github.com/maiska/qubes-translation-utilz/pull/2
> 
>> Either way, one could try it out, there should be no more undefined or
>> unknown label warnings when rendering the rst docs
>> and thus could safely imho go and convert the documentation and host it on
>> RTD.
> 
>> Here is a README.md instead of spamming via email
>> https://github.com/maiska/qubes-translation-utilz/blob/master/README.md
> 
>> the configuration should be more readable also:
> 
>> https://github.com/maiska/qubes-translation-utilz/blob/master/md2rst/config.toml
> 
>> Please let me know if I have to fix further or this suffices.
> 
> I think the current version of scripts is good :) Thanks!
> 
> There are sphinx warning remaining, but there are not that many of them
> and can be fixed manually (things like underscores for headers, or
> single space at the beginning of line interpreted as unexpected
> indentation).
> 
> The only other issue I consider a blocker (but hopefully should be easy
> to fix) is index.rst. The sidebar index is great, but in its current
> form it's hard to use - it's very long. I added section captions there
> and it helped a bit, but I think those should be folded by default
> (similar folding like sections of the current page). I tried setting
> `collapse_navigation`[1], but it didn't work.  Any other ideas?
> 
> BTW, while looking for related option, I found you can use `:glob:`
> in toctree, to add everything from given subdirectory. This way we can have
> some section filled automatically (as long as directory structure
> reflects sections, but it is the case in most cases).
> 
> I uploaded current version to
> https://qubes-doc-rst.readthedocs.io/en/latest/ (I haven't fixed all
> sphinx warnings there, so few places may have wrong indentation). I
> haven't updated translated pages - those are still from previous
> iteration.
> Source of the above is at https://github.com/marmarek/qubes-doc/tree/work4/
> 
> Another thing that IMO would be better, is to keep the "introduction" page
> as part of the main website, and only link to it from the documentation.
> Should be easy with the redirects extension (as already done for HCL and
> few others).
> 
> The next question is what to do about qubes-doc repo. We can either
> replace the current content with converted to rst (and keep markdown in
> a separate branch, for historical reasons), or create new one
> (qubes-doc-rst?), and basically archive qubes-doc.
> 

Git already keeps everything for historical reasons, so I don't think it's 
necessary to keep a separate branch around *forever* just for historical 
reasons, which would create extra clutter and get in the way, but keeping the 
historical branch for, say, a year would make sense. For a permanent marker, it 
seems cleaner just use a tag to indicate where the transition occurred.

As far as I can tell, the main difference between reusing the same repo and 
creating a new repo is simply that, in the latter case, history would be split 
across two repos, and we'd have to update all of our references to "qubes-doc" 
everywhere. So, I'm inclined to say we should keep using the existing repo.

> In any case, the _doc submodule should be replaced with generated
> redirects to the new documentation. IMO it can be put into
> qubesos.github.io repository directly, as it shouldn't really change
> (it's only to keep existing documentation links on mailing list, forum
> etc working, shouldn't be used for new content).
> 
> [1] https://sphinx-rtd-theme.readthedocs.io/en/stable/configuring.html
> 
>> Otherwise I will briefly handson evaluate weblate locally and report back.
> 
> Do you have any update on weblate?
> 
>> @Andrew,
> 
>> regarding the minimal debian jekyll vm, here is a way with a template and an
>> app vm.
> 
>> qvm-clone debian-11-minimal jekyll-tvm
> 
>> in jekyll-tvm:
>> apt install qubes-core-agent-networking
>> apt install ruby-full build-essential zlib1g-dev vim
>> apt install qubes-core-agent-passwordless-root
>> apt install firefox-esr git
> 
>> in jekyll-app-vm:
>> echo '# Install Ruby Gems to ~/gems' >> ~/.bashrc
>> echo 'export GEM_HOME="$HOME/gems"' >> ~/.bashrc
>> echo 'export PATH="$HOME/gems/bin:$PATH"' >> ~/.bashrc
>> source ~/.bashrc
>> gem install jekyll bundler
>> find . -name gem # '/home/user/.local/share/gem/'
>> bundle config set --local path '/home/user/.local/share/gem/'
>> git clone -b new-master --recursive
>> https://github.com/QubesOS/qubesos.github.io.git; cd qubesos.github.io.rtd/
>> bundle install
>> bundle exec jekyll serve --incremental
> 
> 
> 
>> All the best,
> 
>> m
> 
> 
> 
>> On 10/4/22 12:29, Marek Marczykowski-Górecki wrote:
>>> Hi,
>>>
>>> Thanks 

[qubes-devel] QSB-087: Qrexec: Injection of unsanitized data into log output

[Andrew David Wong]

Dear Qubes Community,

We have just published [Qubes Security Bulletin (QSB) 087: Qrexec: Injection of 
unsanitized data into log 
output](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-087-2022.txt).
 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)](https://www.qubes-os.org/security/pack/). More information 
about QSBs, including a complete historical list, is available 
[here](https://www.qubes-os.org/security/qsb/).

```

 ---===[ Qubes Security Bulletin 087 ]===---

 2022-11-23

  Qrexec: Injection of unsanitized data into log output

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 templates, standalones and dom0:
  - qrexec packages version 4.1.19

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]

Summary


Due to a bug in qrexec [3], a malicious qube that is allowed to call a
qrexec service inside of another qube can inject unsanitized data into
the log output of a process that handles incoming qrexec calls in the
receiving qube. This log output may end up in
`/var/log/qubes/qrexec.*.log`, `~/.xsession-errors`, or systemd's
journal.

Impact
---

An attacker could use this vulnerability in order to inject malicious
data, such as terminal control codes, into log output in the hope that
this data will be processed in a unsafe way, for example, by writing it
directly to a potentially-vulnerable terminal emulator.

In the default Qubes OS configuration, for example, there are qrexec
services like `qubes.WindowIconUpdater` that any qube can call in dom0.
An attacker who gains control of an untrusted qube could inject data
containing malicious terminal control sequences into
`/var/log/qubes/qrexec.*.log` in dom0. If the user views that log in a
terminal emulator in a way that doesn't filter terminal escape codes (by
simply using `cat` on the file, for example), the malicious data might
then exploit a hypothetical bug in the terminal emulator.

Note that this attack scenario, as described, has several layered
requirements:

1. The user must voluntarily open a log file containing malicious data
   (or otherwise take action that causes the log file data to be
   parsed).

2. There must exist an independent vulnerability in the user's terminal
   emulator or in whichever program parses the log. (In other words, the
   attacker must chain independent vulnerabilities together.)

3. If using a terminal emulator, a command-line tool that does not
   filter control codes must be used. (`journalctl` prevents the display
   of unsafe sequences by default, but many other tools do not.)

To be clear, the scenario in which the attacker uses the
`qubes.WindowIconUpdater` service in order to exploit a hypothetical bug
in a terminal emulator is just one conceivable scenario for how an
attacker might exploit the vulnerability described in this bulletin. It
is not the only way in which this vulnerability could be exploited, and
the requirements listed for this scenario may not necessarily apply to
other scenarios featuring different types of attacks (for example, using
other qrexec services and exploiting other software that handles log
output). Rather, this example is merely intended as an aid for
understanding the nature of the vulnerability.

Discussion
---

Qubes OS features a framework known as "qrexec," which allows different
qubes to communicate with each other in a controlled manner. [3][4]
These interactions are restricted by the system's RPC policies. [5] In
particular, qrexec can be used to allow less trusted qubes to
communicate with more trusted qubes, including dom0.

Normally, the calling side can send data to the remote services'
standard input and receive its standard output, standard error, and exit
code data. Since it handles untrusted data flows, qrexec is designed
under the assumption that an adversary will use it in order to launch an
attack against one qube from another qube. Therefore, qrexec treats
incoming data as untrusted and carefully sanitizes it. For example, when
qrexec output is connected to a terminal, `qrexec-client` and
`qrexec-client-vm` remove terminal control sequences.

However, due to a mistake in qrexec message type handling, the calling
side can send data marked as "standard error" (`MSG_DATA_STDERR`), and
the remote side will print it to the standard error of the process
handling incoming qrexec connections. This data flow was not expected.
Such messages should be rejected, as they are expected only in the other
direction. Consequently, this data 

[qubes-devel] XSAs released on 2022-11-08

[Andrew David Wong]

Dear Qubes Community,

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-422

Please see [QSB-086](https://www.qubes-os.org/news/2022/11/08/qsb-086/) for 
further 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.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/11/08/xsas-released-on-2022-11-08/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/c720b745-266f-d303-1523-182a239b37b9%40qubes-os.org.

[qubes-devel] QSB-086: Speculative security issues on AMD CPUs (XSA-422)

[Andrew David Wong]

Dear Qubes Community,

We have just published [Qubes Security Bulletin (QSB) 086: Speculative security 
issues on AMD CPUs 
(XSA-422)](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-086-2022.txt).
 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)](https://www.qubes-os.org/security/pack/). More information 
about QSBs, including a complete historical list, is available 
[here](https://www.qubes-os.org/security/qsb/).

```

 ---===[ Qubes Security Bulletin 086 ]===---

 2022-11-08

   Speculative security issues on AMD CPUs (XSA-422)


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.5-13

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-11-08, the Xen Project published XSA-422, "x86: Multiple
speculative security issues" [3]:

| Researchers have discovered that on some AMD CPUs, the
| implementation of IBPB (Indirect Branch Prediction Barrier) does not
| behave according to the specification.
|
| Specifically, IBPB fails to properly flush the RAS (Return Address
| Stack, also RSB - Return Stack Buffer - in Intel terminology; one of
| the hardware prediction structures), allowing attacker controlled
| values to survive across a deliberate attempt to purge said values.
|
| AMD have allocated CVE-2022-23824.

XSA-422 also describes a second AMD vulnerability. However, since it
is believed not to affect Xen, and therefore not to affect Qubes OS,
it is omitted here.


Impact
---

On Qubes OS installations with affected CPUs, a VM running in PV mode
may be capable of inferring the memory contents of other running VMs,
including dom0. In the default Qubes OS configuration, only the
stubdomains for HVMs are in a position to exploit this vulnerability
in order to attack other VMs. (Dom0 also runs in PV mode, but it is
fully trusted.)

Only certain AMD CPUs are affected. Please see AMD-SB-1040 [4] for the
official list of affected models.

(Note: XSA-422 states that Xen versions prior to 4.16 are not affected
by this vulnerability. While Qubes OS uses a Xen version prior to
4.16, we have backported a Xen performance optimization [5] that
assumes that IBPB works as previously specified. Therefore, the
version of Xen used in Qubes is affected by this vulnerability even
though its version numbers is lower than 4.16.)


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-422.html
[4] https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1040
[5] 
https://github.com/QubesOS/qubes-vmm-xen/blob/v4.14.5-12/patch-0001-x86-spec-ctrl-Skip-RSB-overwriting-when-safe-to-do-s.patch

--
The Qubes Security Team
https://www.qubes-os.org/security/

```


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/11/08/qsb-086/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/5e3d5454-cdfc-b576-6233-899e94d95f64%40qubes-os.org.

[qubes-devel] XSAs released on 2022-11-01

[Andrew David Wong]

Dear Qubes Community,

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 DO affect the security of Qubes OS

The following XSAs *do affect* the security of Qubes OS:

- XSA-414

Please see [QSB-085](https://www.qubes-os.org/news/2022/11/01/qsb-085/) for 
further 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:

- XSA-326 (denial-of-service only)
- XSA-412 (affects only version 4.16)
- XSA-415 (denial-of-service only)
- XSA-416 (denial-of-service only)
- XSA-417 (domid is never reused)
- XSA-418 (denial-of-service only)
- XSA-419 (denial-of-service only)
- XSA-420 (oxenstored is not used in Qubes OS)
- XSA-421 (denial-of-service 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/)


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/11/01/xsas-released-on-2022-11-01/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/81b39e8c-e335-3337-9a4b-66cd6ebc53c0%40qubes-os.org.

[qubes-devel] QSB-085: Xenstore: Guests can crash xenstored (XSA-414)

[Andrew David Wong]

Dear Qubes Community,

We have just published [Qubes Security Bulletin (QSB) 085: Xenstore: Guests can 
crash xenstored 
(XSA-414)](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-085-2022.txt).
 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)](https://www.qubes-os.org/security/pack/). More information 
about QSBs, including a complete historical list, is available 
[here](https://www.qubes-os.org/security/qsb/).

```

 ---===[ Qubes Security Bulletin 085 ]===---

 2022-11-01

   Xenstore: Guests can crash xenstored (XSA-414)


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.5-12

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-11-01, the Xen Project published XSA-414, "Xenstore: Guests
can crash xenstored" [3]:

| Due to a bug in the fix of XSA-115 a malicious guest can cause
| xenstored to use a wrong pointer during node creation in an error
| path, resulting in a crash of xenstored or a memory corruption in
| xenstored causing further damage.
|
| Entering the error path can be controlled by the guest e.g. by
| exceeding the quota value of maximum nodes per domain.


Impact
---

The Xen Project's impact description also applies to Qubes OS:

| A malicious guest can cause xenstored to crash, resulting in the
| inability to create new guests or to change the configuration of
| running guests.
|
| Memory corruption in xenstored or privilege escalation of a guest
| can't be ruled out.

(Note: In Qubes terminology, a Xen guest is referred to as a "qube.")


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-414.html

--
The Qubes Security Team
https://www.qubes-os.org/security/

```


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/11/01/qsb-085/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/053e6df0-4439-1cc0-33e2-2ddeb123c94d%40qubes-os.org.

[qubes-devel] New user guide: How to organize your qubes

[Andrew David Wong]

Dear Qubes Community,

We have just published a new article:

"New user guide: How to organize your qubes"
https://www.qubes-os.org/news/2022/10/28/how-to-organize-your-qubes/

As a courtesy to plain-text email users, the plain-text source is reproduced 
below.

8<

_The following is a new [how-to guide](/doc/#how-to-guides) for users who are
starting out with Qubes OS. You can also find it in our [documentation](/doc/)
under [How to organize your qubes](/doc/how-to-organize-your-qubes/)._


When people first learn about Qubes OS, their initial reaction is often, "Wow,
this looks really cool! But... what can I actually *do* with it?" It's not
always obvious which qubes you should create, what you should do in each one,
and whether your organizational ideas makes sense from a security or usage
perspective.

Each qube is essentially a secure compartment, and you can create as many of
them as you like and connect them to each other in various ways. They're sort
of like Lego blocks in the sense that you can build whatever you want. But if
you're not sure what to build, then this open-ended freedom can be daunting.
It's a bit like staring at a blank document when you first sit down to write
something. The possibilities are endless, and you may not know where to begin!

The truth is that no one else can tell you *exactly* how you should organize
your qubes, as there is no single correct answer to that question. It depends
on your needs, desires, and preferences. Every user's optimal setup will be
different. However, what we *can* do is provide you with some illustrative
examples based on questionnaires and interviews with Qubes users and
developers, as well as our own personal experience and insight from using Qubes
over the years. You may be able to adapt some of these examples to fit your own
unique situation. More importantly, walking you through the rationale behind
various decisions will teach you how to apply the same thought process to your
own organizational decisions. Let's begin!


## Alice, the software developer

Alice is a freelance dev who works on several projects for different clients
simultaneously. The projects have varying requirements and often different
build environments. She has a separate set of qubes for each project. She keeps
them organized by coming up with a naming scheme, such as:

```
clientA-code
clientA-build
clientA-test
clientA-prod
projectB-code
projectB-build-test
projectB-prod
...
```

This helps her keep groups of qubes organized in a set. Some of her qubes are
based on [Debian templates](/doc/templates/debian/), while others are based on
[Fedora templates](/doc/templates/fedora/). The reason for this is that some
software packages are more readily available in one distribution as opposed to
the other. Alice's setup looks like this:

[![Alice's system: diagram 
1](/attachment/doc/howto_use_qubes_alice_1.png)](/attachment/doc/howto_use_qubes_alice_1.png)

- **Several qubes for writing code.** Here's where she runs her IDE, commits
  code, and signs her commits. These qubes are based on different templates
  depending on which tools and which development environment she needs. In
  general, Alice likes to have a separate qube of this type for each client or
  each project. This allows her to keep everything organized and avoid
  accidentally mixing up any access credentials or client code, which could be
  disastrous. This also allows her to truthfully tell her clients that their
  code is always securely isolated from all her other clients. She likes to use
  the [Qubes firewall](/doc/firewall/) to restrict these qubes' network access
  to only the code repositories she needs in that qube in order to avoid
  accidentally interacting with anything else on her local network or on the
  internet. Alice also has some qubes of this type for personal programming
  projects that she works on just for fun when she has "free time" (whatever
  that is).

- **Several qubes for building and testing.** Again, Alice usually likes to
  have one of these for each client or project in order to keep things
  organized. However, this can become rather cumbersome and memory-intensive
  when many such qubes are running at the same time, so Alice will sometimes
  use the same qube for building and testing, or for multiple projects that
  require the same environment, when she decides that the marginal benefits of
  extra compartmentalization aren't worth the trouble. Here's where she pulls
  any dependencies she needs, compiles her code, runs her build toolchain, and
  tests her deliverables. In some cases, she finds it useful to use
  [standalones](/doc/standalones-and-hvms/) for these so that it's easier to
  quickly [install different pieces of software](/doc/how-to-install-software/)
  without having to juggle rebooting both the template and an app qube. She
  also sometimes finds it necessary (or just convenient) to 

[qubes-devel] XSAs released on 2022-10-11

[Andrew David Wong]

Dear Qubes Community,

The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS *is not affected*.
Therefore, *no 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:

- (none)


## 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-409 (ARM architecture only)
- XSA-410 (denial-of-service only)
- XSA-411 (denial-of-service only; gnttab v2 is unused in Qubes OS)
- XSA-413 (denial-of-service only; XAPI is unused in Qubes OS)


## Related links

- Xen XSA list: 
- Qubes XSA tracker: 
- Qubes security pack (qubes-secpack): 
- Qubes security bulletins (QSBs): 


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/10/11/xsas-released-on-2022-10-11/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/47f92807-97e2-0b68-5249-4382b4862507%40qubes-os.org.

[qubes-devel] The Qubes OS Project is now accepting donations on Ethereum!

[Andrew David Wong]

Dear Qubes Community,

We are pleased to announce that the Qubes OS Project is now accepting 
[donations](https://www.qubes-os.org/donate/) on 
[Ethereum](https://ethereum.org/) (Mainnet) at the following address:

```
0xDaa04647e8ecb616801F9bE89712771F6D291a0C
```

*Warning*: This [Gnosis Safe](https://gnosis-safe.io/) Ethereum address 
supports ether (ETH) and all assets that fully comply with the 
[ERC-20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/) 
standard (e.g., USDT, USDC, and DAI), but *only* on [Ethereum 
Mainnet](https://ethereum.org/en/developers/docs/networks/#ethereum-mainnet). 
Please *do not* send assets on any other network to this address, or else your 
donation may be lost. For example, please *do not* send assets on any Ethereum 
Layer 2 solution (e.g., Arbitrum, Optimism) or any sidechain (e.g., Polygon, 
xDai) to this address.

We have recently observed an increase in demand for an Ethereum donation 
option, both for ETH itself and for stablecoins like USDT, USDC, and DAI. As 
the largest smart-contract blockchain, largest proof-of-stake blockchain, and 
second-largest cryptocurrency by market capitalization, the Ethereum network 
and its native currency ETH are natural additions to our growing list of 
donation methods. Moreover, this new option allows users to donate any token 
they choose (including non-stablecoins!) so long as (1) the token fully 
complies with the ERC-20 standard and (2) the transaction is done on Ethereum 
Mainnet (as opposed to a Layer 2 solution or a sidechain). Please double-check 
that both of these conditions hold before sending anything to our Ethereum 
address, or else your donation may be lost!

As with our bitcoin (BTC) and monero (XMR) donation addresses, you can verify 
the authenticity of our Ethereum donation address via the [Qubes Security 
Pack](https://www.qubes-os.org/security/pack/) in the 
[fund](https://github.com/QubesOS/qubes-secpack/tree/master/fund) directory. We 
also provide detailed instructions for [verifying the digital 
signatures](https://www.qubes-os.org/security/pack/#how-to-obtain-and-authenticate).

As with all other donations, your donations on Ethereum will [directly fund the 
Qubes OS Project](https://www.qubes-os.org/donate/#how-is-my-donation-used). 
Since Qubes is free and open-source software, we do not earn any revenue by 
selling it. Instead, we rely on your financial support. If you rely on Qubes 
for secure computing in your work or personal life or see the value in our 
efforts, we would greatly appreciate your donation. Thank you!


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/09/29/qubes-os-project-now-accepting-donations-on-ethereum/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/730997aa-533d-bb26-ef0d-01fc0ecc3ca3%40qubes-os.org.

Re: [qubes-devel] qubes-doc & rtd

[Andrew David Wong]

On 9/9/22 12:52 PM, mm wrote:
> Hey Andrew,
> 
> 
> thank you for your work!!
> 

Thank *you*! :)

> So one by one:
> 
> https://github.com/maiska/qubes-doc.rtd/commit/0b8529a026da0523355eec55c57c1da2aa110d07
> 
>> By the way, with this one, the link is not actually broken. It still works, 
>> because your browser adds the missing forward slash automatically. 
>> Nonetheless, I've committed a fix to make it technically syntactically 
>> correct.
> 
> With the above commit there several links. I suppose you mean the internal 
> one:

Ah yes, I meant the first one.

> it is so, yes, but for the convenience of my stupid script..., but let me 
> explain:
> 
> Some people, when confronted with a problem, think
> “I know, I'll use regular expressions.”
> Now they have two problems.
> 
> Well :)
> 

Oh, no worries. It ought to be syntactically correct anyway. :)

>>> [...]
>>> other people's articles linking to the official Qubes OS documentation 
>>> would be broken, since I do not think that there is a proxy
>>>
>>> to handle such requests and redirects? Or there is a simpler way?
>>>
>> I don't understand why links would get broken. Let's use a concrete example 
>> to help me understand. Take this page, for example:
>>
>> https://www.qubes-os.org/doc/how-to-update/
>>
>> After the migration to RtD, wouldn't this still be the same URL for that 
>> page? Why would it be any different?
>>
>> If you're saying it has to be a different URL for some reason, what would 
>> the new URL look like?
> 
> The new url when generated will look like: 
> foo.bar/user/how-to-guides/how-to-update.html from rst will look like :doc:` 
> foo `
> 
> Domain dependent or whatever...
> 

Oh, so it will mirror the directory structure. I seem to recall that I/we once 
tried this and decided against it for some reason, but I can no longer remember 
the details. I also can't recall whether we already discussed mirroring the 
directory structure for the purpose of this RST conversion and decided to go 
ahead with it. I suppose that if it's already implemented that way, we can 
proceed with it and deal with any problems that might arise. (Worst case 
scenario, we may have to go back and re-implement this part, but hopefully we 
can just work around it.)

>>
 Wouldn't converting all Markdown files to RST result in still using the 
 _doc submodule, just with all the files converted? Maybe I'm not 
 understanding something here.
>>> This could be a possibility yes, perhaps with a sphinx plugin for 
>>> redirects. It exists, haven't tried it yet.
>>>
>> Why only "a possibility"? I figured that would be the obvious thing to do, 
>> but clearly I am missing something. If there is a good reason to do 
>> otherwise, then that's totally fine! It's just not clear to me what that 
>> reason might be.
> 
> Nope, you are abs right!
> 
> My motivation behind this solution (meaning leave the docs as they are but 
> empty etc.) was take it one step at a time w/o necessarily drain time in 
> fixing possible broken links. Till the documentation is on RTD
> 
> and afterwards the website can be dealt with and properly cleared of any 
> redundant information (such as in _includes research.html, cause i blank out 
> translated it
> 
> into flat markdown or rst),
> 
> also than use the sphinx redirect extension, these all are nice to have and 
> can be done afterwards.
> 
> The possibility was not the right word in this context...
> 
> The HCL and Downloads thus can be addressed later :)
> 

Ok, one step at a time makes sense.

> About the pull requests I will look into it latest tomorrow, render and say 
> if smth is 'missing'
> 
> 
> One thing though which I did not think about:
> 
> The privacy policy should be 2x - one for the Qubes OS website, and one for 
> RTD. The one for RTD should be adjusted and perhaps refer to also their 
> privacy policy:
> 
> https://docs.readthedocs.io/en/stable/privacy-policy.html
> 

I guess it's not obvious to me why that would be the case since we're 
self-hosting (aren't we?), but if you say we need it, then I don't see why we 
can't have two.

> 
> But maybe that's okay, since once we migrate to RtD, we'll no longer be 
> relying on custom scripts like this to populate the table of contents.
> 
> Yes!! Hopefully there will be a lot less clutter :))
> 
> 
> git clone -b new-master 
> --recursivehttps://github.com/maiska/qubesos.github.io.rtd.git
> 
> So, how do I serve the site locally after doing this? Can you provide 
> step-by-step instructions?
> 
> 
> On a fedora VM:
> 
> sudo dnf install ruby ruby-devel openssl-devel redhat-rpm-config 
> @development-tools;
> gem install jekyll bundler;
> find . -name gem; #(in my case it was /home/user/.local/share/gem/)
> git clone -b new-master --recursive 
> https://github.com/maiska/qubesos.github.io.rtd.git; cd qubesos.github.io.rtd/
> bundle config set --local path '/home/user/.local/share/gem/'
> bundle exec jekyll serve
> 

Ah, ok, it looks similar to the 

[qubes-devel] Qubes Canary 032

[Andrew David Wong]

Dear Qubes Community,

We have published Qubes Canary 032. 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 032 in the qubes-secpack:



Learn how to obtain and authenticate the qubes-secpack and all the
signatures it contains:



View all past canaries:



```

---===[ Qubes Canary 032 ]===---


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 September 13, 2022.

2. There have been 84 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 December 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
--

We plan to create a new Release Signing Key (RSK) [3] 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.


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
---

Tue, 13 Sep 2022 02:47:47 +

Source: DER SPIEGEL - International 
(https://www.spiegel.de/international/index.rss)
Poland's Prime Minister on Ukraine War and Energy Crisis
Habeck's Meltdown: Nuclear Energy Standby Proposal Has Germany's Greens Seeing 
Red
European Commissioner Gentiloni: "The Coming Winter Could Be One of the Worst 
in History"
Russian Meddling in the Balkans: "Over and Over, Putin Says Kosovo, Kosovo, 
Kosovo!"
Laos and the New Silk Road: The Train to Dependence on China

Source: NYT > World News 
(https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Ukraine’s Sudden Gains Prompt New Questions for Commanders
Russian Critics Speak Out, Prompted by Ukraine Losses
King Charles Pays Tribute to Queen Elizabeth on a Day Steeped in Tradition
Oppressive Blackouts Force Lebanese to Change Rhythm of Life
Ukraine Claims More Ground in Northeast and South

Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Ukraine war: We retook 6,000 sq km from Russia in September, says Zelensky
Ukraine war: What will Russia's losses mean for Putin?
Ukraine war: A successful surprise attack - but danger still looms
Sweden election: Result could take days as vote too close to call
Taoiseach: Queen's death 'reminder to nurture UK-Ireland relations'

Source: Blockchain.info
0002fb0e59c723277069b5389aa2df4b8ff6dc8d80da6ad4


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 

Re: [qubes-devel] qubes-doc & rtd

[Andrew David Wong]

On 9/8/22 6:15 PM, Andrew David Wong wrote:
> On 9/8/22 6:14 PM, Andrew David Wong wrote:
>> On 9/8/22 6:00 PM, Andrew David Wong wrote:
>>> On 9/7/22 6:30 PM, mm wrote:
>>>> [...]
>>>>>>> The following files will be retained at this stage, due to liquid 
>>>>>>> templating
>>>>>>> (needs some tweeking if
>>>>>>> one wishes to work with sphinx templating) and also these are perhaps 
>>>>>>> also
>>>>>>> just part of the official website not the documenation as I see it at 
>>>>>>> least
>>>>>>> atm
>>>>>>> - https://www.qubes-os.org/hcl/
>>>>>>> - https://www.qubes-os.org/downloads/
>>>>>>> - https://www.qubes-os.org/security/xsa/
>>>>>>> - https://www.qubes-os.org/security/qsb/
>>>>>>> - https://www.qubes-os.org/security/canary/
>>>>>>> - https://www.qubes-os.org/security/pgp-keys/
>>>>>> Sounds fine. IMO those should be moved to the main repo. In fact, actual
>>>>>> data for those pages is already in the main repo (_data/), just not the
>>>>>> .md file...
>>>>>>
>>>>> I think this goes back to the previous discussions we've had over the 
>>>>> years about how to organize website vs. doc content, and we landed on 
>>>>> organizing it this way for various reasons. I think one of those reasons 
>>>>> was to have everything that should be included in offline documentation 
>>>>> in qubes-doc. (So, even if the data is in `_data/`, the offline doc 
>>>>> generation tool might decide whether to include it based on whether the 
>>>>> page referencing that data is in qubes-doc or not.)
>>>>>
>>>>> Also, it might be a bit weird to have a page (/security/) in qubes-doc, 
>>>>> while its "subpages" are in the more general parent repo "above" it. So, 
>>>>> organizing based on semantic content vs. source file/data attributes will 
>>>>> get you different results.
>>>>>
>>>>> I'm sure there are many other considerations buried in our archives that 
>>>>> I'm forgetting now.
>>>>
>>>> From my part what I see is more work. It dragged itself through the years 
>>>> enough :) (Of course that is also on me)
>>>>
>>>> As soon as we get the localization workflow going and RTD is the way to go 
>>>> as discussed previously and is stable,
>>>>
>>>> one can still play with sphinx templating and incorporate the above files 
>>>> in the RST documentation. I already tried it as a simple example it 
>>>> functions, but is frustrating, and rn I do not have the nerve to sit 
>>>> through this.
>>>>
>>>> Perhaps some volunteers will come forward at the summit :)
>>>>
>>>
>>> Ok, if it's too much trouble to get the tech working correctly, then that's 
>>> probably a good enough reason to just move these files. I don't mind.
>>>
>>>> Why I see them as a part of the website is the following: downloads, xsa, 
>>>> qsb, canary and pgp-keys are somewhat essential to security of the 
>>>> project, not truly documentation as I see it atm
>>>>
>>>
>>> Well, I don't know if that holds for all of these, because at least some 
>>> parts of those pages are clearly documentation explaining what XSAs are, 
>>> what QSBs are, what canaries are, how we handle them, and so on.
>>>
>>> But the other technical reason you gave enough is a separate and probably 
>>> good enough on its own.
>>>
>>> Ok, I've just moved these pages to the main repo and deleted the ones we 
>>> don't need.
>>>
>>>> HCL is documentation yes, there I just make my life easier
>>>>
>>>
>>> Yes, making life easier is probably more important at this stage. :)
>>>
>>> (Btw, I'm assuming you meant *not* documentation, since above you listed 
>>> the HCL page as one that you said *should* be moved to the main repo, which 
>>> makes sense because it is indeed "empty" with all the data stored 
>>> elsewhere. So, I've just moved it along with the others.)
>>>
>>
>> Ah, I already see one side effect of moving these pages to the main repo: 
>> They can no longer appear in the doc index, probably because the script that 
>> populates the doc index only checks for files in qubes-doc, which is 
>> probably one of the reasons we had them there in the first place
> 
> But maybe that's okay, since once we migrate to RtD, we'll no longer be 
> relying on custom scripts like this to populate the table of contents. :)

Well, I guess I better move back at least the Downloads and HCL pages, since 
having those in the index is pretty important. I guess the others can stay in 
the main repo, since they're linked from the Security Center page.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/b78f4cc0-f38d-1445-ca01-d38a965be3e7%40qubes-os.org.

Re: [qubes-devel] qubes-doc & rtd

[Andrew David Wong]

On 9/7/22 6:30 PM, mm wrote:
> and the clone should go recursive if you want to try it out locally
> 
> git clone -b new-master --recursive 
> https://github.com/maiska/qubesos.github.io.rtd.git
> 

So, how do I serve the site locally after doing this? Can you provide 
step-by-step instructions?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/feffd9bb-a010-8f05-105e-272eccb12739%40qubes-os.org.

Re: [qubes-devel] qubes-doc & rtd

[Andrew David Wong]

On 9/8/22 6:14 PM, Andrew David Wong wrote:
> On 9/8/22 6:00 PM, Andrew David Wong wrote:
>> On 9/7/22 6:30 PM, mm wrote:
>>> [...]
>>>>>> The following files will be retained at this stage, due to liquid 
>>>>>> templating
>>>>>> (needs some tweeking if
>>>>>> one wishes to work with sphinx templating) and also these are perhaps 
>>>>>> also
>>>>>> just part of the official website not the documenation as I see it at 
>>>>>> least
>>>>>> atm
>>>>>> - https://www.qubes-os.org/hcl/
>>>>>> - https://www.qubes-os.org/downloads/
>>>>>> - https://www.qubes-os.org/security/xsa/
>>>>>> - https://www.qubes-os.org/security/qsb/
>>>>>> - https://www.qubes-os.org/security/canary/
>>>>>> - https://www.qubes-os.org/security/pgp-keys/
>>>>> Sounds fine. IMO those should be moved to the main repo. In fact, actual
>>>>> data for those pages is already in the main repo (_data/), just not the
>>>>> .md file...
>>>>>
>>>> I think this goes back to the previous discussions we've had over the 
>>>> years about how to organize website vs. doc content, and we landed on 
>>>> organizing it this way for various reasons. I think one of those reasons 
>>>> was to have everything that should be included in offline documentation in 
>>>> qubes-doc. (So, even if the data is in `_data/`, the offline doc 
>>>> generation tool might decide whether to include it based on whether the 
>>>> page referencing that data is in qubes-doc or not.)
>>>>
>>>> Also, it might be a bit weird to have a page (/security/) in qubes-doc, 
>>>> while its "subpages" are in the more general parent repo "above" it. So, 
>>>> organizing based on semantic content vs. source file/data attributes will 
>>>> get you different results.
>>>>
>>>> I'm sure there are many other considerations buried in our archives that 
>>>> I'm forgetting now.
>>>
>>> From my part what I see is more work. It dragged itself through the years 
>>> enough :) (Of course that is also on me)
>>>
>>> As soon as we get the localization workflow going and RTD is the way to go 
>>> as discussed previously and is stable,
>>>
>>> one can still play with sphinx templating and incorporate the above files 
>>> in the RST documentation. I already tried it as a simple example it 
>>> functions, but is frustrating, and rn I do not have the nerve to sit 
>>> through this.
>>>
>>> Perhaps some volunteers will come forward at the summit :)
>>>
>>
>> Ok, if it's too much trouble to get the tech working correctly, then that's 
>> probably a good enough reason to just move these files. I don't mind.
>>
>>> Why I see them as a part of the website is the following: downloads, xsa, 
>>> qsb, canary and pgp-keys are somewhat essential to security of the project, 
>>> not truly documentation as I see it atm
>>>
>>
>> Well, I don't know if that holds for all of these, because at least some 
>> parts of those pages are clearly documentation explaining what XSAs are, 
>> what QSBs are, what canaries are, how we handle them, and so on.
>>
>> But the other technical reason you gave enough is a separate and probably 
>> good enough on its own.
>>
>> Ok, I've just moved these pages to the main repo and deleted the ones we 
>> don't need.
>>
>>> HCL is documentation yes, there I just make my life easier
>>>
>>
>> Yes, making life easier is probably more important at this stage. :)
>>
>> (Btw, I'm assuming you meant *not* documentation, since above you listed the 
>> HCL page as one that you said *should* be moved to the main repo, which 
>> makes sense because it is indeed "empty" with all the data stored elsewhere. 
>> So, I've just moved it along with the others.)
>>
> 
> Ah, I already see one side effect of moving these pages to the main repo: 
> They can no longer appear in the doc index, probably because the script that 
> populates the doc index only checks for files in qubes-doc, which is probably 
> one of the reasons we had them there in the first place

But maybe that's okay, since once we migrate to RtD, we'll no longer be relying 
on custom scripts like this to populate the table of contents. :)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/55fa0e9b-df03-175f-0b85-7b5c991f9bc7%40qubes-os.org.

Re: [qubes-devel] qubes-doc & rtd

[Andrew David Wong]

On 9/8/22 6:00 PM, Andrew David Wong wrote:
> On 9/7/22 6:30 PM, mm wrote:
>> [...]
>>>>> The following files will be retained at this stage, due to liquid 
>>>>> templating
>>>>> (needs some tweeking if
>>>>> one wishes to work with sphinx templating) and also these are perhaps also
>>>>> just part of the official website not the documenation as I see it at 
>>>>> least
>>>>> atm
>>>>> - https://www.qubes-os.org/hcl/
>>>>> - https://www.qubes-os.org/downloads/
>>>>> - https://www.qubes-os.org/security/xsa/
>>>>> - https://www.qubes-os.org/security/qsb/
>>>>> - https://www.qubes-os.org/security/canary/
>>>>> - https://www.qubes-os.org/security/pgp-keys/
>>>> Sounds fine. IMO those should be moved to the main repo. In fact, actual
>>>> data for those pages is already in the main repo (_data/), just not the
>>>> .md file...
>>>>
>>> I think this goes back to the previous discussions we've had over the years 
>>> about how to organize website vs. doc content, and we landed on organizing 
>>> it this way for various reasons. I think one of those reasons was to have 
>>> everything that should be included in offline documentation in qubes-doc. 
>>> (So, even if the data is in `_data/`, the offline doc generation tool might 
>>> decide whether to include it based on whether the page referencing that 
>>> data is in qubes-doc or not.)
>>>
>>> Also, it might be a bit weird to have a page (/security/) in qubes-doc, 
>>> while its "subpages" are in the more general parent repo "above" it. So, 
>>> organizing based on semantic content vs. source file/data attributes will 
>>> get you different results.
>>>
>>> I'm sure there are many other considerations buried in our archives that 
>>> I'm forgetting now.
>>
>> From my part what I see is more work. It dragged itself through the years 
>> enough :) (Of course that is also on me)
>>
>> As soon as we get the localization workflow going and RTD is the way to go 
>> as discussed previously and is stable,
>>
>> one can still play with sphinx templating and incorporate the above files in 
>> the RST documentation. I already tried it as a simple example it functions, 
>> but is frustrating, and rn I do not have the nerve to sit through this.
>>
>> Perhaps some volunteers will come forward at the summit :)
>>
> 
> Ok, if it's too much trouble to get the tech working correctly, then that's 
> probably a good enough reason to just move these files. I don't mind.
> 
>> Why I see them as a part of the website is the following: downloads, xsa, 
>> qsb, canary and pgp-keys are somewhat essential to security of the project, 
>> not truly documentation as I see it atm
>>
> 
> Well, I don't know if that holds for all of these, because at least some 
> parts of those pages are clearly documentation explaining what XSAs are, what 
> QSBs are, what canaries are, how we handle them, and so on.
> 
> But the other technical reason you gave enough is a separate and probably 
> good enough on its own.
> 
> Ok, I've just moved these pages to the main repo and deleted the ones we 
> don't need.
> 
>> HCL is documentation yes, there I just make my life easier
>>
> 
> Yes, making life easier is probably more important at this stage. :)
> 
> (Btw, I'm assuming you meant *not* documentation, since above you listed the 
> HCL page as one that you said *should* be moved to the main repo, which makes 
> sense because it is indeed "empty" with all the data stored elsewhere. So, 
> I've just moved it along with the others.)
> 

Ah, I already see one side effect of moving these pages to the main repo: They 
can no longer appear in the doc index, probably because the script that 
populates the doc index only checks for files in qubes-doc, which is probably 
one of the reasons we had them there in the first place

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/d7a89487-2aa3-466d-a179-0e1968b22f37%40qubes-os.org.

Re: [qubes-devel] qubes-doc & rtd gems

[Andrew David Wong]

On 9/7/22 6:45 PM, mm wrote:
> Hello again,
> 
> here in a clear manner some suggestions.
> 
> What do you think?
> 
>>>
>>> Qubes builder -- probably a subpage linked from a main page
> is actually Qubes builder details, could be hosted in the Building section?
> 
>>> Join -- intentionally hidden when active recruiting stopped (to be unhidden 
>>> if/when it resumes)
> 
> Should it than be just part of the Qubes OS Website and not the docs?
> 
> 
>>> Admin API Table -- it's an "embed" on the Admin API page (just a hack to 
>>> allow opening that huge table by itself in the "fullscreen" layout)
> 
> Could go below Admin API in the index?
> 
> 
>>> Disposable VM Implementation -- not sure
> Somewhere in developer's sections?
>>> Qrexec2 -- not sure
> Somewhere in developer's sections?
>>> Qfileexchgd -- not sure
> Somewhere in developer's sections?
>>> Code of Conduct -- linked from footer, as Marek said; would be okay to link 
>>> from index
> Perhaps in Introduction section ?
>>> Intro -- linked from "nav bar" at the very top of the website
> Perhaps in Introduction section ?
>>> Privacy -- intentional footer link, like every other website
> Perhaps in Introduction section ? for now after that somehow in the footer
>>> Screenshots -- linked from Intro; would be okay to link from index
> Perhaps in Introduction section ?
>>> Statistics -- linked from News page; would be okay to link from index
> Perhaps in Introduction section ?
>>> Video Tours -- linked from Intro; would be okay to link from index
> Perhaps in Introduction section ?
>>> QSB Checklist -- checklist for internal use; probably not of interest to 
>>> users; would just be clutter in the index
> Go to the official Qubes OS Website?
>>> Canary Checklist -- same
> Go to the official Qubes OS Website?
>>> Download mirrors -- table embedded on Downloads page
> hm ok obsolete
>>> Custom install -- linked from Installation Guide; would be okay to link 
>>> from index
> in Downloading, Installing, and Upgrading Qubes section?
>>> Install security -- linked from Installation Guide; would be okay to link 
>>> from index
> in Downloading, Installing, and Upgrading Qubes section?
>>> How to use the hcl -- linked from HCL page; would be okay to link from index
> Choosing your hardware section?
>>> How to reinstall a template -- subpage linked from Templates page
> Templates section?
>>> Debian template -- this page is already linked from the index; not sure why 
>>> it was miscategorized as a hidden gem
> ja, idk, mistake
>>> Debian upgrade -- in-plage upgrade guide subpage linked from Debian page
> Templates section?
>>> Fedora upgrade -- in-plage upgrade guide subpage linked from Fedora page
> Templates section?
>>> Fedora -- this page is already linked from the index; not sure why it was 
>>> miscategorized as a hidden gem
> ja, idk, mistake
>>> Update Debian Whonix -- looks like this got missed in the contributor 
>>> overhaul of troubleshooting documentation that occurred a while back; it 
>>> might just be outdated now
> 
> Templates section?
> 

Thanks for the suggestions. I believe I have taken care of all of these:

https://github.com/QubesOS/qubes-doc/pull/1267
https://github.com/QubesOS/qubesos.github.io/pull/204

Please let me know if I missed any.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/4e5fab0b-f974-48df-d7a0-c2a259022c24%40qubes-os.org.