[qubes-users] "Automated OS testing on physical laptops" by Marek Marczykowski-Górecki

[Andrew David Wong]

Dear Qubes Community,

A new article has just been published on the Qubes website:

"Automated OS testing on physical laptops"
by Marek Marczykowski-Górecki
https://www.qubes-os.org/news/2022/05/05/automated-os-testing-on-physical-laptops/

The original Markdown source is reproduced below as a courtesy to plain 
text email readers.


=8<=

---
layout: post
title: "Automated OS testing on physical laptops"
categories: articles
author: Marek Marczykowski-Górecki
image: /attachment/posts/openqa-hw-power-button.jpg
---

Our journey towards automating OS tests on physical laptops started a 
few years

ago with the idea of using Intel AMT to drive tests on physical machines. To
start, I got an [initial
implementation](https://github.com/os-autoinst/os-autoinst/pull/983) 
working.
In particular, VNC for input/output and power control worked. I tried to 
get a
virtual CD working, but it turned out to be quite unstable. Worse --- 
and more

importantly --- it was really just a CD, not a CD/DVD, which meant that the
protocol couldn't handle images larger than 2 GB. Some time later I 
abandoned

this approach, for two related reasons:

1. Many machines that we want Qubes OS to support intentionally do not have
   Intel AMT.
2. The single AMT-enabled machine that I had been using to develop this 
feature

   broke.

If anyone would like to resume this work, [this
page](https://web.archive.org/web/20200926070850/senseless.info/amt.html)
includes _a lot_ of useful info about Intel AMT on Linux.

Recently, I came back to the project with a new approach: to capture 
video from
HDMI output and use an emulated USB keyboard and mouse for input. Then, 
I added

power control to the mix, combined everything on a Raspberry Pi, and got a
[working 
prototype](https://github.com/os-autoinst/os-autoinst/pull/1741) of an
openQA worker that runs the tests on a physical machine, instead of a 
virtual

one.

The whole setup includes several devices:

- One "central" Raspberry Pi that controls a power strip and serves boot 
files.

- One Raspberry Pi per laptop that runs an openQA worker for that laptop. It
  emulates a USB device for that laptop and captures HDMI output from it.

All these elements are detailed below.

## Base system

The goal was to run an openQA worker on a Raspberry Pi 4. Why a Raspberry Pi
(RPi)?

- Their USB controllers can play the role of a device, not just that of USB
  host.
- They're powerful enough to run the video processing required by openQA.
- They're (mostly) readily available and relatively cheap.

As a base system, I chose OpenSUSE, because that's openQA's native
distribution. Getting OpenSUSE to work on an RPi was [rather
straightforward](https://en.opensuse.org/HCL:Raspberry_Pi4), but the 
choice did

lead to a few issues discussed later in this article.

## Power control

Power control was the first stage of this project. I thought it looked 
like the

simplest part.

To reliably run unattended tests, I needed a way to interrupt a test when it
went into some unrecoverable state (kernel panic, hard hang, etc.). With 
AMT, I
had a built-in API for that, but now I needed something else. I chose a 
power
strip that was remotely controlled via USB. Then, I removed the 
batteries from

the laptops connected to the setup. This gave me a very reliable way to
interrupt whatever was running on the machines by simply powering them down.
But it turned out that powering them back on may not be that simple.

In the current setup, there are several laptops, each of them slightly
different, and each (sic!) requiring a slightly different approach to power
management. Here are some things I tried and that worked on some machines:

1. Setting the BIOS to automatically power on the machine when a power 
supply
   was connected. This is the simplest method. Sadly, only one of the 
machines

   supported it.
2. Sending a Wake-On-Lan packet. Here, reliability depends on the 
device. For
   some, it just works, while others require enabling it in the network 
card
   (with the `ethtool -s eth0 wol g` command), and some lose the 
setting either

   on system startup or on disconnecting the power...
3. When all else fails, one can just press the physical power button. Of 
course
   it would be too much work to do it manually, so I attached a servo 
motor in

   the exact spot where the power button is. Then, I drove that servo motor
   from an RPi.

[![Power button 
servo](/attachment/posts/openqa-hw-power-button.jpg)](/attachment/posts/openqa-hw-power-button.jpg)


## System startup

After achieving control over system power, the next step was taking 
control of

which operating system starts there. I considered two options:

- A USB boot drive, emulated from an RPi
- Network boot

The first option turned out to be problematic when combined with 
emulated USB
input devices (see below), at least on some laptops. While a single USB 
device

can have multiple 

[qubes-users] Whonix support for Qubes 4.0 has ended

[Andrew David Wong]

Dear Qubes Community,

As a final reminder following our previous announcements [1][2], Whonix
support for Qubes 4.0 ends today, 2022-04-20.

## How does Whonix support work?

While Qubes OS releases are supported for six months [3] following each
subsequent major or minor release, Whonix templates have their own
support policy [4] set by the Whonix Project. This policy requires
Whonix template users to stay reasonably close to the cutting edge by
upgrading to new stable releases of Qubes OS and Whonix templates within
a month of their respective releases. To be precise:

- One month after a new stable version of Qubes OS is released, Whonix
  templates are no longer supported on any older release of Qubes OS.
  This means that users who wish to continue using Whonix templates on
  Qubes are usually required to upgrade to the latest stable Qubes OS
  version within one month of its release (unless the deadline is
  extended, as it has been in this case).

- One month after new stable versions of Whonix templates are released,
  older releases of Whonix templates are no longer supported. This means
  that users who wish to continue using Whonix templates on Qubes are
  usually required to upgrade to the latest stable Whonix template
  versions within one month of their release. (This point doesn't apply
  to the present situation, since this announcement pertains to a new
  Qubes OS release, not a new Whonix template release. However, I'm
  mentioning it here for the sake of completeness, as it's part of the
  Whonix support policy.)

## What does this mean for you?

If you're currently using Whonix on Qubes 4.0, you should immediately
either upgrade to Qubes 4.1 [5] or discontinue the use of Whonix.

If you're already on Qubes 4.1, or you don't use Whonix templates,
then you're all set. This announcement doesn't change anything for you.


[1] 
https://www.qubes-os.org/news/2022/02/04/qubes-4-1-0/#support-for-older-releases
[2] 
https://www.qubes-os.org/news/2022/03/17/whonix-support-for-qubes-4-0-extended/

[3] https://www.qubes-os.org/doc/supported-releases/#qubes-os
[4] https://www.qubes-os.org/doc/supported-releases/#note-on-whonix-support
[5] https://www.qubes-os.org/doc/upgrade/4.1/

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/04/20/whonix-support-for-qubes-4-0-has-ended/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ff13512e-ce28-ac54-edfd-9b7215b5caf1%40qubes-os.org.

[qubes-users] "Windows integration work in Qubes 4.1 by the tabit-pro team" by Ivan Kardykov

[Andrew David Wong]

Dear Qubes Community,

We've just published a new guest article by Ivan Kardykov from
tabit-pro, who we've invited to explain the work
the tabit-pro team contributed to Qubes 4.1.


"Windows integration work in Qubes 4.1 by the tabit-pro team"
by Ivan Kardykov
https://www.qubes-os.org/news/2022/04/10/windows-integration-by-tabit-pro/


The Markdown source of the article is reproduced below as a courtesy to 
plain text email readers.


8<

In this article, I'll briefly describe the code contributions we made to
the latest Qubes 4.1 release, most of which focus on improving Windows
integration.

## OEM activation support

When Windows comes preinstalled on a computer, license activation is
based on a certificate embedded in the hardware. Technically, this uses
one of the ACPI tables called "SLIC," which is readable by the host OS.
This option is not available in Qubes OS, since each qube is a Xen
virtual machine (VM) that has no physical hardware of its own. However,
a small change in Xen allowed us to copy the necessary data onto the
appropriate memory partition of the VM (thanks to OpenXT for the working
patch). This can be done simply by [extending the VM configuration with
the SLIC data via the libvirt template
extension](https://github.com/QubesOS/qubes-issues/issues/5279#issuecomment-525947408).
This fix has been included in stable packages for a long time. In fact,
it is also available for Qubes 4.0 users.

## Audio support

Audio virtualization in Qubes OS is based on communication between
PulseAudio services running in each VM, including dom0 (described in
more detail [here](https://www.qubes-os.org/doc/audio-virtualization/)). 
Unfortunately, this

method is problematic in the case of Windows VMs due to the lack of
PulseAudio support in Windows, and attempting to support it
independently seems like too time-consuming of a task (see
[#2624](https://github.com/QubesOS/qubes-issues/issues/2624)).

An alternative is to use QEMU, which allows for the emulation of
different audio devices and docking with PulseAudio. In our case, the
main obstacle for this method is the complexity of the connection to
QEMU, which is isolated by a stubdomain. We developed a patch that
allows for building and starting the necessary components for PulseAudio
in a minimal environment with vchan support. We also worked out a
separate version for building the stubdomain image with extended
functionality (the `xen-hvm-stubdom-linux-full` package). This mode is
activated in HVMs by setting the `audio-model` feature (using
`qvm-features`) and specifying the type of audio device, for example,
`ich6`. (Device variants are described in the QEMU documentation.)

## USB support

We used a similar approach to improve support for USB devices. In the
extended stubdomain, we proposed including qrexec and USB-proxy services
and including libusb features in QEMU (see
[qubes-app-linux-usb-proxy](https://github.com/QubesOS/qubes-app-linux-usb-proxy)).
As a result, we didn't even need to increase the available memory in
order to achieve stable operation of the extended stubdomain, although
it may be a problem when using some devices (e.g., webcams). There was a
question of which controller type QEMU should emulate. After
experimenting with different devices, we settled on the NEC XHCI, in
part due to the availability of Windows 7 drivers. The activation of
this emulation mode in HVMs is done by setting the `stubdom-qrexec`
property (using `qvm-features`). Details of user testing can be found on
the [Qubes
Forum](https://forum.qubes-os.org/t/windows-usb-integration-with-r4-1/5001).

## Not only Windows

The advantage of this approach is that there is no need to install guest
tools for attaching audio and USB devices, which allows the emulation to
be used not only with Windows, but with any OS (e.g., Linux live images,
Android x86, and probably ReactOS).  At the same time, there are also
disadvantages. In particular, the additional workload can slow down the
VM and affect the sound quality. (Even at minimum workload, you may
notice crackling.)

## Qubes Windows Tools

A relatively long time ago, we proposed building all the components of
Qubes Windows Tools (QWT) in a Linux environment using MinGW and Wine,
which allows us to use our existing CI tools and simplify the
maintenance of changes. We also worked a lot on improving the stability
of all the components, in particular, eliminating the causes of freezes
and performance degradation. In recent weeks, all of our proposed
changes have been approved and merged, and the
[cross-build](https://github.com/QubesOS/qubes-windows-tools-cross)
project has been added as a Qubes OS component. I'm sure everything will
be available in the stable repositories soon.

## Conclusion

The result of our work is full integration of Windows 7, 10, and 11 in
Qubes OS and significant improvements in usability for even
inexperienced users.

Thanks to 

[qubes-users] XSAs released on 2022-04-05

[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 affect the security of Qubes OS (user action required)


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

- XSA-399
- XSA-400

Please see *QSB-079* for the actions users must take in order to
protect themselves, as well as further details about these XSAs:

<https://www.qubes-os.org/news/2022/04/05/qsb-079/>


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-397 (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/04/05/xsas-released-on-2022-04-05/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/07a2f016-7584-51e0-14d3-2c58f42fe909%40qubes-os.org.

[qubes-users] QSB-079: Two IOMMU-related Xen issues (XSA-399, XSA-400)

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 079: Two IOMMU-
related Xen issues (XSA-399, XSA-400). The text of this QSB is
reproduced below. This QSB and its accompanying signatures will always
be available in the Qubes Security Pack (qubes-secpack).

View QSB-079 in the qubes-secpack:



In addition, you may wish to:

- Get the qubes-secpack: 
- View all past QSBs: 
- View the XSA Tracker: 

```

 ---===[ Qubes Security Bulletin 079 ]===---

 2022-04-05

Two IOMMU-related Xen issues (XSA-399, XSA-400)


User action required
-

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

  For Qubes 4.0, in dom0:
  - Xen packages, version 4.8.5-39

  For Qubes 4.1, in dom0:
  - Xen packages, version 4.14.4-4

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]

Dom0 must be restarted afterward in order for the updates to take
effect.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.


Summary


The following security advisories were published on 2022-04-05:

XSA-399 [3] "race in VT-d domain ID cleanup":

| Xen domain IDs are up to 15 bits wide.  VT-d hardware may allow for only
| less than 15 bits to hold a domain ID associating a physical device with
| a particular domain.  Therefore internally Xen domain IDs are mapped to
| the smaller value range.  The cleaning up of the housekeeping structures
| has a race, allowing for VT-d domain IDs to be leaked and flushes to be
| bypassed.


XSA-400 [4] "IOMMU: RMRR (VT-d) and unity map (AMD-Vi) handling
issues":

| Certain PCI devices in a system might be assigned Reserved Memory
| Regions (specified via Reserved Memory Region Reporting, "RMRR") for
| Intel VT-d or Unity Mapping ranges for AMD-Vi.  These are typically used
| for platform tasks such as legacy USB emulation.
|
| Since the precise purpose of these regions is unknown, once a device
| associated with such a region is active, the mappings of these regions
| need to remain continuouly accessible by the device.  This requirement
| has been violated.
|
| Subsequent DMA or interrupts from the device may have unpredictable
| behaviour, ranging from IOMMU faults to memory corruption.


Impact
---

The precise impact of XSA-399 and XSA-400 is system-specific but
would typically be a denial of service (DoS) affecting the entire
host. Privilege escalation and information leaks cannot be ruled out.

XSA-399 affects only Qubes OS 4.1. Qubes OS 4.0 is not affected due to
the version of Xen it uses. This issue affects only qubes with assigned
PCI devices, which are sys-net and sys-usb in the default Qubes OS
configuration.

XSA-400 affects both Qubes OS 4.0 and 4.1. It affects only qubes with
assigned PCI devices that have an associated RMRR or unity map. This
usually applies to USB controllers, which are assigned to the sys-usb
qube in the default Qubes OS configuration.


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-399.html
[4] https://xenbits.xen.org/xsa/advisory-400.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/04/05/qsb-079/

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8d619029-30c1-02bd-dffd-3424bc41d894%40qubes-os.org.

[qubes-users] Qubes OS configuration survey! (5-10 minutes)

[Andrew David Wong]

Dear Qubes Community,

I'm writing to share the following announcement from Marta 
Marczykowska-Górecka:


-

We're working on a simpler, more user-friendly Qubes OS configuration
experience. We invite you all to lend us 5-10 minutes of your time to
participate in this 100% anonymous survey. Your participation will help
us build better GUI tools for system configuration that meet real user
needs. This survey will remain live for 28 days. Thank you!

https://survey.qubes-os.org/index.php?r=survey/index=762843=en

-

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/03/23/qubes-os-configuration-survey/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/56858924-60af-b175-3a94-41be9e83c18e%40qubes-os.org.

[qubes-users] Whonix support for Qubes 4.0 extended

[Andrew David Wong]

Dear Qubes Community,

The Whonix Project has extended its support for Whonix templates on
Qubes 4.0 by an additional month to 2022-04-20. This comes after an
initial 16-day extension when the release of Qubes 4.1 was originally
announced [1].


## How does Whonix support work?

While Qubes OS releases are supported for six months [2] following each
subsequent major or minor release, Whonix templates have their own
support policy [3] set by the Whonix Project. This policy requires
Whonix template users to stay reasonably close to the cutting edge by
upgrading to new stable releases of Qubes OS and Whonix templates within
a month of their respective releases. To be precise:

- One month after a new stable version of Qubes OS is released, Whonix
  templates are no longer supported on any older release of Qubes OS.
  This means that users who wish to continue using Whonix templates on
  Qubes are usually required to upgrade to the latest stable Qubes OS
  version within one month of its release (unless the deadline is
  extended, as it has been in this case).

- One month after new stable versions of Whonix templates are released,
  older releases of Whonix templates are no longer supported. This means
  that users who wish to continue using Whonix templates on Qubes are
  usually required to upgrade to the latest stable Whonix template
  versions within one month of their release. (This point doesn't apply
  to the present situation, since this announcement pertains to a new
  Qubes OS release, not a new Whonix template release. However, I'm
  mentioning it here for the sake of completeness, as it's part of the
  Whonix support policy.)


## What does this mean for you?

If you haven't upgraded from Qubes 4.0 to Qubes 4.1 yet, and you use
Whonix templates, this extension means you have a bit more time to
upgrade before your Whonix templates are no longer supported. You should
aim to upgrade to Qubes 4.1 (or discontinue use of Whonix templates) by
2022-04-20.

If you're already on Qubes 4.1 or you don't use Whonix templates, you're
all set. This announcement doesn't change anything for you.


[1] https://www.qubes-os.org/news/2022/02/04/qubes-4-1-0/
[2] https://www.qubes-os.org/doc/supported-releases/#qubes-os
[3] https://www.qubes-os.org/doc/supported-releases/#note-on-whonix-support

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/03/17/whonix-support-for-qubes-4-0-extended/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/aa394bda-2197-f8ad-490a-ed67e53952e1%40qubes-os.org.

Re: [qubes-users] How to use optical media (audio CDs and CDR, DVD, etc...) in qubes?

[Andrew David Wong]

On 3/13/22 1:14 PM, Demi Marie Obenour wrote:

On Sun, Mar 13, 2022 at 08:10:23PM +, 'awokd' via qubes-users wrote:

Peter Funk:



So for the moment I've given up any hope that I could use my builtin
bluray drive of my laptop in Qubes-OS to work with any optical media.

The next thing I tried was to plug an external USB optical
drive into one of the USB ports.

This also appears fine in the device manager menu similar to the builtin
optical drive before when I put a audio media into that one.

I can assign this sys-usb:sr0 device to the qube with the gnome sound
juicer application installed.

However this will not work either, because the virtual block device
(/dev/xvdi in my case) appears not have some magical properties of
a real audio cdrom this application seems to expect.



USB drive may be accessible to apps run within sys-usb, which is a bit
better than running them in dom0.


You might also be able to use USB pass-through.  That said, is there any
chance that SCSI pass-through could be supported, Marek?



Follow-up issue (for anyone following this thread):

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

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4b6c77d9-a4b4-a264-b912-77545f17fa4a%40qubes-os.org.

[qubes-users] QSB-078: Linux kernel PV driver issues and LVM misconfiguration

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 078: Linux kernel
PV driver issues and LVM misconfiguration. The text of this QSB is
reproduced below. This QSB and its accompanying signatures will always
be available in the Qubes Security Pack (qubes-secpack).

View QSB-078 in the qubes-secpack:



In addition, you may wish to:

- Get the qubes-secpack: 
- View all past QSBs: 
- View the XSA Tracker: 

```

 ---===[ Qubes Security Bulletin 078 ]===---

  2022-03-10

   Linux kernel PV driver issues and LVM misconfiguration


User action required
-

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

  For Qubes 4.0, in dom0:
  - Kernel packages, versions 5.4.183-2, 5.16.13-2, 4.19.233-2
  - LVM2 packages, version 2.02.167-4

  For Qubes 4.1, in dom0:
  - Kernel packages, versions 5.10.104-2, 5.16.13-2
  - LVM2 packages, version 2.03.09-2

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]

A system restart is required 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
Dom0 kernel binaries.

By default, qube kernels are provided by dom0. However, advanced users
may instead opt to install a different kernel inside of a qube, e.g.,
from an upstream distribution like Fedora or Debian. [3] Such users
should consult that distribution's update channels for any kernel
updates that might be relevant to this bulletin.

In addition, advanced users with customized setups are advised that the
LVM patch changes the LVM's default value for "global_filter" [5]. This
means you must ensure that the device that contains the LVM with Qubes'
rootfs is allowed, or else your system will not boot.


Summary


On 2022-03-10, the Xen project published XSA-396, "Linux PV device
frontends vulnerable to attacks by backends" [4]:

| Several Linux PV device frontends are using the grant table interfaces
| for removing access rights of the backends in ways being subject to
| race conditions, resulting in potential data leaks, data corruption
| by malicious backends, and denial of service triggered by malicious
| backends:
|
| blkfront, netfront, scsifront and the gntalloc driver are testing
| whether a grant reference is still in use. If this is not the case,
| they assume that a following removal of the granted access will always
| succeed, which is not true in case the backend has mapped the granted
| page between those two operations. As a result the backend can keep
| access to the memory page of the guest no matter how the page will be
| used after the frontend I/O has finished. The xenbus driver has a
| similar problem, as it doesn't check the success of removing the
| granted access of a shared ring buffer.
| blkfront: CVE-2022-23036
| netfront: CVE-2022-23037
| scsifront: CVE-2022-23038
| gntalloc: CVE-2022-23039
| xenbus: CVE-2022-23040
|
| blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront,
| and pvcalls are using a functionality to delay freeing a grant
| reference until it is no longer in use, but the freeing of the related
| data page is not synchronized with dropping the granted access. As a
| result the backend can keep access to the memory page even after it
| has been freed and then re-used for a different purpose.
| CVE-2022-23041
|
|
| netfront will fail a BUG_ON() assertion if it fails to revoke access
| in the rx path. This will result in a Denial of Service (DoS)
| situation of the guest which can be triggered by the backend.
| CVE-2022-23042

As a separate matter, there is a misconfiguration in the Linux Volume
Manager (LVM) in dom0 that affects certain custom storage configurations
(see below). In affected systems, the LVM fails to ignore devices that
are controlled by other qubes. This exposes the LVM metadata parser in
dom0 to untrusted data, which could, hypothetically, be exploited in
combination with an another vulnerability and which may result in the
LVM becoming "confused" about which devices it should use.


Impact
---

Regarding XSA-396, due to race conditions and missing tests of return
codes in the Linux PV device frontend drivers, a malicious backend could
gain access (both read and write) to memory pages to which it should not
have such access, or it could directly trigger a denial of service (DoS)
in the qube in which it is running. A backend gaining full control over
its frontend 

[qubes-users] XSAs released on 2022-03-10

[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 affect the security of Qubes OS (user action required)


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

- XSA-396

Please see *QSB-078* for the actions users must take in order to
protect themselves, as well as further details about these XSAs:




XSAs that do not affect the security of Qubes OS (no user action required)
--

The following XSAs *do not affect* the security of Qubes OS, and no user 
action is necessary:


- (None)


Related links
-

- Xen XSA list: 
- 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/03/10/xsas-released-on-2022-03-10/

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/700c87a4-6cba-60b9-7431-9cf9b39221be%40qubes-os.org.

[qubes-users] XSAs released on 2022-03-08

[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 affect the security of Qubes OS (user action required)


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

- XSA-398

Please see *QSB-077* for the actions users must take in order to
protect themselves, as well as further details about these XSAs:




XSAs that do not affect the security of Qubes OS (no user action required)
--

The following XSAs *do not affect* the security of Qubes OS, and no user 
action is necessary:


- (None)


Related links
-

- Xen XSA list: 
- 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/03/10/xsas-released-on-2022-03-08/

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0416a551-e9f9-0010-c267-893c52a646d6%40qubes-os.org.

[qubes-users] QSB-077: Multiple speculative security issues (XSA-398)

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 077: Multiple
speculative security issues (XSA-398). The text of this QSB is
reproduced below. This QSB and its accompanying signatures will always
be available in the Qubes Security Pack (qubes-secpack).

View QSB-077 in the qubes-secpack:



In addition, you may wish to:

- Get the qubes-secpack: 
- View all past QSBs: 
- View the XSA Tracker: 

```

 ---===[ Qubes Security Bulletin 077 ]===---

 2022-03-09

 Multiple speculative security issues (XSA-398)


User action required
-

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

  For Qubes 4.0, in dom0:
  - Xen packages, version 4.8.5-38

  For Qubes 4.1, in dom0:
  - Xen packages, version 4.14.4-2

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]

Dom0 must be restarted afterward in order for the updates to take
effect.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.

Note: As of the publication date of this QSB, the Xen Project's patches
for XSA-398 are incomplete. Specifically, they do not protect systems
running on CET-capable Intel platforms (11th generation and later). This
limitation affects Qubes 4.1 but not Qubes 4.0. In light of this
situation, we have decided to push both the complete 4.0 patches and the
incomplete 4.1 patches to the security-testing repository immediately.
The Xen Project expects to make complete patches available in the near
future. We will push the complete 4.1 patches as soon as possible after
they become available to us.

Summary


On 2022-03-08, the Xen Project published XSA-398, "Multiple
speculative security issues" [3]:

| 1) Researchers at VU Amsterdam have discovered Spectre-BHB, pertaining
|to the use of Branch History between privilege levels.
|
|ARM have assigned CVE-2022-23960.  Intel have assigned CVE-2022-0001
|(Branch History Injection) and CVE-2022-0002 (Intra-mode BTI).  AMD
|have no statement at the time of writing.
|
|For more details, see:
|  https://vusec.net/projects/bhi-spectre-bhb
| 
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
| 
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00598.html

|
| 2) Researchers at Open Source Security, Inc. have discovered that AMD
|CPUs may speculate beyond direct branches.
|
|AMD have assigned CVE-2021-26341.
|
|For more details, see:
| 
https://grsecurity.net/amd_branch_mispredictor_part_2_where_no_cpu_has_gone_before
| 
https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1026

|
| 3) Researchers at Intel have discovered that previous Spectre-v2
|recommendations of using lfence/jmp is incomplete.
|
|AMD have assigned CVE-2021-26401.
|
|For more details, see:
| 
https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1036

|


Impact
---

The Xen Project's summary above enumerates three security issues. The
first one, in practice, affects only newer Intel systems (11th
generation and later). For other systems, previous mitigations
are already sufficient. The second issue does not, in practice, affect
any configuration supported by Qubes OS. The third issue affects only
AMD systems.
On affected systems, an attacker might be able to infer the contents
of arbitrary host memory, including memory assigned to other guests.

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-398.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/03/10/qsb-077/

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/df012b65-2e7f-9fcf-3fb6-0daf6143d71f%40qubes-os.org.

[qubes-users] Re: Should the footer at the bottom of the mailing list be deleted?

[Andrew David Wong]

On 3/9/22 1:25 PM, Demi Marie Obenour wrote:

The footer on each message is rather annoying, mostly because it breaks
digital signatures.  Should it be set to the empty string, or do its
benefits outweigh the drawbacks?


As far as I can tell from examining the settings interface, it can't be 
entirely removed or entirely replaced with an empty string. Google 
Groups will not allow it.


--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ebf3e76c-9923-6de4-3572-8eac6d9db752%40qubes-os.org.

[qubes-users] Qubes Canary 030

[Andrew David Wong]

Dear Qubes Community,

We have published Qubes Canary 030. 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 030 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 030 ]===---


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 08, 2022.

2. There have been 76 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 June 2022. Special note should be taken if no new
   canary is published by that time or if the list of statements changes
   without plausible explanation.


Special announcements
--

None.


Disclaimers and notes
--

We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently compromised.
This means that we assume NO trust in any of the servers or services
which host or provide any Qubes-related data, in particular, software
updates, source code repositories, and Qubes ISO downloads.

This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other means,
like blackmail or compromising the signers' laptops, to coerce us to
produce false declarations.

The proof of freshness provided below serves to demonstrate that this
canary could not have been created prior to the date stated. It shows
that a series of canaries was not created in advance.

This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to anybody.
None of the signers should be ever held legally responsible for any of
the statements made here.


Proof of freshness
---

Tue, 08 Mar 2022 04:12:58 +

Source: DER SPIEGEL - International 
(https://www.spiegel.de/international/index.rss)
Yuval Noah Harari on the Ukraine War: "Human Stupidity Should Never Be 
Underestimated"
Josep Borrell on Russia's war in Ukraine and what Europe needs to do 
about it

Ukraine: Kyiv Residents Prepare for the Arrival of the Russians
Russia-Ukraine-War: How Vladimir Putin Brought the West Together
The Ukrainian Heartland Prepares for War: "I'm Not Leaving My Home!"

Source: NYT > World News 
(https://rss.nytimes.com/services/xml/rss/nyt/World.xml)

Ukraine Live Updates: Third Round of Talks Raise Hopes for Evacuation Routes
With New Limits on Media, Putin Closes a Door on Russia’s ‘Openness’
Once Victims in Southeast Europe, Jews Come to Aid Fleeing Ukrainians
Baltics, in Russia's Shadow, Demand Tougher Stance From West
These Syrian Refugees Can't Stay in Denmark, but They Can't Go Home

Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
War in Ukraine: Russia says it may cut gas supplies if oil ban goes ahead
War in Ukraine: Crisis is unleashing 'hell on earth' for food prices
War in Ukraine: World Bank approves $723m financial package
War in Ukraine: 'It's hell, it's really hell' - Families flee bombs in Irpin
Ukraine war: Chernobyl workers' 12-day ordeal under Russian guard

Source: Blockchain.info
0003c2fb54d0cb10b7730ca540bcd201beabacce179976cd


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/03/08/canary-030/

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

Re: [qubes-users] zenity is not installed in dom0 by default in Qubes-OS 4.1.0

[Andrew David Wong]

On 2/17/22 3:40 AM, Peter Funk wrote:

Hello all,

While playing around with a freshly installed Qubes-OS 4.1.0
I discovered by accident that there are a few core commands
which make still use of the utility program zenity to display
error messages but the package zenity is not
installed in dom0 by default.  For me the fix was easy::

   sudo qubes-dom0-update zenity

I added the missing tool.  Out of curiosity I had a look into
the sources and found at least three places which make use of
zenity::

   $ grep -rn zenity .
   ./qubes-core-admin-linux/file-copy-vm/qfile-dom0-agent.c:23:#define ZENITY_CMD 
"zenity --title 'File copy/move error' --warning --text "
   ./qubes-core-admin-linux/dom0-updates/qubes-dom0-update:187:zenity --error 
--text "$message1\n$message2"
   ./qubes-core-admin-linux/dom0-updates/qubes-dom0-update:334:zenity 
--info --title='Dom0 updates' --text='No updates available'

So since kdialog is also not installed by default I believe this
could be considered as a bug in the default package selection.

Either zenity should be installed in dom0 by default or these three
places in qubes-core-admin-linux should be changed to some other
mechanism to display error messages.

Best regards, Peter Funk


Thanks for the bug report, Peter. I've copied it into qubes-issues:

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

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/368510a0-3540-e8de-5ac0-9019f62223ad%40qubes-os.org.

[qubes-users] QSB-076: Intel microcode updates

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 076: Intel
microcode updates. The text of this QSB is reproduced below. This QSB
and its accompanying signatures will always be available in the Qubes
Security Pack (qubes-secpack).

View QSB-076 in the qubes-secpack:



In addition, you may wish to:

- Get the qubes-secpack: 
- View all past QSBs: 
- View the XSA Tracker: 

```

 ---===[ Qubes Security Bulletin 076 ]===---

 2022-02-11

  Intel microcode updates


User action required
-

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

  For Qubes 4.0, in dom0:
  - microcode_ctl package, version 2.1-34.qubes1

  For Qubes 4.1, in dom0:
  - microcode_ctl package, version 2.1-34.qubes1

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 PCR19 will change due to the new
microcode in the initramfs.


Summary


On 2022-02-08, Intel published microcode updates [3] for some of their
CPUs that fix security issues [4]. INTEL-SA-00561 (CVE-2021-0145) [7][8]
affects Qubes installations on hardware with affected CPU models. Red
Hat provides a good overview [5]:

| A flaw was found in microcode. Fast store forwarding prediction in one
| domain could be controlled by software previously executed in another
| domain. Such control helps a malicious program running in user mode
| (or guest VM) to trigger transient execution gadgets in supervisor
| mode (or VMM), potentially leading to sensitive data disclosure.

There is also a separate vulnerability -- INTEL-SA-00589
(CVE-2021-33120) [9] -- that seems to affect mainly low-power
architecture CPUs, e.g., Atom. However, due to the sparse description of
the issue, we cannot judge whether it affects Qubes OS.

Impact
---

INTEL-SA-00561 (CVE-2021-0145) is another CPU vulnerability related to
speculative execution (also called transient execution). If successfully
exploited, it could allow an attacker to read information across
security boundaries. In this case, the successful exploitation could
allow an attacker-controlled VM to read information that should be
accessible only to the hypervisor.

This affects at least 10th generation mobile and 11th generation mobile
and desktop Intel Core CPUs. For a full list of affected CPU models, see
Intel's table [6] or Red Hat's summary [5].


Credits


See the original security advisories. Additional thanks to Red Hat for
their helpful overview of the microcode updates.


References
---

[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] 
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md#microcode-2022027

[4] https://www.intel.com/content/www/us/en/security-center/default.html
[5] https://access.redhat.com/articles/6716541
[6] 
https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
[7] 
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00561.html
[8] 
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/fast-store-forwarding-predictor.html
[9] 
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00589.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/02/11/qsb-076/

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d2ca185b-7e64-9f63-e28e-3fbbafe1131e%40qubes-os.org.

[qubes-users] Qubes OS 4.1.0 has been released!

[Andrew David Wong]

e Qubes OS Project a
great example of open-source collaboration.

https://www.qubes-os.org/partners/
https://www.qubes-os.org/donate/
https://www.qubes-os.org/doc/contributing/
https://www.qubes-os.org/doc/issue-tracking/
https://www.qubes-os.org/doc/testing/


## Release notes

The following list is also available on the Qubes OS 4.1 release notes
page:

https://www.qubes-os.org/doc/releases/4.1/release-notes/

- Optional qubes-remote-support package now available from repositories
  (strictly opt-in, no package installed by default; no new ports or
  network connections open by default; requires explicit connection
  initiation by the user, then requires sharing a code word with the
  remote party before a connection can be established; see
  [#6364](https://github.com/QubesOS/qubes-issues/issues/6364) for more
  information)
- Qubes firewall reworked to be more defensive (see
  [#5540](https://github.com/QubesOS/qubes-issues/issues/5540) for
  details)
- Xen upgraded to version 4.14
- Dom0 operating system upgraded to Fedora 32
- Default desktop environment upgraded to Xfce 4.14
- Upgraded default template releases
- Experimental support for GUI running outside of dom0 (hybrid mode GUI
  domain without real GPU passthrough; see
  [#5662](https://github.com/QubesOS/qubes-issues/issues/5662) for
  details)
- Experimental support for audio server running outside of dom0 ("Audio
  domain")
- sys-firewall and sys-usb are now disposables by default
- UEFI boot now loads GRUB, which in turn loads Xen, making the boot
  path similar to legacy boot and allowing the user to modify boot
  parameters or choose an alternate boot menu entry
- New qrexec policy format (see
  [#4370](https://github.com/QubesOS/qubes-issues/issues/4370) for
  details)
- qrexec protocol improvements (see
  [#4909](https://github.com/QubesOS/qubes-issues/issues/4909) for
  details)
- New qrexec-policy daemon
- Simplified using in-qube kernels
- Windows USB and audio support courtesy of
  [tabit-pro](https://github.com/tabit-pro) (see
  [#5802](https://github.com/QubesOS/qubes-issues/issues/5802) and
  [#2624](https://github.com/QubesOS/qubes-issues/issues/2624))
- Clarified disposable-related terminology and properties
- Default kernelopts can now be specified by a kernel package
- Improved support for high-resolution displays
- Improved notifications when a system drive runs out of free space
- Support for different cursor shapes
- "Paranoid mode" backup restore option now properly supported using
  disposables
- Users can now choose between Debian and Fedora in the installer
- Certain files and applications are now opened in disposables, e.g.,
  Thunderbird email attachments
- New graphical interface for managing testing repository updates
- New "Cute Qube" icon family (replaces padlock icons)
- Disposable qube types now use the disposable icon
- New Template Manager tool for installing, removing, and updating
  templates (meanwhile, the tool previously known as the "Template
  Manager," which was for mass template switching, has been integrated
  into the Qube Manager)
- The "file" storage driver has been deprecated in Qubes 4.1 and will be
  removed in Qubes 4.2
- `property-del` event renamed to `property-reset` to avoid confusion
- qrexec no longer supports non-executable files in `/etc/qubes-rpc`
- qrexec components have been reorganized into the core-qrexec
  repository
- The `qvm-pool` argument parser has been rewritten and improved
- Removed the need for the out-of-tree u2mfn kernel module
- Qrexec services can now run as a socket server
- Improved template distribution mechanism
- Now possible to restart qrexec-agent
- The term "VM" has largely been replaced by "qube"
- GUI daemon is now configured using `qvm-features` tool,
  `/etc/qubes/guid.conf` file is no longer used
- `qvm-run` tool got `--no-shell` option to run a single command without
  using a shell inside the qube

For a full list, including more detailed descriptions, please see here:

https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+sort%3Aupdated-desc+milestone%3A%22Release+4.1%22+label%3A%22release+notes%22+is%3Aclosed

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/02/04/qubes-4-1-0/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0f88fd4c-4095-0bb3-4c31-30cc8aecb083%40qubes-os.org.

[qubes-users] XSAs released on 2022-01-25

[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 affect the security of Qubes OS (user action required)


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

- XSA-395

Please see *QSB-075* for the actions users must take in order to
protect themselves, as well as further details about these XSAs:

<https://www.qubes-os.org/news/2022/01/25/qsb-075/>


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-393 (ARM architectures only)
- XSA-394 (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/01/25/xsas-released-on-2022-01-25/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

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

[qubes-users] QSB-075: Insufficient cleanup of passed-through device IRQs (XSA-395)

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 075: Insufficient
cleanup of passed-through device IRQs (XSA-395). The text of this QSB
is reproduced below. This QSB and its accompanying signatures will
always be available in the Qubes Security Pack (qubes-secpack).

View QSB-075 in the qubes-secpack:



In addition, you may wish to:

- Get the qubes-secpack: 
- View all past QSBs: 
- View the XSA Tracker: 

```

 ---===[ Qubes Security Bulletin 075 ]===---

 2022-01-25

Insufficient cleanup of passed-through device IRQs (XSA-395)


User action required
-

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

  For Qubes 4.0, in dom0:
  - Xen packages, version 4.8.5-37

  For Qubes 4.1, in dom0:
  - Xen packages, version 4.14.3-8

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-01-25, the Xen project published XSA-395, "Insufficient cleanup
of passed-through device IRQs" [3]:

| The management of IRQs associated with physical devices exposed to x86
| HVM guests involves an iterative operation in particular when cleaning
| up after the guest's use of the device.  In the case where an
| interrupt is not quiescent yet at the time this cleanup gets invoked,
| the cleanup attempt may be scheduled to be retried.  When multiple
| interrupts are involved, this scheduling of a retry may get
| erroneously skipped.  At the same time pointers may get cleared
| (resulting in a de-reference of NULL) and freed (resulting in a
| use-after-free), while other code would continue to assume them to be
| valid.


Impact
---

The precise impact is system-specific but would typically be a denial of
service (DoS) affecting the entire host.  Privilege escalation and
information leaks cannot be ruled out.

Only x86 HVM guests with one or more passed-through physical devices
using multiple physical interrupts together can exploit this
vulnerability. In Qubes, this generally applies to sys-usb and sys-net,
but whether the relevant devices use multiple interrupts together is
system-specific.


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-395.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/01/25/qsb-075/

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0d5d5b5c-5411-e2ed-f081-36a847b0911a%40qubes-os.org.

[qubes-users] Qubes OS 4.1.0-rc4 has been released!

[Andrew David Wong]

Dear Qubes Community,

The fourth release candidate for Qubes 4.1.0 is here! There are no major
changes to report. We've just focused on fixing bugs that were
discovered and reported in the third release candidate.

If you're currently using any Qubes 4.1.0 release candidate, a regular
update [01] is sufficient to upgrade to the latest one. Otherwise,
read on for more about how to get started with testing Qubes 4.1.0-rc4.


What's new in Qubes 4.1.0?
--

In case you still haven't heard, Qubes 4.1.0 includes several major new
features, each of which is explained in depth in its own article:

- Qubes Architecture Next Steps: The GUI Domain [02]
- Qubes Architecture Next Steps: The New Qrexec Policy System [03]
- New Gentoo templates and maintenance infrastructure [04]
- Reproducible builds for Debian: a big step forward [05]

There are also  numerous other improvements and bug fixes listed in
the release notes [06] and in the issue tracker [07].

Finally, Qubes 4.1.0 features the following updated default components:

- Xen 4.14
- Fedora 32 in dom0
- Fedora 34 template
- Debian 11 template
- Whonix 16 Gateway and Workstation templates
- Linux kernel 5.10


How to test Qubes 4.1.0-rc4
---

If you're willing to test [08] this release candidate, you can help to
improve the stable release by reporting any bugs you encounter [09].
Experienced users are strongly encouraged to join the testing team [10]!

How to migrate to 4.1.0-rc4:

- If you're already on any 4.1.0 release candidate, simply perform a
  normal update [01].
- If you're not on a 4.1.0 release candidate yet, you have two options:
  1. Back up [11] your current installation, download [12] 4.1.0-rc4,
 perform a fresh install [13], then restore [14] from your backup.
  2. Perform an in-place upgrade [15].


Release candidate planning
--

With each new release candidate, Qubes 4.1.0 becomes more stable as
testers report bugs and our developers fix them. As explained in our
general release schedule [16], this cycle will continue until no major
bugs are discovered, at which point the last release candidate will be
declared the stable 4.1.0 release. Until then, we plan to have new
release candidates approximately every five weeks.


[01] https://www.qubes-os.org/doc/how-to-update/
[02] https://www.qubes-os.org/news/2020/03/18/gui-domain/
[03] https://www.qubes-os.org/news/2020/06/22/new-qrexec-policy-system/
[04] 
https://www.qubes-os.org/news/2020/10/05/new-gentoo-templates-and-maintenance-infrastructure/
[05] 
https://www.qubes-os.org/news/2021/10/08/reproducible-builds-for-debian-a-big-step-forward/

[06] https://www.qubes-os.org/doc/releases/4.1/release-notes/
[07] 
https://github.com/QubesOS/qubes-issues/issues?q=milestone%3A%22Release+4.1%22+is%3Aclosed+-label%3A%22R%3A+duplicate%22+-label%3A%22R%3A+invalid%22+-label%3A%22R%3A+cannot+reproduce%22+-label%3A%22R%3A+not+an+issue%22+-label%3A%22R%3A+not+our+bug%22+-label%3A%22R%3A+won%27t+do%22+-label%3A%22R%3A+won%27t+fix%22+

[08] https://www.qubes-os.org/doc/testing/
[09] https://www.qubes-os.org/doc/issue-tracking/
[10] https://forum.qubes-os.org/t/joining-the-testing-team/5190
[11] 
https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/#creating-a-backup

[12] https://www.qubes-os.org/downloads/
[13] https://www.qubes-os.org/doc/installation-guide/
[14] 
https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/#restoring-from-a-backup

[15] https://www.qubes-os.org/doc/upgrade/4.1/
[16] https://www.qubes-os.org/doc/version-scheme/#release-schedule

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/01/18/qubes-4-1-0-rc4/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ea2eb4ad-def7-acd0-b8c1-7517ca32c17c%40qubes-os.org.

Re: [qubes-users] Q: Thunderbird extension: "open URL in VM..."

[Andrew David Wong]

On 12/31/21 9:53 AM, Ulrich Windl wrote:

Hi!

As it seems, there is a Thunderbird extension (Qubes attachments) 
allowing to open an attachment in a VM, but I'd like to have an 
extension that allows to open an URL in a VMs web browser easily, too.


Is there one already?

Regards,
Ulrich



I'm not aware of an actual Thunderbird extension for it, but you can set 
it up yourself by following the instructions here, for example:


https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/tips-and-tricks.md#opening-links-in-your-preferred-appvm

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/417129bd-4fac-a053-47a4-d4d731f7ca40%40qubes-os.org.

Re: [EXT] [qubes-users] Re: Qubes OS 4.1-rc3 has been released!

[Andrew David Wong]

On 12/31/21 2:40 PM, Scat wrote:

Thank you all, appreciate the feedback and happy new year to some!

Excuse the layman question but I assume if I install 4.1rc3, when 4.1 rolls
outit is simply an upgrade?



It depends on the nature of any updates, but that seems like the most 
likely outcome right now. In general, the final release candidate of a 
series (whichever one that might be) is ultimately declared to be the 
stable release. However, it's possible that a clean reinstallation may 
be required from one release candidate to the next (though that's less 
common and rather unlikely at this stage of the R4.1-rc series).


--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/92339c41-abae-d5ae-3dd9-fffedeef7460%40qubes-os.org.

[qubes-users] Qubes OS 4.1-rc3 has been released!

[Andrew David Wong]

Dear Qubes Community,

The third release candidate for Qubes 4.1 is here! There are no major
changes to report. We've just focused on fixing bugs that were
discovered and reported in the second release candidate.

If you're currently using any Qubes 4.1 release candidate, a regular
update [01] is sufficient to upgrade to the latest one. Otherwise,
read on for more about how to get started with testing Qubes 4.1-rc3.


What's new in Qubes 4.1?


In case you still haven't heard, Qubes 4.1 includes several major new
features, each of which is explained in depth in its own article:

- Qubes Architecture Next Steps: The GUI Domain [02]
- Qubes Architecture Next Steps: The New Qrexec Policy System [03]
- New Gentoo templates and maintenance infrastructure [04]
- Reproducible builds for Debian: a big step forward [05]

There are also  numerous other improvements and bug fixes listed in
the release notes [06] and in the issue tracker [07].

Finally, Qubes 4.1 features the following updated default components:

- Xen 4.14
- Fedora 32 in dom0
- Fedora 34 template
- Debian 11 template
- Whonix 16 Gateway and Workstation templates
- Linux kernel 5.10


How to test Qubes 4.1-rc3
-

If you're willing to test [08] this release candidate, you can help to
improve the stable release by reporting any bugs you encounter [09].
Experienced users are strongly encouraged to join the testing team [10]!

How to migrate to 4.1-rc3:

- If you're already on any 4.1 release candidate, simply perform a
  normal update [01].
- If you're not on a 4.1 release candidate yet, you have two options:
  1. Back up [11] your current installation, download [12] 4.1-rc3,
 perform a fresh install [13], then restore [14] from your backup.
  2. Perform an in-place upgrade [15].


Release candidate planning
--

With each new release candidate, Qubes 4.1 becomes more and more stable
as our testers report more bugs, and our developers fix them. As
explained in our general release schedule [16], this cycle will continue
until no major bugs are discovered, at which point the last release
candidate will be declared the stable 4.1 release. Until then, we plan
to have new release candidates approximately every five weeks.


[01] https://www.qubes-os.org/doc/how-to-update/
[02] https://www.qubes-os.org/news/2020/03/18/gui-domain/
[03] https://www.qubes-os.org/news/2020/06/22/new-qrexec-policy-system/
[04] 
https://www.qubes-os.org/news/2020/10/05/new-gentoo-templates-and-maintenance-infrastructure/
[05] 
https://www.qubes-os.org/news/2021/10/08/reproducible-builds-for-debian-a-big-step-forward/

[06] https://www.qubes-os.org/doc/releases/4.1/release-notes/
[07] 
https://github.com/QubesOS/qubes-issues/issues?q=milestone%3A%22Release+4.1%22+is%3Aclosed+-label%3A%22R%3A+duplicate%22+-label%3A%22R%3A+invalid%22+-label%3A%22R%3A+cannot+reproduce%22+-label%3A%22R%3A+not+an+issue%22+-label%3A%22R%3A+not+our+bug%22+-label%3A%22R%3A+won%27t+do%22+-label%3A%22R%3A+won%27t+fix%22+

[08] https://www.qubes-os.org/doc/testing/
[09] https://www.qubes-os.org/doc/issue-tracking/
[10] https://forum.qubes-os.org/t/joining-the-testing-team/5190
[11] 
https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/#creating-a-backup

[12] https://www.qubes-os.org/downloads/
[13] https://www.qubes-os.org/doc/installation-guide/
[14] 
https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/#restoring-from-a-backup

[15] https://www.qubes-os.org/doc/upgrade/4.1/
[16] https://www.qubes-os.org/doc/version-scheme/#release-schedule

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/12/21/qubes-4-1-rc3/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/98e481bb-cf44-1afc-5f29-3c6e58e980d1%40qubes-os.org.

[qubes-users] XSAs released on 2021-12-20

[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-376 (denial-of-service only)
- XSA-391 (denial-of-service only)
- XSA-392 (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/2021/12/20/xsas-released-on-2021-12-20/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/682df33f-5bb2-57f1-11c5-cf64ce25564d%40qubes-os.org.

Re: [EXT] Re: [qubes-users] Upgrading debian instructions are wrong

[Andrew David Wong]

On 12/16/21 1:21 PM, Ulrich Windl wrote:

On 12/16/21 10:05 PM, frag wrote:

Hi Ulrich,

You should try the following commands:

$ sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list
$ sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list.d/qubes-r4.list

And I recommand you to clone your qube first as described.


Hi!

thanks for the reply. In fact I found out later reading 
https://www.qubes-os.org/doc/template/debian/upgrade/#release-specific-notes 

Maybe there should be anchors for each debian release, so the referrer 
could point to specific instructions.




There already are. Simply hover over one of the release subheadings, 
then click on the link icon that appears. You'll get a URL like this:


https://www.qubes-os.org/doc/template/debian/upgrade/#debian-11-bullseye

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c3e73709-5698-98cb-c208-aeb9059f8286%40qubes-os.org.

[qubes-users] Qubes Canary 029

[Andrew David Wong]

Dear Qubes Community,

We have published Qubes Canary 029. 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 029 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 029 ]===---


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 13, 2021.

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

Many PGP keys in the Qubes security pack (qubes-secpack) that are used
elsewhere in the project (such as the Qubes builder), including the
Qubes Master Signing Key (QMSK), were signed or self-signed using the
SHA-1 hash function. Unlike some other uses of SHA-1, its use in our PGP
signatures does not pose a noteworthy security risk unless an adversary
is capable of performing a successful preimage attack (not merely a
collision attack). Since there are presently no known feasible attacks
against the preimage resistance of full SHA-1, our use of SHA-1 in PGP
signatures does not currently pose a relevant security risk.
Nonetheless, as a preemptive defense-in-depth enhancement and to support
deprecation of SHA-1 in tooling, we have decided to re-(self-)sign many
of these keys using SHA-256 or SHA-512. [3]

In addition, the qubes-secpack contains several expired code signing
keys, old release keys, and keys belonging to individuals who are no
longer active Qubes developers. We have decided to move these keys into
new "retired" subdirectories. (We've decided to move them rather than
delete them, since some users may wish to use them to authenticate old
signatures. Note that this is merely a matter of convenience, since even
deleted files always remain in the Git repository's history and can
always be retrieved that way.)

To be clear, none of the actions described here constitute a response to
any security incident. To our knowledge, the keys in the qubes-secpack
are not and have never been at risk. No key fingerprints have changed as
a result of these actions. We consider this updating and cleanup of the
keys to be more of a "housekeeping" task.


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

Mon, 13 Dec 2021 01:15:23 +

Source: DER SPIEGEL - International 
(https://www.spiegel.de/international/index.rss)
Resurrection of the SP: The Unexpected Rise of Germany's New Chancellor, 
Olaf Scholz
BioNTech Founder Şahin on the Omicron Variant: “It Will Make Scientific 
Sense To Offer Booster after Three Months”

City of Warriors: Resistance Across the Border to the Myanmar Military Junta
Deadly Intrigue: The Story of the Destruction of an Aid Organization
The One-Man State: Viktor Orbán and the Fall of Democracy in Hungary

Source: NYT > World News 
(https://rss.nytimes.com/services/xml/rss/nyt/World.xml)

Haiti’s Leader Kept a List of Drug Traffickers. His Assassins Came for It.
‘Our Boat Was Surrounded by Dead Bodies’: 

[qubes-users] Debian 11 templates available

[Andrew David Wong]

Dear Qubes Community,

New Debian 11 templates are available for both Qubes 4.0 and 4.1.

We provide fresh Debian 11 template packages through the official Qubes
repositories, which you can install in dom0 by following the standard
installation instructions [1]. Alternatively, we also provide
step-by-step instructions for performing an in-place upgrade [2] 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 [3].

For a complete list of template releases that are supported for your
specific Qubes release, see our supported template releases [4].

Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL [5].


[1] https://www.qubes-os.org/doc/templates/debian/#installing
[2] https://www.qubes-os.org/doc/template/debian/upgrade/
[3] https://www.qubes-os.org/doc/templates/#switching
[4] https://www.qubes-os.org/doc/supported-releases/#templates
[5] 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/2021/12/07/debian-11-templates-available/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

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

Re: [EXT] Re: [qubes-users] Verifying signatures

[Andrew David Wong]

On 11/30/21 10:18 AM, Ulrich Windl wrote:

On 11/30/21 12:32 PM, Andrew David Wong wrote:

On 11/29/21 12:06 PM, 'Rune Philosof' via qubes-users wrote:

When I follow the guide
on https://www.qubes-os.org/security/verifying-signatures/
I get the following result
```
[vagrant@fedora ~]$ gpg2 --check-signatures "Qubes Master Signing Key"
pub   rsa4096 2010-04-01 [SC]
   427F11FD0FAA4B080123F01CDDFA1A3E36879494
uid   [ultimate] Qubes Master Signing Key
sig!3    DDFA1A3E36879494 2010-04-01  Qubes Master Signing Key

gpg: 1 good signature
[vagrant@fedora ~]$ gpg2 --check-signatures "Qubes OS Release 4 
Signing Key"

pub   rsa4096 2017-03-06 [SC]
   5817A43B283DE5A9181A522E1848792F9E2795E9
uid   [ unknown] Qubes OS Release 4 Signing Key
sig!3    1848792F9E2795E9 2017-03-06  Qubes OS Release 4 Signing Key
gpg: Note: third-party key signatures using the SHA1 algorithm are 
rejected

gpg: (use option "--allow-weak-key-signatures" to override)
sig% DDFA1A3E36879494 2017-03-08  [Invalid digest algorithm]

gpg: 1 good signature
gpg: 1 signature not checked due to an error
```

Is it because the master key is old and the old defaults are now
considering too weak?


I take it you're referring to the message about SHA1. I'm not certain, 
but we do have a related open issue, which the devs are working on now:


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

Also see the comments on this issue, which are even more specific to 
your question:


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

In particular, Marek commented (on #4378):

"In general, it may be a good idea to create new signature using 
SHA256 or such, to ease the use with weak-digest SHA1 option enabled. 
But in practice, in the current state SHA1 problems doesn't affect 
security of the key itself, because there are no known pre-image attacks.

New signatures are made with SHA256 hash function."


If so, why not distribute a new one?



It's not that simple. As Marek recently pointed out to me, "The 
current QMSK is well known and published in a lot of places (easing 
its verification), including various conference videos, physical 
t-shirts we sold, some stickers etc. With every new QMSK it will take 
time until it will be comparably easy to independently verify."


But isn't that exactly the advantage of the "web of trust"?: You can 
sign the new key with your old key, and people will (have the chance to) 
trust the new key as well.




The Web of Trust is only one of several different methods for 
authenticating the QMSK. Many of our users do not use the Web of Trust. 
Please read this for further details:


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



Having said that, we do have an open issue for generating a new QMSK:

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

We likely will at some point, but it's not an action to be taken lightly.





--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/40a7697d-75ed-8883-0fde-d4b3f14d1ad9%40qubes-os.org.

[qubes-users] Fedora 33 has reached EOL

[Andrew David Wong]

Dear Qubes Community,

As previously announced [1], Fedora 33 has reached EOL (end-of-life
[2]). If you have not already done so, we strongly recommend upgrading
[3] your Fedora 33 templates and standalones to Fedora 34 immediately.

We provide fresh Fedora 34 template packages through the official Qubes
repositories, which you can install in dom0 by following the standard
installation instructions [4]. Alternatively, we also provide
step-by-step instructions for performing an in-place upgrade [5] 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 [6].

For a complete list of template releases that are supported for your
specific Qubes release, see our supported template releases [7].

Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL [8].

*Note for 4.1 release candidate testers:* Qubes R4.1-rc1 already
includes the Fedora 34 template by default, so no action is required.


[1] 
https://www.qubes-os.org/news/2021/11/11/fedora-33-approaching-eol-fedora-34-templates-available/

[2] https://fedoraproject.org/wiki/End_of_life
[3] https://www.qubes-os.org/doc/templates/fedora/#upgrading
[4] https://www.qubes-os.org/doc/templates/fedora/#installing
[5] https://www.qubes-os.org/doc/template/fedora/upgrade/
[6] https://www.qubes-os.org/doc/templates/#switching
[7] https://www.qubes-os.org/doc/supported-releases/#templates
[8] 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/2021/11/30/fedora-33-eol/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1b53d5a4-ff3c-da77-6d7f-cf57cd610d63%40qubes-os.org.

Re: [qubes-users] Verifying signatures

[Andrew David Wong]

On 11/29/21 12:06 PM, 'Rune Philosof' via qubes-users wrote:

When I follow the guide
on https://www.qubes-os.org/security/verifying-signatures/
I get the following result
```
[vagrant@fedora ~]$ gpg2 --check-signatures "Qubes Master Signing Key"
pub   rsa4096 2010-04-01 [SC]
   427F11FD0FAA4B080123F01CDDFA1A3E36879494
uid   [ultimate] Qubes Master Signing Key
sig!3DDFA1A3E36879494 2010-04-01  Qubes Master Signing Key

gpg: 1 good signature
[vagrant@fedora ~]$ gpg2 --check-signatures "Qubes OS Release 4 Signing Key"
pub   rsa4096 2017-03-06 [SC]
   5817A43B283DE5A9181A522E1848792F9E2795E9
uid   [ unknown] Qubes OS Release 4 Signing Key
sig!31848792F9E2795E9 2017-03-06  Qubes OS Release 4 Signing Key
gpg: Note: third-party key signatures using the SHA1 algorithm are rejected
gpg: (use option "--allow-weak-key-signatures" to override)
sig% DDFA1A3E36879494 2017-03-08  [Invalid digest algorithm]

gpg: 1 good signature
gpg: 1 signature not checked due to an error
```

Is it because the master key is old and the old defaults are now
considering too weak?


I take it you're referring to the message about SHA1. I'm not certain, 
but we do have a related open issue, which the devs are working on now:


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

Also see the comments on this issue, which are even more specific to 
your question:


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

In particular, Marek commented (on #4378):

"In general, it may be a good idea to create new signature using SHA256 
or such, to ease the use with weak-digest SHA1 option enabled. But in 
practice, in the current state SHA1 problems doesn't affect security of 
the key itself, because there are no known pre-image attacks.

New signatures are made with SHA256 hash function."


If so, why not distribute a new one?



It's not that simple. As Marek recently pointed out to me, "The current 
QMSK is well known and published in a lot of places (easing its 
verification), including various conference videos, physical t-shirts we 
sold, some stickers etc. With every new QMSK it will take time until it 
will be comparably easy to independently verify."


Having said that, we do have an open issue for generating a new QMSK:

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

We likely will at some point, but it's not an action to be taken lightly.

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/040578c4-101b-3276-b71d-521206ff3de7%40qubes-os.org.

[qubes-users] XSAs released on 2021-11-23

[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 affect the security of Qubes OS (user action required)


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

- XSA-388
- XSA-389

Please see *QSB-074* for the actions users must take in order to
protect themselves, as well as further details about these XSAs:

<https://www.qubes-os.org/news/2021/11/24/qsb-074/>


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-385 (DoS only; Qubes has BIGMEM disabled)
- XSA-387 (Qubes has grant tables v2 disabled)


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/2021/11/24/xsas-released-on-2021-11-23/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

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

[qubes-users] QSB-074: Xen issues related to populate-on-demand (XSA-388, XSA-389)

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 074:
Xen issues related to populate-on-demand (XSA-388, XSA-389).
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack 
(qubes-secpack).


View QSB-074 in the qubes-secpack:



In addition, you may wish to:

- Get the qubes-secpack: 
- View all past QSBs: 
- View the XSA Tracker: 

```

 ---===[ Qubes Security Bulletin 074 ]===---

 2021-11-23

 Xen issues related to populate-on-demand (XSA-388, XSA-389)


User action required
-

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

  For Qubes 4.0, in dom0:
  - Xen packages, version 4.8.5-36

  For Qubes 4.1, in dom0:
  - Xen packages, version 4.14.3-4

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]

Dom0 must be restarted afterward in order for the updates to take
effect.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.


Summary


The following security advisories were published on 2021-11-23:

XSA-388 [3] "PoD operations on misaligned GFNs":

| x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode,
| to provide a way for them to later easily have more memory assigned.
|
| Guests are permitted to control certain P2M aspects of individual
| pages via hypercalls.  These hypercalls may act on ranges of pages
| specified via page orders (resulting in a power-of-2 number of pages).
| The implementation of some of these hypercalls for PoD does not
| enforce the base page frame number to be suitably aligned for the
| specified order, yet some code involved in PoD handling actually makes
| such an assumption.
|
| These operations are XENMEM_decrease_reservation (CVE-2021-28704) and
| XENMEM_populate_physmap (CVE-2021-28707), the latter usable only by
| domains controlling the guest, i.e. a de-privileged qemu or a stub
| domain.  (Patch 1, combining the fix to both these two issues.)
|
| In addition handling of XENMEM_decrease_reservation can also trigger a
| host crash when the specified page order is neither 4k nor 2M nor 1G
| (CVE-2021-28708, patch 2).

XSA-389 [4] "issues with partially successful P2M updates on x86":

| x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode,
| to provide a way for them to later easily have more memory assigned.
|
| Guests are permitted to control certain P2M aspects of individual
| pages via hypercalls.  These hypercalls may act on ranges of pages
| specified via page orders (resulting in a power-of-2 number of pages).
| In some cases the hypervisor carries out the requests by splitting
| them into smaller chunks.  Error handling in certain PoD cases has
| been insufficient in that in particular partial success of some
| operations was not properly accounted for.
|
| There are two code paths affected - page removal (CVE-2021-28705) and
| insertion of new pages (CVE-2021-28709).  (We provide one patch which
| combines the fix to both issues.)


Impact
---

Malicious or buggy guest kernels may be able to mount Denial of Service
(DoS) attacks affecting the entire system. Privilege escalation and
information leaks cannot be ruled out.

These issues affect only qubes that have dynamic memory balancing
enabled. In the default Qubes OS configuration, this excludes sys-net
and sys-usb, which have memory assigned statically. All other
Linux-based qubes are affected.


Credits


See the original Xen Security Advisories.


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-388.html
[4] https://xenbits.xen.org/xsa/advisory-389.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/2021/11/24/qsb-074/

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fa828ea0-75ff-9be5-f860-db9012535c96%40qubes-os.org.

[qubes-users] XSAs released on 2021-11-19

[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-390 (affects only Xen versions >=4.15; Qubes currently uses 4.14 
and 4.8)



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/2021/11/19/xsas-released-on-2021-11-19/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/079a5e3d-aebc-1166-6b99-8d6a94b227b9%40qubes-os.org.

Re: [qubes-users] Qubes OS 4.1-rc2 has been released!

[Andrew David Wong]

On 11/17/21 3:22 AM, taran1s wrote:

Andrew David Wong:

Dear Qubes Community,

We're pleased to announce the second release candidate for Qubes 4.1!

[...]


Is there any HCL list for Qubes 4.1? [...]


Yes, simply go here and click on the "Qubes" column header to sort by 
Qubes release:


https://www.qubes-os.org/hcl/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/dafa0050-1d99-d154-cbef-55cf4d992047%40qubes-os.org.

[qubes-users] Qubes OS 4.1-rc2 has been released!

[Andrew David Wong]

Dear Qubes Community,

We're pleased to announce the second release candidate for Qubes 4.1!

Qubes 4.1-rc2 contains fixes for bugs that were discovered in the first
release candidate (4.1-rc1). For existing Qubes 4.1-rc1 users, a regular
update [01] is sufficient to upgrade to 4.1-rc2.

In case you haven't heard, Qubes 4.1 includes several major new
features, each of which is explained in depth in its own article:

- Qubes Architecture Next Steps: The GUI Domain [02]
- Qubes Architecture Next Steps: The New Qrexec Policy System [03]
- New Gentoo templates and maintenance infrastructure [04]
- Reproducible builds for Debian: a big step forward [05]

There are also  numerous other improvements and bug fixes listed in
the release notes [06] and in the issue tracker [07].

Finally, Qubes 4.1 features the following updated default components:

- Xen 4.14
- Fedora 32 in dom0
- Fedora 34 template
- Debian 11 template
- Whonix 16 Gateway and Workstation templates
- Linux kernel 5.10


How to test Qubes 4.1-rc2
-

If you're willing to test [08] this release candidate, you can help to
improve the stable release by reporting any bugs you encounter [09].
Experienced users are strongly encouraged to join the testing team [10]!

How to migrate to 4.1-rc2:

- If you're already on 4.1-rc1, simply perform a normal update [01].
- If you're not on 4.1-rc1, you have two options:
  1. Back up [11] your current installation, download [12] 4.1-rc2,
 perform a fresh install [13], then restore [14] from your backup.
  2. Perform an in-place upgrade [15].


Release candidate planning
--

As with any release candidate, it's possible that user testing will
reveal important bugs that we'll want to fix before the stable release.
We plan to release the next release candidate in approximately five
weeks. As explained in our general release schedule [16], this cycle
will continue until no major bugs are discovered, at which point the
latest release candidate will be declared the stable 4.1 release.


[01] https://www.qubes-os.org/doc/how-to-update/
[02] https://www.qubes-os.org/news/2020/03/18/gui-domain/
[03] https://www.qubes-os.org/news/2020/06/22/new-qrexec-policy-system/
[04] 
https://www.qubes-os.org/news/2020/10/05/new-gentoo-templates-and-maintenance-infrastructure/
[05] 
https://www.qubes-os.org/news/2021/10/08/reproducible-builds-for-debian-a-big-step-forward/

[06] https://www.qubes-os.org/doc/releases/4.1/release-notes/
[07] 
https://github.com/QubesOS/qubes-issues/issues?q=milestone%3A%22Release+4.1%22+is%3Aclosed+-label%3A%22R%3A+duplicate%22+-label%3A%22R%3A+invalid%22+-label%3A%22R%3A+cannot+reproduce%22+-label%3A%22R%3A+not+an+issue%22+-label%3A%22R%3A+not+our+bug%22+-label%3A%22R%3A+won%27t+do%22+-label%3A%22R%3A+won%27t+fix%22+

[08] https://www.qubes-os.org/doc/testing/
[09] https://www.qubes-os.org/doc/issue-tracking/
[10] https://forum.qubes-os.org/t/joining-the-testing-team/5190
[11] 
https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/#creating-a-backup

[12] https://www.qubes-os.org/downloads/
[13] https://www.qubes-os.org/doc/installation-guide/
[14] 
https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/#restoring-from-a-backup

[15] https://www.qubes-os.org/doc/upgrade/4.1/
[16] https://www.qubes-os.org/doc/version-scheme/#release-schedule

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/11/17/qubes-4-1-rc2/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/79846056-9216-c809-aaeb-30b8f994fdd3%40qubes-os.org.

[qubes-users] Whonix 15 has reached EOL

[Andrew David Wong]

Dear Qubes Community,

Whonix 15 has reached EOL (end-of-life). If you have not already done
so, we strongly recommend upgrading your Whonix 15 templates and
standalones to Whonix 16 [1] immediately. The Whonix Project provides
fresh Whonix 16 template packages through the Qubes community template
repositories, which you can install in dom0 by following the standard
installation instructions [2]. Alternatively, the Whonix Project also
provides step-by-step instructions for performing an in-place upgrade
[3] of an existing Whonix 15 template. After upgrading your templates,
please remember to switch all qubes that were using the old template
to use the new one [4].

For a complete list of template releases supported for your specific
Qubes release, please see our supported template releases [5].


[1] https://www.qubes-os.org/news/2021/09/30/whonix-16-template-available/
[2] https://www.whonix.org/wiki/Qubes/Install
[3] https://www.whonix.org/wiki/Release_Upgrade_Whonix_15_to_Whonix_16
[4] https://www.qubes-os.org/doc/templates/#switching
[5] https://www.qubes-os.org//doc/supported-releases/#templates

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/11/14/whonix-15-eol/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d7baaf3f-bb3f-64fd-a68f-e13b93f207fb%40qubes-os.org.

[qubes-users] "New Qubes application menu" by Marta Marczykowska-Górecka

[Andrew David Wong]

Dear Qubes Community,

A new article has just been published on the Qubes website:

"New Qubes application menu" by Marta Marczykowska-Górecka
https://www.qubes-os.org/news/2021/11/12/new-qubes-application-menu/

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


8<--

"New Qubes application menu"
by Marta Marczykowska-Górecka


## The new application menu is here!

If you are running a release candidate of [Qubes OS 
4.1](https://www.qubes-os.org/news/2021/10/11/qubes-4-1-rc1/) and wish 
to just dive on in, the new app menu can be found 
[here](https://github.com/QubesOS/qubes-desktop-linux-menu). But first, 
a couple important caveats:


- **This new menu requires 4.1 and cannot run on 4.0.**
- **This is experimental software for testing purposes only!**

Still want to give it a go? To install, enter this command in a dom0 
terminal:


```
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable 
qubes-desktop-linux-menu

```

Once installed, add the new menu to the XFCE panel using the provided 
`.desktop` file 
([instructions](https://github.com/QubesOS/qubes-desktop-linux-menu#how-to-run)). 
For those who want to learn more, read on!



## Background

One of the key issues raised by users in last year's Qubes User Survey 
(see the 
[write-up](https://www.qubes-os.org/news/2020/11/26/qubes-survey-results/) 
--- and a big thank you to everyone who participated!) was general 
usability. Qubes OS is great for security, but the *experience* of using 
it can be somewhat opaque or even confusing. The UX difficulties are 
exacerbated by the fact that most of our GUI components are adapted from 
those designed for single-environment systems, like XFCE on Fedora. This 
served as a good first pass for an open-source project developed by a 
small team, but the time has come to begin working on a GUI tailored to 
Qubes OS's particular multi-environment setting.


Helpfully, three years ago the SecureDrop team began user research in 
support of their [SecureDrop Workstation 
project](https://securedrop.org/news/piloting-securedrop-workstation-qubes-os/) 
(built atop Qubes OS). In the course of their work, they discovered that 
it was not just SecureDrop users who wanted the Qubes OS GUI to be 
friendlier --- a lot of other folks seemed to want Qubes OS to be more 
usable, too! From the SecureDrop Workstation project, Nina Alter began 
contributing to Qubes, and we subsequently joined forces to tackle the 
app menu project. This project received a generous grant from the 
Mozilla Foundation!



## Goals

The main idea behind the new application menu is simple: to create a way 
of accessing programs that's native to Qubes OS, takes into account its 
quirks and approach, and is both easy to use and accessible. The visual 
clarity of the current application menu, which uses XFCE's default menu 
and adds a folder within the menu for each qube, leaves much to be 
desired. Research showed us most users prefer GUI system tools. The 
classic Linux nerd answer of "Just use the terminal. It's easy!" does 
not really capture how most people work. Thus, we needed a better 
approach, one that's more accessible, easier to use, and represents a 
mental model consistent with Qubes OS rather than a typical monolithic 
Linux distribution.


For those interested, [we presented our work on the new app menu on the 
second day of our 2021 Qubes Mini 
Summit](https://www.youtube.com/watch?v=KdDr6TiqF0k). The presentation 
begins at the 01h 15min mark of the video.



## Application Menu Features

### Qubes

The new application menu has three tabs (as seen on the left): qubes, 
favorites, and system tools. The first tab is the most similar one to 
the old menu. It contains all qubes, but now sorted into three groups 
(on top of the middle pane): normal application qubes (the APP section), 
qube templates (TEMPLATES), and various system qubes (SYSTEM).


[![Menu](https://www.qubes-os.org/attachment/posts/menu_writeup_1.png)](https://www.qubes-os.org/attachment/posts/menu_writeup_1.png)

When you select a qube, its applications appear on the right --- the 
same applications that you chose for the old menu, in Qube Settings. 
Now, however, they are accompanied by a couple of utility features, like 
quick access to start and shut down commands and an indicator of the 
networking state of the qube on top.


The menu itself also communicates more information about system state. 
Names of running qubes are bolded, and those of disposable qubes and 
their templates are italicized. There's also a clear visual indicator of 
the disposable template each disposable is based on.
Further enhancements (coming in the future) will be --- as inspired by 
many users citing frustrations with memory management and information in 
the menu --- more data about RAM usage or qube template on top of the 
application pane.


[![Disposable qube 

[qubes-users] Fedora 33 approaching EOL; Fedora 34 templates available

[Andrew David Wong]

Dear Qubes Community,

Fedora 33 is scheduled to reach EOL (end-of-life [1]) on 2021-11-30, and
new Fedora 34 templates are now available for both Qubes 4.0 and 4.1.

We strongly recommend that all Qubes users upgrade [2] their Fedora 33
templates and standalones to Fedora 34 before Fedora 33 reaches EOL.

We provide fresh Fedora 34 template packages through the official Qubes
repositories, which you can install in dom0 by following the standard
installation instructions [3]. Alternatively, we also provide
step-by-step instructions for performing an in-place upgrade [4] 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 [5].

For a complete list of template releases supported for your specific
Qubes releases, see our supported template releases [6].

Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL [7].

*Note for 4.1 release candidate testers:* Qubes R4.1-rc1 already
includes the Fedora 34 template by default, so no action is required.


[1] https://fedoraproject.org/wiki/End_of_life
[2] https://www.qubes-os.org/doc/templates/fedora/#upgrading
[3] https://www.qubes-os.org/doc/templates/fedora/#installing
[4] https://www.qubes-os.org/doc/template/fedora/upgrade/
[5] https://www.qubes-os.org/doc/templates/#switching
[6] https://www.qubes-os.org/doc/supported-releases/#templates
[7] 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/2021/11/11/fedora-33-approaching-eol-fedora-34-templates-available/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/36a8ffa8-3e08-7604-0cbb-4c3a7fb05893%40qubes-os.org.

Re: [qubes-users] Start disposable

[Andrew David Wong]

On 11/2/21 6:14 PM, Franz wrote:

Hello
the documented way to start a disposable from dom0 is:

$ qvm-run --dispvm= --service qubes.StartApp+firefox


however this works well when the disposable template is based on Fedora,
but when it is based on Debian it gives me the following error:
disp6615: command failed with code: 1
any idea?



Is it possible that the command you're attempting to execute is not 
being found in the disposable, e.g., because Firefox is not installed in 
the template on which that disposable is (ultimately) based or because 
the proper command to run it is different from `firefox`?


--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ec96037d-07b3-8e19-047f-d991a2c6b5f3%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] QSB-073: Race condition when setting override-redirect flag

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 073: Race condition
when setting override-redirect flag. The text of this QSB is reproduced
below. This QSB and its accompanying signatures will always be available
in the Qubes Security Pack (qubes-secpack).

View QSB-073 in the qubes-secpack:



In addition, you may wish to:

- Get the qubes-secpack: 
- View all past QSBs: 
- View the XSA Tracker: 

```

 ---===[ Qubes Security Bulletin 073 ]===---

  2021-10-15

 Race condition when setting override-redirect flag


User action required
-

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

  For Qubes 4.0, in dom0:
  - qubes-gui-dom0 version 4.0.17

  For Qubes 4.1, in dom0 and the template(s) of any GUI qube(s) [1]:
  - qubes-gui-daemon version 4.1.18

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. [2] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [3]

The user session must be restarted afterward in order for the updates to
take effect, e.g., by logging out then logging back in.


Summary


An override-redirect flag in the X11 protocol tells the window manager
not to manage a particular window. Windows with such flags do not get
their frames or title bars from the window manger, nor does the window
manager determine their positions. This feature is used for application
menus, tooltips, and similar accessory windows.

Unfortunately, some window managers get confused if the
override-redirect flag is set shortly before making the window visible.
When that happens, the window manager may try to move or resize the
window without respecting any size and position constraints imposed by
the GUI daemon. Normally, every window move and resize action requested
by the VM is validated by the GUI daemon. However, if the action is
initiated by the window manager, it doesn't require the GUI daemon's
validation.


Impact
---

A malicious application may try to hide its unspoofable colored frame
off-screen. Hiding all four sides is prevented by another constraint
(forbidding a override-redirect window from covering more than 90% of
the screen), but hiding some sides is possible. The issue is known to
affect XFCE and KDE. Other desktop environments may also be affected.


Discussion
---

This is yet another corner case in handling the override-redirect flag.
In the long term, we will try to eliminate use of this flag completely.
As an immediate fix, we are adding additional validation of constraints
placed on windows with the override-redirect flag. This validation is
done whenever a window is moved or resized, regardless of what initiated
the action. If an illegal size or position is detected, the GUI daemon
will try to resize or move the window back to a legal size and position.
While this is a reactive solution (in the sense that it allows windows
to enter illegal states before correcting them), it will cover several
more cases, including the case in which another application resizes a
window behind the GUI daemon's back (which is the case being reported in
this QSB). Moreover, this solution serves as an additional safety check
in case the GUI daemon itself misses any other edge cases.


Credits


This issue was discovered by Demi Marie Obenour.


Notes
--

[1] In Qubes 4.1, certain GUI functions historically served by dom0 can
be delegated to separate template-based "GUI qubes." A single Qubes
4.1 system can have multiple GUI qubes.
[2] https://www.qubes-os.org/doc/testing/
[3] https://www.qubes-os.org/doc/how-to-update/

--
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/2021/10/15/qsb-073/

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/02f229b0-82bc-762b-1411-4f783d098467%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Systemd terminating qubesd during backup?

[Andrew David Wong]

On 10/12/21 12:31 PM, Marek Marczykowski-Górecki wrote:

On Mon, Oct 11, 2021 at 11:52:59AM -0400, Steve Coleman wrote:

I seem to have an intermittent problem when my backup scripts are running
late at night.



My qubesd is apparently being shutdown (sent a sigterm signal) by systemd
during my long running backup sessions which then causes an eof pipe close
exception and qvm-backup then receives a socket exception and immediately
receives a second exception while still handling the first exception, thus
the qvm-backup process gets forcibly terminated mid stream. Just prior to
the qubesd shutdown I can clearly see that systemd had also
shutdown/restarted the qubes memory manager (qubes-qmemman) too.



Q: What kind of background maintenance processing would actually require
qubesd or the memory manager to be restarted?


I guess that's logrorate (but it isn't clear to me why qubesd too, not
just qubes-qmemman service...).


Q: Could this processing be put on hold during backups?



Q: Or, how could I at least know when this maintenance is scheduled to
happen so I could defer my own processing?


If that's indeed logrotate, see `systemctl status logrotate.timer`


My scripts can certainly trap this error, erase the incomplete backup file,
then loop and check for qubesd to complete its restart, and then finally
restart my own backup processing, but why should this even be necessary?



When this happens its almost always during the backup of my largest VM which
can take well over 90 minutes to complete.  If I can somehow block/defer
this kind of system maintenance until after my backups are complete that
would be better than having to deal with trapping random restarts.


Again, if that's logrotate, you can stop the timer before, and restart it
afterwards.



This sounds like:

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

I agree that it's a serious bug. It makes no sense for logrotate to 
interrupt backups. Backups completing successfully and reliably is 
infinitely more important than rotating log files.


It looks like the issue has been fixed in 4.1, but I'm still 
experiencing on 4.0, as well. I've just gotten in the habit of trying 
not to let my backups run between ~1-6am. :\


--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/748d50de-9c67-ab38-bd46-d2810f5c024d%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] Qubes OS 4.1-rc1 has been released!

[Andrew David Wong]

Dear Qubes Community,

After many years of work, the team is pleased to announce the first
release candidate for Qubes 4.1!

Qubes 4.1 includes several major new features, each of which is
explained in depth in its own article:

- Qubes Architecture Next Steps: The GUI Domain [01]
- Qubes Architecture Next Steps: The New Qrexec Policy System [02]
- New Gentoo templates and maintenance infrastructure [03]
- Reproducible builds for Debian: a big step forward [04]

This release candidate also includes numerous other improvements and
bug fixes, which are listed in the release notes [05] and in the issue
tracker [06].

Finally, Qubes 4.1 features the following updated default components:

- Xen 4.14
- Fedora 32 in dom0
- Fedora 34 template
- Debian 11 template
- Whonix 16 Gateway and Workstation templates
- Linux kernel 5.10

Qubes 4.1-rc1 is available on the downloads [07] page.


How to test Qubes 4.1-rc1
-

If you're willing to test [08] this release candidate, you can help to
improve the stable release by reporting any bugs you encounter [09].
Experienced users are strongly encouraged to join the testing team [10]!

There are two ways to migrate to 4.1-rc1:

- Back up [11] your current installation, perform a fresh
  install [12] of 4.1-rc1, then restore [13] from your backup.
- Perform an in-place upgrade [14].


Release candidate planning
--

As with any initial release candidate, it's likely that user testing
will reveal important bugs that we'll want to fix before the stable
release. Depending on the severity of the bugs discovered and how long
it takes to fix them, we expect that it may be anywhere from a few weeks
to a few months before we announce the second release candidate.


[01] https://www.qubes-os.org/news/2020/03/18/gui-domain/
[02] https://www.qubes-os.org/news/2020/06/22/new-qrexec-policy-system/
[03] 
https://www.qubes-os.org/news/2020/10/05/new-gentoo-templates-and-maintenance-infrastructure/
[04] 
https://www.qubes-os.org/news/2021/10/08/reproducible-builds-for-debian-a-big-step-forward/

[05] https://www.qubes-os.org/doc/releases/4.1/release-notes/
[06] 
https://github.com/QubesOS/qubes-issues/issues?q=milestone%3A%22Release+4.1%22+is%3Aclosed+-label%3A%22R%3A+duplicate%22+-label%3A%22R%3A+invalid%22+-label%3A%22R%3A+cannot+reproduce%22+-label%3A%22R%3A+not+an+issue%22+-label%3A%22R%3A+not+our+bug%22+-label%3A%22R%3A+won%27t+do%22+-label%3A%22R%3A+won%27t+fix%22+

[07] https://www.qubes-os.org/downloads/
[08] https://www.qubes-os.org/doc/testing/
[09] https://www.qubes-os.org/doc/issue-tracking/
[10] https://forum.qubes-os.org/t/joining-the-testing-team/5190
[11] 
https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/#creating-a-backup

[12] https://www.qubes-os.org/doc/installation-guide/
[13] 
https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/#restoring-from-a-backup

[14] https://www.qubes-os.org/doc/upgrade/4.1/

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/10/11/qubes-4-1-rc1/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1e90d5b4-a09a-db3f-92f7-3409c7701e8f%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] New article: "Reproducible builds for Debian: a big step forward" by Frédéric Pierret

[Andrew David Wong]

Dear Qubes Community,

A new article has just been published on the Qubes website:

"Reproducible builds for Debian: a big step forward" by Frédéric Pierret
https://www.qubes-os.org/news/2021/10/08/reproducible-builds-for-debian-a-big-step-forward/

For your convenience, the original Markdown text is reproduced below.



---
layout: post
title: "Reproducible builds for Debian: a big step forward"
categories: articles
author: Frédéric Pierret
---

_This is the second article in the "reproducible builds" series.
Previously: [Improvements in testing and building: GitLab CI and 
reproducible 
builds](https://www.qubes-os.org/news/2021/02/28/improvements-in-testing-and-building/)._


In the previous article, [Improvements in testing and building: GitLab 
CI and reproducible 
builds](https://www.qubes-os.org/news/2021/02/28/improvements-in-testing-and-building/#reproducible-builds), 
we discussed reproducible builds and our current short-term goals for 
them in Qubes OS. Notably, we aimed to start by building our Debian 
templates such that packages can be installed only when configured 
rebuilders confirm that they really came from the source code we 
publish. Today, we go beyond this expectation.


Reproducible builds: retrieve the past
--

The challenge in reproducible builds lies in rebuilding a package in the 
same environment in which it was officially published. This means that 
we need to retrieve every single package version that was used as 
dependency to rebuild a given package. For Debian, some packages in the 
current release were built several releases in the past but not 
necessarily with the exact same dependencies. In order to retrieve them, 
there is only one solution: a Debian service called 
`snapshot.debian.org`, which is an archive acting as a [Wayback 
Machine](https://web.archive.org/) that allows access to old packages 
based on dates and version numbers. It contains all past and present 
packages that the Debian archive provides. Unfortunately, this service 
is known to suffer significant blocking issues on usability. For 
example, watch the DebConf 2021 talk [Making use of snapshot.debian.org 
for fun and 
profit](https://debconf21.debconf.org/talks/22-making-use-of-snapshotdebianorg-for-fun-and-profit/) 
and have a look at some related Debian issues like 
[#977653](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%977653), 
[#960304](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%960304), 
[#969906](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%969906), 
[#969603](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%969603), 
and 
[#782857](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%782857). To 
summarize: There are throttling limits and availability issues such as 
repeatedly cutting off connections, returning partial content, etc. As 
announced in our previous article, we developed our own rebuilder tool, 
[debrebuild](https://github.com/fepitre/debrebuild), which is able to 
rebuild a single Debian package together with a rebuilder orchestrator 
[PackageRebuilder](https://github.com/fepitre/package-rebuilder). We 
started to put it in production in order to actively rebuild Qubes OS 
and Debian packages, but it quickly ceased to function, as the 
`snapshot.debian.org` service was unable to sustain the load of 
rebuilding even a single Debian package. That said, the question was: 
How should we proceed in order to make it work? Clearly, those issues 
are critical and make the `snapshot.debian.org` service awful or useless 
for reproducible builds.


Is rebuilding Debian really possible?
-

The `snapshot.debian.org` issues have still not been addressed even 
after several years. The service has existed for more than a decade, yet 
it still suffers from the aforementioned limitations. It's either a 
design problem or a lack of resources, but we still had to do something.


That's why we decided to create our own 
[snapshot](https://github.com/fepitre/debian-snapshot) service. Easy to 
say, but not to do. First, the original snapshot service from Debian is 
roughly 90 TB of repository data. Second, we cannot download files 
easily because only HTTP(S) is available, and downloading multiple files 
means we are impeded by availability issues.
In order to work around the huge volume of data, we decided to get 
repositories from 2017 to today (which corresponds approximately to when 
Debian "Buster" was released) and only related architectures `amd64`, 
`source`, and `all`. (`all` indicates no specific architecture in the 
Debian world.) For the download part itself, we needed to parse the 
metadata of each Debian repository in order to get the list of files to 
download for every timestamp for which a snapshot had been made. Then, 
we developed `resume` and `retry` download functions, which 
unfortunately are brute force download 

[qubes-users] XSAs released on 2021-10-05

[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-386 (in practice affects only Xen 4.14.3+ due to another bug that 
cancels out this security flaw; the other bug was fixed in 4.14.3, which 
exposed this flaw)



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/2021/10/07/xsas-released-on-2021-10-05/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ab4a42e0-d6cd-22da-dc51-501acf52a5be%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] Whonix 16 template available

[Andrew David Wong]

Dear Qubes Community,

The Whonix Project [1] has announced the release of Whonix 16 [2]. For a 
list of changes and further details, please see the official 
announcement [2].


Please note that, according to the Whonix support schedule [3], Whonix 
15 will reach end-of-life (EOL) in one month. This coincides with the 
end date for Whonix 15 template support in Qubes according to the Whonix 
Project's support policy for Whonix templates in Qubes [4]. Therefore, 
all Whonix users are urged to upgrade from Whonix 15 to Whonix 16 within 
the next month.


The Whonix Project provides instructions for installing fresh Whonix 16 
templates [5] as well as instructions for performing an in-place upgrade 
from Whonix 15 to Whonix 16 [6].



[1] https://www.whonix.org/
[2] https://forums.whonix.org/t/12465
[3] https://www.whonix.org/wiki/About#Support_Schedule
[4] https://www.qubes-os.org/doc/supported-releases/#note-on-whonix-support
[5] https://www.whonix.org/wiki/Qubes/Install
[6] https://www.whonix.org/wiki/Release_Upgrade_Whonix_15_to_Whonix_16

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/09/30/whonix-16-template-available/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3977d0e3-75e2-4d92-a39d-f33f7f08f6e7%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] Re: New mailing list posting policy

[Andrew David Wong]

On 9/24/21 10:29 PM, Andrew David Wong wrote:

Dear Qubes Community,

Due to excessive spam, we have changed the posting policy for our 
mailing lists. All mailing lists now require users to subscribe before 
they'll be able to post. (A Google account is still *not* required to 
subscribe or post to any of our mailing lists; see below.)


Since the qubes-devel list has already had this policy for a long time, 
no changes have been made to the way qubes-devel behaves. Rather, this 
change simply brings all the other mailing lists (qubes-users, 
qubes-project, and qubes-translation) in line with qubes-devel's 
existing behavior.


For information about how to subscribe and post to the mailing lists, 
please see: https://www.qubes-os.org/support/#mailing-lists


Please note: There is a common misconception that a Google account is 
required to interact with the Qubes mailing lists. This is not true. 
Many people simply assume that a Google account is required when they 
see "@googlegroups.com" or try to interact with the Google Groups web 
interface. A Google email address is not required. Any email address 
will do. The Google Groups web interface is also not required for 
viewing these mailing lists on the web, as there are traditional mail 
archives you can use instead. (See the page linked above for links and 
further details.)




Unfortunately, the spammer(s) are now subscribing their spam addresses 
to qubes-users in order to continue sending spam here. We can ban them 
from the member list, but by that time, it's already too late, and they 
can simply use a different email address every time. Therefore, I've 
further changed the qubes-users policy so that all posts from new 
members are moderated. This means that posts from new members must be 
manually approved before they'll be received by the rest of the list's 
members. This change applies only to qubes-users (for now).


--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8eff4bdd-87db-7475-bd41-3dd28d0d210a%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] QSB-072: Inconsistent handling of the override-redirect flag

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 072: Inconsistent 
handling of the override-redirect flag. The text of this QSB is 
reproduced below. This QSB and its accompanying signatures will always 
be available in the Qubes Security Pack (qubes-secpack).


View QSB-072 in the qubes-secpack:



In addition, you may wish to:

- Get the qubes-secpack: 
- View all past QSBs: 

```

 ---===[ Qubes Security Bulletin 072 ]===---

  2021-09-27

 Inconsistent handling of the override-redirect flag


User action required
-

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

  For Qubes 4.0, in dom0:
  - qubes-gui-dom0 version 4.0.15

  For Qubes 4.1, in dom0 and the template(s) of any GUI qube(s) [1]:
  - qubes-gui-daemon version 4.1.16

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. [2] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [3]

The user session must be restarted afterward in order for the updates to
take effect, e.g., by logging out then logging back in.


Summary


An override-redirect flag in the X11 protocol tells the window manager
not to manage a particular window. Windows with such flags do not get
their frames or title bars from the window manger, nor does the window
manager determine their positions. This feature is used for application
menus, tooltips, and similar accessory windows.

Since the window manager ignores such windows, the GUI daemon imposes
certain extra constraints on them, such as drawing thin colored frames.
Unfortunately, there are several cases in which the window manager and
GUI daemon do not agree on the override-redirect flag state, leading to
neither of them imposing the appropriate constraints.


Impact
---

Normally, every window in Qubes OS has an unspoofable colored frame,
except for those belonging to dom0 or a GUI qube. [1] The flaws
described in this bulletin allow a malicious qube to create a window
that has no such colored frame. Such a window might be made to appear as
though it belongs to a different qube. For example, a malicious qube
with an untrusted color label might draw a passphrase prompt window.
Then, in order to induce the user to enter a valuable passphrase into
this window, the malicious qube might draw a fake frame in a different
color (more trusted than its own) along the inside edge of the window.
Since the window has no externally-imposed colored frame of its own, the
user might be deceived into accepting the fake internally-drawn frame as
a reliable indicator of the window's trust level or origin.

Such windows are also capable of bypassing limits normally imposed on
windows with the override-redirect flag. For example, such windows are
capable of covering desktop environment panels, potentially preventing
users from interacting with certain parts of the system or displaying
fake interface elements. Since such windows also lack colored frames,
they could be made to appear as though they belong to dom0 or a GUI qube
in an attempt to deceive users into believing that they are interacting
with trusted parts of the system.


Discussion
---

There were several cases in which the GUI daemon's view of the
override-redirect flag did not match the window manager's expectations:

1. Using an MSG_CONFIGURE GUI protocol [4] command to change the
   override-redirect flag of a window that has already been mapped
   (i.e., made visible). In this case, the GUI daemon saved the new
   state of the flag (and thus stopped applying its own constraints),
   but it had not yet sent this flag to the X server.

2. Using an MSG_MAP GUI protocol [4] command to change the
   override-redirect flag of a window that has already been mapped. In
   this case, the attribute was updated in the X server, but the window
   manager did not pick up the change, since the window was already
   mapped.

3. The override-redirect protection feature, which prevents a window
   from covering more than 90% of the screen if it has the
   override-redirect flag, suffered from the same problem described in
   the first point.

4. It was unclear how docked windows (aka "tray icons") should interact
   with the override-redirect flag. Neither the XEmbed Protocol
   Specification [5] nor the System Tray Protocol Specification [6]
   defines how they should interact.

5. Docking a window passes control over mapping and unmapping the window
   to the embedder (the application that "holds" the docked windows).
   The implications of this behavior are unclear, and we cannot rule
   out the 

[qubes-users] New mailing list posting policy

[Andrew David Wong]

Dear Qubes Community,

Due to excessive spam, we have changed the posting policy for our 
mailing lists. All mailing lists now require users to subscribe before 
they'll be able to post. (A Google account is still *not* required to 
subscribe or post to any of our mailing lists; see below.)


Since the qubes-devel list has already had this policy for a long time, 
no changes have been made to the way qubes-devel behaves. Rather, this 
change simply brings all the other mailing lists (qubes-users, 
qubes-project, and qubes-translation) in line with qubes-devel's 
existing behavior.


For information about how to subscribe and post to the mailing lists, 
please see: https://www.qubes-os.org/support/#mailing-lists


Please note: There is a common misconception that a Google account is 
required to interact with the Qubes mailing lists. This is not true. 
Many people simply assume that a Google account is required when they 
see "@googlegroups.com" or try to interact with the Google Groups web 
interface. A Google email address is not required. Any email address 
will do. The Google Groups web interface is also not required for 
viewing these mailing lists on the web, as there are traditional mail 
archives you can use instead. (See the page linked above for links and 
further details.)


--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/07983061-bfcd-5935-59f4-e2314d615d55%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] [Update] QSB-071: Fatal options filtering flaw in Split GPG

[Andrew David Wong]

On 9/9/21 3:29 PM, Andrew David Wong wrote:

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 071: Fatal options 
filtering flaw in Split GPG. The text of this QSB is reproduced below. 
This QSB and its accompanying signatures will always be available in the 
Qubes Security Pack (qubes-secpack).


View QSB-071 in the qubes-secpack:

<https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-071-2021.txt> 



In addition, you may wish to:

- Get the qubes-secpack: <https://www.qubes-os.org/security/pack/>
- View all past QSBs: <https://www.qubes-os.org/security/qsb/>



Please note that QSB-071 was updated on 2021-09-17. The updated version, 
including the changelog, is reproduced below.


```

 ---===[ Qubes Security Bulletin 071 ]===---

 2021-09-09

  Fatal options filtering flaw in Split GPG

Changelog
--

2021-09-09: Original QSB published
2021-09-17: Updated impact section


User action required
-

Users must install the following specific packages in order to address the
issues discussed in this bulletin:

  For Qubes 4.0, in templates and standalones:
  - qubes-gpg-split 2.0.53

  For Qubes 4.1, in templates and standalones:
  - qubes-gpg-split 2.0.53

Due to the ease with which this flaw can be exploited, we are immediately
migrating these packages to the current (stable) repository, bypassing the
usual testing period. These packages are to be installed via the Qubes 
Update

tool or its command-line equivalents. [1]


Summary


Split GPG [2] is designed to isolate private keys from the application using
them in order to protect them from being extracted and to allow the user to
retain control over when they are used. This isolation is implemented by
forwarding calls to `gpg` into a backend qube that holds the private 
keys and
allowing only specific `gpg` options. This option filtering mechanism 
rejects
options like `--export-secret-keys` and others that might leak private 
keys to

the frontend qube. Unfortunately, several options were declared incorrectly,
which allowed this filtering mechanism to be bypassed.


Impact
---

An attacker controlling a frontend qube (where `qubes-gpg-client` is 
executed)

can execute arbitrary commands and extract arbitrary files (including secret
keys) from the backend qube.


Discussion
---

Several `gpg` options were declared incorrectly in Split GPG, which 
resulted in

Split GPG interpreting them differently than `gpg`. If Split GPG interpreted
one option as an argument to another option, Split GPG would allow it, since
option filtering is performed at the level of the options themselves, 
not their
arguments. This would allow options misinterpreted as arguments to 
bypass the

filtering mechanism. Specifically:

- All `--s2k-*` options were declared as not taking arguments when in 
fact they

  do take arguments.
- `--export-ssh-key` was declared as taking an argument when it doesn't take
  one directly; it does change the meanings of positional arguments, 
however.

- `--with-colons` was aliased with `-k`, which differs in its argument
  requirements.
- `--default-recipient`, which takes an argument, was interpreted as
  `--default-recipient-self`, which does not take an argument.
- `--display` was interpreted as `--display-charset`, which resulted in
  `--display` being allowed when it should have been denied.

For our immediate, initial response, we have corrected all of these
inconsistencies and added automated testing to verify that GnuPG and 
Split GPG

both understand the options in the same way.

More generally, we will prioritize finishing Split GPG 2 [3], which does not
rely on option filtering at all. Instead, it uses `gpg-agent`'s protocol to
delegate only secret key processing to the backend qube. In addition to
obviating the need for fragile option filtering, this dramatically 
reduces the

attack surface, as most of the untrusted data processing is done in the
frontend qube and never reaches the backend qube.

Credits


This issue was discovered by Demi Marie Obenour.

References
---

[1] https://www.qubes-os.org/doc/updating-qubes-os/
[2] https://www.qubes-os.org/doc/split-gpg/
[3] https://github.com/QubesOS/qubes-issues/issues/474

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

This updated announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/09/09/qsb-071/

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/019d7142-b64b-9323-8f9f-a1465a7a53c5%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] QSB-071: Fatal options filtering flaw in Split GPG

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 071: Fatal options 
filtering flaw in Split GPG. The text of this QSB is reproduced below. 
This QSB and its accompanying signatures will always be available in the 
Qubes Security Pack (qubes-secpack).


View QSB-071 in the qubes-secpack:



In addition, you may wish to:

- Get the qubes-secpack: 
- View all past QSBs: 

```

 ---===[ Qubes Security Bulletin 071 ]===---

 2021-09-09

  Fatal options filtering flaw in Split GPG


User action required
-

Users must install the following specific packages in order to address the
issues discussed in this bulletin:

  For Qubes 4.0, in templates and standalones:
  - qubes-gpg-split 2.0.53

  For Qubes 4.1, in templates and standalones:
  - qubes-gpg-split 2.0.53

Due to the ease with which this flaw can be exploited, we are immediately
migrating these packages to the current (stable) repository, bypassing the
usual testing period. These packages are to be installed via the Qubes 
Update

tool or its command-line equivalents. [1]


Summary


Split GPG [2] is designed to isolate private keys from the application using
them in order to protect them from being extracted and to allow the user to
retain control over when they are used. This isolation is implemented by
forwarding calls to `gpg` into a backend qube that holds the private 
keys and
allowing only specific `gpg` options. This option filtering mechanism 
rejects
options like `--export-secret-keys` and others that might leak private 
keys to

the frontend qube. Unfortunately, several options were declared incorrectly,
which allowed this filtering mechanism to be bypassed.


Impact
---

An attacker controlling a frontend qube (where `qubes-gpg-client` is 
executed)
can extract an arbitrary file (including a secret key) from the backend 
qube.



Discussion
---

Several `gpg` options were declared incorrectly in Split GPG, which 
resulted in

Split GPG interpreting them differently than `gpg`. If Split GPG interpreted
one option as an argument to another option, Split GPG would allow it, since
option filtering is performed at the level of the options themselves, 
not their
arguments. This would allow options misinterpreted as arguments to 
bypass the

filtering mechanism. Specifically:

- All `--s2k-*` options were declared as not taking arguments when in 
fact they

  do take arguments.
- `--export-ssh-key` was declared as taking an argument when it doesn't take
  one directly; it does change the meanings of positional arguments, 
however.

- `--with-colons` was aliased with `-k`, which differs in its argument
  requirements.
- `--default-recipient`, which takes an argument, was interpreted as
  `--default-recipient-self`, which does not take an argument.
- `--display` was interpreted as `--display-charset`, which resulted in
  `--display` being allowed when it should have been denied.

For our immediate, initial response, we have corrected all of these
inconsistencies and added automated testing to verify that GnuPG and 
Split GPG

both understand the options in the same way.

More generally, we will prioritize finishing Split GPG 2 [3], which does not
rely on option filtering at all. Instead, it uses `gpg-agent`'s protocol to
delegate only secret key processing to the backend qube. In addition to
obviating the need for fragile option filtering, this dramatically 
reduces the

attack surface, as most of the untrusted data processing is done in the
frontend qube and never reaches the backend qube.

Credits


This issue was discovered by Demi Marie Obenour.

References
---

[1] https://www.qubes-os.org/doc/updating-qubes-os/
[2] https://www.qubes-os.org/doc/split-gpg/
[3] https://github.com/QubesOS/qubes-issues/issues/474

--
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/2021/09/09/qsb-071/

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cae04c7d-7167-fdf1-da57-99cb61e00b8c%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] XSAs released on 2021-09-08

[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* by one or more of these XSAs.
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-384 (already covered by the fix for QSB-070)


Related links
-

 - Xen Project 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/2021/09/08/xsas-released-on-2021-09-08/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f5f6e66f-2656-0a7e-d86a-9d3d9a22f450%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] Qubes Canary 028

[Andrew David Wong]

Dear Qubes community,

We have published Qubes Canary 028. The text of this canary is
reproduced below. Please note that this canary contains an announcement
and is accompanied by two letters, which are also reproduced below.

## General information

This canary and its accompanying signatures will always be available in
the Qubes security pack (qubes-secpack).

View Qubes Canary 028 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-028-2021.txt

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

https://www.qubes-os.org/security/pack/

View all past canaries:

https://www.qubes-os.org/security/canary/

## Qubes Canary 028

```

---===[ Qubes Canary 028 ]===---


Statements
---

The Qubes core developers who have digitally signed this file [1] state
the following:

1. The date of issue of this canary is August 31, 2021.

2. There have been 70 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 2021. 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
--

Joanna Rutkowska will soon begin traveling without her Qubes laptop for
extended periods of time, which means she will not be able to sign
future canaries on time. She has asked the members of the Qubes security
team, Marek Marczykowski-Górecki and Simon Gaiser, to be released of her
obligation to sign canaries, and she has reaffirmed that she destroyed
all copies of the Qubes Master Signing Key in her possession when she
transferred the project lead position to Marek. The Qubes security team
has agreed to her request. Therefore, this will be the last Qubes canary
signed by Joanna.

Note that this canary is being published one day ahead of schedule
because this is the last day Joanna is available to sign. In addition to
the usual detached signatures from all three aforementioned individuals,
this canary is also accompanied by letters (with their own detached
signatures), all of which can be found in the canary directory in the
qubes-secpack [3].

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, 31 Aug 2021 00:03:05 +

Source: DER SPIEGEL - International 
(https://www.spiegel.de/international/index.rss)
Afghan Vice President in Letter to DER SPIEGEL: "A Deal for Surrender 
Won't Happen"

Afghanistan Disaster: Debacle in Kabul Could Overshadow Biden's Presidency
The End of the German Airlift: What Will Become of the Afghans Left Behind?
Terror Expert on Afghanistan: "The Real Threat Is Islamic State, not 
Al-Qaida"

Redistributing Mafia Assets: The Palaces and Ruins of the Drug Bosses

Source: NYT > World News 
(https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Afghanistan Live Updates: The U.S. Occupation Is Over, Ending America’s 
Longest War

U.S. Conducts Drone Strike in Kabul and Winds Down Airlift as Deadline Nears
Colombia’s Troubles Put a President’s Legacy on the Line
North Korea Restarted Plutonium-Producing Reactor, U.N. Agency Warns
How 2 Afghan Paralympians Defied the Odds to Get From Kabul to Tokyo

Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Afghanistan: US investigates civilian deaths in Kabul strike
Hurricane Ida: One million people in Louisiana without power
Covid: EU recommends new travel restrictions for US as cases rise
Brazil bank robbers tie hostages to getaway cars in Araçatuba
China cuts children's 

Re: [qubes-users] resume from suspend issue after QSB-070

[Andrew David Wong]

On 8/30/21 5:39 PM, Andrew David Wong wrote:

On 8/30/21 2:12 PM, haaber wrote:



Kind of answering my own question, but disabling hyperthreading
happened to
be a workaround for the resume from suspend issue.


But shouldn't hyperthreading have already been disabled ever since 
QSB-043?


https://www.qubes-os.org/news/2018/09/02/qsb-43/


I admit that I missed that one as well. Shame on me. Is there some way
to detect active hyperthreading on boot && print out a big red warning ?

That seems a reasonable measure, especially for new-comers how cannot
reasonably be asked to read all old QSB's first :)



I'm confused. I was under the impression that Qubes OS (after the 
QSB-043 patches) automatically disables hyper-threading for you such 
that you don't have to know anything, do anything, or read any past QSBs.


As QSB-043 explains, you would have had to follow special instructions 
to re-enable hyper-threading in Qubes 3.2, and no such instructions were 
provided for re-enabling it in Qubes 4.0 (since, as the QSB explains, 
it's never safe in that release), so I don't even know how'd you do it 
in that release.


But perhaps I'm mistaken or misunderstanding the question.



Ah, a thought just occurred to me. As QSB-043 states, "A CPU
microcode update is required to take advantage of [these patches]." 
Perhaps the problem is that certain CPUs never received the required 
microcode updates, which explains why some users seem to have CPUs with 
hyper-threading enabled even though it's been years since QSB-043. Could 
that be it?


Of course, it's generally also possible to disable hyper-threading in 
one's BIOS/EFI settings, regardless of whether it's disabled in Xen, and 
this does seem like a prudent measure given the risks associated with 
having it enabled and given the fact that Xen-level disablement appears 
to be hit-or-miss. So, perhaps your suggestion about detecting and 
warning about active hyper-threading might be a good idea after all. 
Please feel free to open an enhancement request.


--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/981e1775-e148-efc1-f2c8-6a457da618a3%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] resume from suspend issue after QSB-070

[Andrew David Wong]

On 8/30/21 2:12 PM, haaber wrote:



Kind of answering my own question, but disabling hyperthreading
happened to
be a workaround for the resume from suspend issue.


But shouldn't hyperthreading have already been disabled ever since 
QSB-043?


https://www.qubes-os.org/news/2018/09/02/qsb-43/


I admit that I missed that one as well. Shame on me. Is there some way
to detect active hyperthreading on boot && print out a big red warning ?

That seems a reasonable measure, especially for new-comers how cannot
reasonably be asked to read all old QSB's first :)



I'm confused. I was under the impression that Qubes OS (after the 
QSB-043 patches) automatically disables hyper-threading for you such 
that you don't have to know anything, do anything, or read any past QSBs.


As QSB-043 explains, you would have had to follow special instructions 
to re-enable hyper-threading in Qubes 3.2, and no such instructions were 
provided for re-enabling it in Qubes 4.0 (since, as the QSB explains, 
it's never safe in that release), so I don't even know how'd you do it 
in that release.


But perhaps I'm mistaken or misunderstanding the question.

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a25ef0f0-6fb8-a710-2de8-4c2fd975c7c8%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] resume from suspend issue after QSB-070

[Andrew David Wong]

On 8/26/21 1:55 PM, Mustafa Kuscu wrote:

Kind of answering my own question, but disabling hyperthreading happened to
be a workaround for the resume from suspend issue.


But shouldn't hyperthreading have already been disabled ever since QSB-043?

https://www.qubes-os.org/news/2018/09/02/qsb-43/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6a2ea46d-16fd-e859-173e-88796ccdec02%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Qubes-backup verify only verifies dom0, not appVMs

[Andrew David Wong]

On 8/26/21 6:17 AM, tetrahedra via qubes-users wrote:

On Wed, Aug 25, 2021 at 07:31:33AM -0700, Andrew David Wong wrote:

And in fact only dom0 gets verified, the others seem to be ignored.



I cannot seem to reproduce this. My verify-only attempts also verify 
domUs. I'm using the same qvm-backup-restore command, just without 
`--verbose`.


That's very strange. Are restore settings stored anywhere on the local
machine, like how VMs can have an "exclude from backups" option?



It's possible to create "backup profiles," but I haven't personally used 
them, so I'm not familiar with the details of how they work. This option 
is mentioned in the `--help` text for qvm-backup but not qvm-backup-restore.


--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5cb81b31-43a2-bd70-556e-56329dce446a%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Qubes-backup verify only verifies dom0, not appVMs

[Andrew David Wong]

On 8/25/21 4:03 AM, tetrahedra via qubes-users wrote:

When I verify my backups, it happens ~instantaneously. It used to take
hours, because it would extract every VM backup and verify it. Judging
by the logs, it's only verifying dom0.

Unless something has changed with how Qubes verifies its backups, there
may be a bug that causes verification to only check dom0, rather than
verifying the AppVMs as well.

This is really bad, because what I care about is the data in the
AppVMs... being able to restore the AppVMs is more important than being
able to restore dom0!


Here's how I back up:
```
nice qvm-backup \
 --verbose \
 --passphrase-file $PASSFILE \
 --exclude $IGNORE_VM \
 --dest-vm $DEST_VM \
 --compress \
 --yes \
 $BACKUP_DIR
```

And here's how I restore:
```
qvm-backup-restore \
 --dest-vm $DEST_VM \
 --passphrase-file $PASSFILE \
 --verify-only \
 --verbose \
 $BACKUP_FILE
```

When it starts restoring, it shows that none of my VMs will be restored,
except for dom0:
```
The following VMs are included in the backup:

+--+---+-++ 

    name | type |  template |   
netvm |  label |
+--+---+-++ 

    dom0 |  AdminVM |   n/a |   
(default) |  black |
    myvm | StandaloneVM |   n/a | 
my-net-vm-x | orange | <-- Excluded from restore
     my-other-vm-xxx |    AppVM | debian-10 |   
(default) |   blue | <-- Excluded from restore
   another-vm-xx |    AppVM | fedora-33 |   
(default) |  green | <-- Excluded from restore

   [... continuing for the list of all VMs ...]
```

And in fact only dom0 gets verified, the others seem to be ignored.



I cannot seem to reproduce this. My verify-only attempts also verify 
domUs. I'm using the same qvm-backup-restore command, just without 
`--verbose`.


--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/048fc3f8-aa41-bb19-5ca0-77cac43d872b%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] XSAs released on 2021-08-25

[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* by one or more of these XSAs.
Therefore, *user action is required*.


XSAs that affect the security of Qubes OS (user action required)


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

  - XSA-378
  - XSA-379
  - XSA-382

Please see *QSB-070* for the actions users must take in order to protect
themselves, as well as further details about these XSAs:

<https://www.qubes-os.org/news/2021/08/25/qsb-070/>


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-380 (denial of service only)
  - XSA-383 (affects only Arm systems)


Related links
-

  - Xen Project 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/2021/08/25/xsas-released-on-2021-08-25/>

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org



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


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] QSB-070: Xen issues related to grant tables v2 and IOMMU

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 070:
Xen issues related to grant tables v2 and IOMMU.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack 
(qubes-secpack).


View QSB-070 in the qubes-secpack:



In addition, you may wish to:

- Get the qubes-secpack: 
- View all past QSBs: 
- View the XSA Tracker: 

```


  ---===[ Qubes Security Bulletin 070 ]===---

  2021-08-25


Xen issues related to grant tables v2 and IOMMU
 (XSA-378, XSA-379, XSA-382)


User action required
=

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

   For Qubes 4.0, in dom0:
   - Xen packages, version 4.8.5-35

   For Qubes 4.1, in dom0:
   - Xen packages, version 4.14.2-2

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update Tool or its command-line equivalents. [2]

Dom0 must be restarted afterward in order for the updates to take
effect.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.


Summary


The following security advisories were published on 2021-08-25:

XSA-378 [3] "IOMMU page mapping issues on x86":

| Both AMD and Intel allow ACPI tables to specify regions of memory
| which should be left untranslated, which typically means these
| addresses should pass the translation phase unaltered.  While these
| are typically device specific ACPI properties, they can also be
| specified to apply to a range of devices, or even all devices.
|
| On all systems with such regions Xen failed to prevent guests from
| undoing/replacing such mappings (CVE-2021-28694).
|
| On AMD systems, where a discontinuous range is specified by firmware,
| the supposedly-excluded middle range will also be identity-mapped
| (CVE-2021-28695).
|
| Further, on AMD systems, upon de-assigment of a physical device from a
| guest, the identity mappings would be left in place, allowing a guest
| continued access to ranges of memory which it shouldn't have access to
| anymore (CVE-2021-28696).
|

XSA-379 [4] "grant table v2 status pages may remain accessible after
de-allocation":

| Guest get permitted access to certain Xen-owned pages of memory.  The
| majority of such pages remain allocated / associated with a guest for
| its entire lifetime.  Grant table v2 status pages, however, get
| de-allocated when a guest switched (back) from v2 to v1.  The freeing
| of such pages requires that the hypervisor know where in the guest
| these pages were mapped.  The hypervisor tracks only one use within
| guest space, but racing requests from the guest to insert mappings of
| these pages may result in any of them to become mapped in multiple
| locations.  Upon switching back from v2 to v1, the guest would then
| retain access to a page that was freed and perhaps re-used for other
| purposes.
|
| A malicious guest may be able to elevate its privileges to that of the
| host, cause host or guest Denial of Service (DoS), or cause information
| leaks.

XSA-382 [5] "inadequate grant-v2 status frames array bounds check"
| The v2 grant table interface separates grant attributes from grant
| status.  That is, when operating in this mode, a guest has two tables.
| As a result, guests also need to be able to retrieve the addresses that
| the new status tracking table can be accessed through.
|
| For 32-bit guests on x86, translation of requests has to occur because
| the interface structure layouts commonly differ between 32- and 64-bit.
|
| The translation of the request to obtain the frame numbers of the
| grant status table involves translating the resulting array of frame
| numbers.  Since the space used to carry out the translation is limited,
| the translation layer tells the core function the capacity of the array
| within translation space.  Unfortunately the core function then only
| enforces array bounds to be below 8 times the specified value, and would
| write past the available space if enough frame numbers needed storing.
|
| Malicious or buggy guest kernels may be able to mount a Denial of
| Service (DoS) attack affecting the entire system.  Privilege escalation
| and information leaks cannot be ruled out.


Impact
===

XSA-378:

As the Xen Security Team explains, "The precise impact is system
specific, but can - on affected systems - be any or all of privilege
escalation, denial of service, or information leaks." Only 

[qubes-users] Re: "Qubes virtual mini-summit 2021!" by Marek Marczykowski-Górecki

[Andrew David Wong]

On 7/29/21 10:55 PM, Andrew David Wong wrote:

Dear Qubes Community,

Marek Marczykowski-Górecki has published the following announcement:

"Qubes virtual mini-summit 2021!"
https://www.qubes-os.org/news/2021/07/30/minisummit-agenda/



Just a quick reminder that the second day of the Qubes virtual 
mini-summit is today starting at 18:00 UTC!


--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f1f05ef6-a48c-f90b-4c23-175dfc33b1c2%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] How can I install new software in DOM0 ?

[Andrew David Wong]

On 8/7/21 5:27 AM, qubes user wrote:

How can I install a screen recorder program in DOM0. I tried to install
"OBS" or "simplescreenrecorder" but everything I tried failed. Could you
please explain how I can install a program in dom0?



https://www.qubes-os.org/doc/how-to-install-software-in-dom0/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c636f930-d3c2-2712-c116-233eb85092b7%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Re: How to join the new Qubes OS testing team (message from deeplow & unman)

[Andrew David Wong]

On 7/29/21 9:05 AM, Yethal wrote:

Does running automated tests on own hardware count as being part of testing
team? I have some spare machines I can dedicate to that



Thanks! That's a good question. I'm not entirely certain. It might be 
best to ask this in the testing section of the forum.


--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a231295c-204d-1927-168d-2099fb475cf7%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] "Qubes virtual mini-summit 2021!" by Marek Marczykowski-Górecki

[Andrew David Wong]

Dear Qubes Community,

Marek Marczykowski-Górecki has published the following announcement:

"Qubes virtual mini-summit 2021!"
https://www.qubes-os.org/news/2021/07/30/minisummit-agenda/

For plain text email recipients, the original Markdown source of this 
announcement is reproduced below.


-

We are pleased to announce the third annual Qubes mini-summit co-hosted by
[3mdeb](https://3mdeb.com/) and the Qubes OS Project. (For prior year
summaries, agendas, and slides, see
[2019](https://3mdeb.com/events/#Qubes-OS-and-3mdeb-minisummit) and
[2020](https://3mdeb.com/events/#Qubes-OS-and-3mdeb-minisummit2020).) This
year's event will take place across two virtual sessions on August 3 and 10.
Each day, there will be four talks, intermixed with Q time. An 
abstract for
each talk is provided below.  The discussion section will be a live 
meeting on

Jitsi, with details to follow.  The whole event will be also streamed on
[3mdeb's YouTube
channel](https://www.youtube.com/channel/UC_djHbyjuJvhVjfT18nyqmQ), where we
will also accept questions. We invite everyone interested to join!

## Agenda for August 3

| Time (UTC) | Event description
| -- | -
| 18:00 -- 18:15 | Welcome and introduction by Piotr Król
| 18:15 -- 19:00 | "Qubes OS 4.1 highlights" by Marek Marczykowski-Górecki
| 19:00 -- 19:45 | "First Impressions Count: Onboarding Qubes Users 
Through an Integrated Tutorial" by deeplow

| 19:45 -- 20:15 | Break
| 20:15 -- 21:00 | "Wyng-backups: revertible local and remote known safe 
Qubes OS states (including dom0)" by Thierry Laurion

| 21:00 -- 21:45 | "SRTM and Secure Boot for VMs" by Piotr Król
| 21:45  | vPub, informal afterparty

## Agenda for August 10

| Time (UTC) | Event description
| -- | -
| 18:00 -- 18:15 | Welcome and introduction by Piotr Król
| 18:15 -- 19:00 | "Usability Within A Reasonably Secure, 
Multi-Environment System" by Nina Alter
| 19:00 -- 19:45 | "Qubes OS Native App Menu: UX Design and 
Implementation" by Marta Marczykowska-Górecka and Nina Alter

| 19:45 -- 20:15 | Break
| 20:15 -- 21:00 | "A brief history of USB camera support in Qubes OS" 
by Piotr Król
| 21:00 -- 21:45 | "How to setup BTC and XMR cold storage in Qubes OS" 
by Piotr Król

| 21:45  | vPub, informal afterparty

## Abstracts of the talks

### "Qubes OS 4.1 highlights" by Marek Marczykowski-Górecki

The upcoming Qubes OS 4.1 release is full of new exciting features, ranging
from a technology preview of the GUI domain to subtle, yet important, Qrexec
improvements. In this talk I will give a brief overview of them and demo a
select few.

### "First Impressions Count: Onboarding Qubes Users Through an 
Integrated Tutorial" by deeplow


We may all relate to having a rough time when starting using Qubes --- 
be that

because we're coming from Windows and everything is different or because we
come from Linux and many things don't work like we expect them to. Apart 
from
the usual challenges of going into a different system, Qubes has the 
additional
one of requiring a fundamentally different way of thinking about your 
computer

(a hypervisor mental-model). Smoothing out this transition is particularly
important as Qubes aims to target vulnerable populations that are less
technically inclined and have less time to explore and read the 
documentation.


The solution proposed by deeplow is to implement an integrated onboarding
tutorial. The idea is that a short tutorial (with optional extra parts) that
guides the user through the essential mechanics of Qubes will make the
transition simpler. That's what deeplow's been working on for his master's
dissertation. In this talk he'll introduce the idea and give an update 
on the

current progress and challenges.

### "Wyng-backups: revertible local and remote known safe Qubes OS 
states (including dom0)" by Thierry Laurion


[Wyng-backups](https://github.com/tasket/wyng-backup) is an incremental
backup/restore tool for LVMs. For Qubes OS, this means even dom0 can be
reverted to a known safe state; locally or remotely, applying changes only.
This talk will be a deep dive into the possibilities of wyng-backups for
deploying and maintaining up to date, revertible states of Qubes OS base
systems.

### "SRTM and Secure Boot for VMs" by Piotr Król

This talk is the continuation of the Qubes OS mini-summit presentation "SRTM
for Qubes OS VMs", where the theoretical background of the Static Root 
of Trust
was presented and discussed. In this presentation, we will practically 
approach

SRTM and Secure Boot for VMs. We will also explore potential use cases for
self-decrypting storage and signed kernels using safeboot. Finally, we will
discuss how to introduce this and other security mechanisms in Qubes OS.

### "Usability Within A Reasonably Secure, Multi-Environment System" by 
Nina Alter


Nina Alter first became aware of exciting 

[qubes-users] How to join the new Qubes OS testing team (message from deeplow & unman)

[Andrew David Wong]

Dear Qubes Community,

The message below is from deeplow and unman. Here's the link to the 
original post on the Qubes Forum:


https://forum.qubes-os.org/t/joining-the-testing-team/5190

--

# Joining the Testing Team

## What's the testing team?

It's a group of users who help make Qubes better.
They commit to testing updates and releases of Qubes OS, and are willing
to provide test results, confirm issues, and identify particular edge cases.
This is key to detecting issues early on, and stop them affecting more 
users.


## What's the risk?

For those willing to enable the testing repositories for the [current 
release](https://www.qubes-os.org/doc/testing/#updates)

the risk is minimal, because the packages will end up in current anyway.

**If security and stability are crucial to you, you should use the 
current stable release,

not enable the testing repositories, and not join the testing team.**

## How to join the testing team?

1. Request to join the testing team
  * **Via forum** (preferred): request to join [here 
](https://forum.qubes-os.org/g/testing-team) (requires JavaScript and a 
forum account)
  * **Via email:** send an email to `register-testing-team at 
forum.qubes-os.org` saying you'd like to join (does not require 
JavaScript or a forum account)


2. Follow the instructions for the kind of testing you want to help with 
(testing updates / releases)


>Testing Type|Instructions|Description|
> --- | --- | --- |
>Testing Updates|[see 
here](https://www.qubes-os.org/doc/testing/#updates)|Enabling the 
testing repositories (e.g. 4.0 testing)|
>Testing Releases|[part 1 
](https://www.qubes-os.org/doc/testing/#releases) & [part 
2](https://www.qubes-os.org/doc/testing/#updates)|Running the upcoming 
Qubes version (e.g. 4.1) and enabling the testing repositories.|


3. Report issues in the appropriate category:
  * **If testing updates**, post in the '4.0 Testing' category, or 
email `testing-updates at forum.qubes-os.org` .
  * **if testing releases**, post in the '4.1 Testing' category, or 
email `testing-releases at forum.qubes-os.org` .


You can leave the group at any time by following steps similar to the 
ones in `1`.


Packages move through the testing process quite quickly. Ideally you
would be able to update at least once a week.

When 4.1 moves toward release, we will see if we can test some of the
open issues in 4.0, and confirm they have been closed.

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/272979cd-7a58-164b-c6b4-ddb58996f76b%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] The Qubes Forum is moving to a new home!

[Andrew David Wong]

Dear Qubes community,

Since the [Qubes Forum](https://qubes-os.discourse.group) first 
[launched](https://www.qubes-os.org/news/2020/08/20/new-discussion-forum-for-qubes-os-users/) 
over nine months ago, it's been far more popular than we anticipated! 
While this has been a pleasant surprise, one consequence is that we've 
outgrown the [free hosting for open source 
projects](https://blog.discourse.org/2018/11/free-hosting-for-open-source-v2/) 
that [Discourse](https://www.discourse.org/) has generously been 
providing to us. As a result, we must switch to a new paid host. We're 
also taking this opportunity to move the forum to our official domain!


In order to ensure a smooth and orderly transition, we're announcing 
these changes well in advance. The move is scheduled for *2021-07-01 
(July 1)*, which is a little over two weeks from the date of this 
announcement. We hope this gives everyone sufficient time to prepare so 
that the transition doesn't come as a surprise.


Once the move has been completed, the forum's new address will be:

<https://forum.qubes-os.org>

*Again, this link will _not_ take you to a fully functional forum until 
the migration on 2021-07-01.*
We hope that this new address better reflects the forum's [official 
nature](https://www.qubes-os.org/support/#forum), as well as being 
intuitive and easy to remember. :)


Rest assured, we'll be taking a full backup of the current forum and 
copying everything over to the new forum, including all categories, 
topics, posts, private messages, and even likes! After the migration, 
the old forum will automatically redirect visitors to the new address 
for at least a few months.


We'd like to thank you, the Qubes community, for making the forum a 
success. Your passion and engagement helps the project grow as we 
continue our journey together. On a personal note, I'd also like to give 
special recognition to a few individuals whose efforts made this forum 
possible to begin with and continue to sustain it. Thank you, 
[deeplow](https://www.qubes-os.org/team/#deeplow), [Simon 
Newton](https://www.qubes-os.org/team/#simon-newton), and [Michael 
Carbone](https://www.qubes-os.org/team/#michael-carbone) for your 
tireless work. We wouldn't have this forum without you!


## Important note for U2F two-factor authentication users

If you're using a U2F key for two-factor authentication (2FA) on the 
forum, you'll have to use a backup code in order to log in on the new 
domain. Alternatively, you can disable two-factor authentication before 
the migration and re-enable it afterward. *Please make sure you have 
either saved a copy of your backup codes or disabled 2FA before 
2021-07-01, or you will be locked out of your forum account!*



This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/06/15/qubes-forum-moving-to-new-home/

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e2253ebb-c0ac-bac2-9e0f-fe1b111d7a5a%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] Qubes Canary 027

[Andrew David Wong]

Dear Qubes Community,

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

https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-027-2021.txt

Learn about the qubes-secpack, including how to obtain, verify, and
read it:

https://www.qubes-os.org/security/pack/

View all past canaries:

https://www.qubes-os.org/security/canaries/

```


---===[ Qubes Canary 027 ]===---


Statements
---

The Qubes core developers who have digitally signed this file [1]
state the following:

1. The date of issue of this canary is June 12, 2021.

2. There have been 69 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
two weeks of September 2021. 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 news feeds quoted below (Proof of freshness) serves to demonstrate
that this canary could not have been created prior to the date stated.
It shows that a series of canaries was not created in advance.

This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to
anybody. None of the signers should be ever held legally responsible
for any of the statements made here.

Proof of freshness
---

Sat, 12 Jun 2021 00:25:17 +

Source: DER SPIEGEL - International 
(https://www.spiegel.de/international/index.rss)

The Telegram Billionaire and His Dark Empire
Biometric Data: How I Lost Control Over My Own Face
France’s War in West Africa: “People Collected Severed Arms, Legs and Heads”
An Interview with Håvard Grip, Chief Pilot of Ingenuity, Nasa's Mars 
Helicopter
A Boost for the CDU: German Conservatives Back on Track as General 
Election Approaches


Source: NYT > World News 
(https://rss.nytimes.com/services/xml/rss/nyt/World.xml)

Cameras Off: G7 Summit Heralds the Return of In-Person Diplomacy
Question Looms Over This Year’s Group of 7: Where Are All the Protesters?
China’s Censorship Widens to Hong Kong’s Vaunted Film Industry, With 
Global Implications

A Fragile Israeli Coalition, With Some Underlying Glue
G7 Live Updates: A Return to Face-to-Face Diplomacy

Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
G7: Boris Johnson kicks off summit with plea to tackle inequality
Israel ex-top spy reveals Mossad operations against Iran
Ethiopia conflict: 33,000 Tigray children risk death from hunger - UN
Teen who filmed George Floyd's murder given journalism award
Oregon lawmaker ousted for allowing rioters into State Capitol

Source: Blockchain.info
000b56dd6255d8c3d53b6363cfb4459114de601ee2ddc96c

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

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/06/14/canary-027/


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d99fdb3f-024a-7dc2-021f-d86821e69142%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] Qubes OS Project now accepting donations in Monero!

[Andrew David Wong]

Dear Qubes Community,

We are pleased to announce that the Qubes OS Project is now accepting 
donations [1] in the privacy-oriented cryptocurrency Monero (XMR) [2] at 
the following address:


```
46PrVgXBdD4cps3SVkHoCDZvMfFdG5q4ej5DYKpuKpTnjiL7pv6KGv7dPh4DPijCGqTbxLDPqZJkobd9SttMiauoP1CQU4y
```

We have received an increasing number of requests for Monero as a 
donation method over the past few years. We are proud that Qubes is the 
OS of choice for so many privacy-conscious individuals, and we are 
pleased to be able to offer a more private donation method for those 
users to show their support.


As with our Bitcoin donation address, you can verify the authenticity of 
the Monero donation address via the Qubes Security Pack [3] in the fund 
[4] directory. We also provide detailed instructions for verifying the 
digital signatures [5].


As with all other donations, your Monero donations will directly fund 
the Qubes OS Project [6]. 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!



[1] https://www.qubes-os.org/donate/
[2] https://www.getmonero.org/
[3] https://www.qubes-os.org/security/pack/
[4] https://github.com/QubesOS/qubes-secpack/tree/master/fund
[5] https://www.qubes-os.org/security/pack/#how-to-obtain-verify-and-read
[6] https://www.qubes-os.org/donate/#how-is-my-donation-used

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/06/11/qubes-os-project-now-accepting-donations-in-monero/

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ae27b656-e8ee-20ab-d28b-02f11fcbd7b4%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Direct link to the "Installing-contributed-packages" page from the docs page?

[Andrew David Wong]

On 6/11/21 3:30 AM, Stumpy wrote:
  


I was just curious why the Installing-contributed-packages [1] page isnt
accessible/have an entry in the main docs [2] page?
I suppose its not a big deal as i know its there but I have ended up
bookmarking it so i didnt have to go to either the news page or dig down
in the docs How to Contribute [3] -> installing contributed packages [1]
-> QubesOS-contrib [4]? I looked through the list in the docs page and
it didnt seem there was a direct link but if there is it wasnt obvious
to me.
I just thought since those contribution packages are *really* useful it
would be good to make them more accessible?
Cheers
  


Links:
--
[1] https://www.qubes-os.org/doc/installing-contributed-packages/
[2] https://www.qubes-os.org/doc/
[3] https://www.qubes-os.org/doc/contributing/
[4] https://github.com/QubesOS-contrib/



Added: 
https://github.com/QubesOS/qubesos.github.io/commit/fe82f3e99e21224d906ae0c14bc6bb89ff3f39bb


Whoever added this page probably just forgot to add it to the index.

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1a3720c5-d0e3-5fc4-bced-6a2a467cde7c%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Re: QSB-069: Multiple Xen and Intel issues

[Andrew David Wong]

On 6/9/21 2:33 PM, Ludovic wrote:

On 6/9/21 @ 23:07, Ulrich Windl wrote :

On 6/9/21 3:06 AM, Andrew David Wong wrote:

After updating today no kernel was offered; I still have:
# rpm -qa kernel\*
kernel-5.4.88-1.qubes.x86_64
kernel-5.4.98-1.fc25.qubes.x86_64
kernel-qubes-vm-5.4.98-1.fc25.qubes.x86_64
kernel-5.4.107-1.fc25.qubes.x86_64
kernel-qubes-vm-5.4.107-1.fc25.qubes.x86_64
kernel-qubes-vm-5.4.88-1.qubes.x86_64

Somehow I'm missing instructions to get that kernel...



Hi Ulrich,

     please, re-read the QSB, you missed **security-testing repository** :

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

     The QSB provides the links to the documentation which explains how 
to update from security-testing, else wait ~2 weeks.


     The kernel update is only if you use `kernel latest` (i.e. 5.5 
kernel), but you use a 5.4 kernel. The xen and intel-microcode update is 
for everyone.


     Same for your post about XScreenSaver : **security-testing 
repository**.


     I did all theses update on my Qubes-OS host, from now, no detected 
issue.




Ludovic is correct. The kernel update is only for people who are using 
`kernel-latest`, as clearly stated in the QSB. You would know if you 
were using `kernel-latest`, as you would've had to take deliberate 
action to start using it. If you never did anything to change from the 
default kernel, then this kernel update doesn't apply to you, and it's 
expected that you would not see any kernel updates associated with this QSB.


--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/68ef299c-8bc9-9fb8-4b61-c23e2d63fc33%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] How to use qvm-open-in-vm?

[Andrew David Wong]

On 6/9/21 1:41 PM, Ulrich Windl wrote:

On 5/31/21 5:12 AM, Sven Semmler wrote:

On 5/30/21 12:37 AM, Adam Mercer wrote:

this opens a dialog asking me to select a target domain


check your /etc/qubes-rpc/policy/qubes.OpenURL

If you want your example to work add this line before all others:

$anyvm browser allow


Curious:
Does the line
$anyvm  $dispvm allow
mean it'll be allowed for any disposable VM?



No, it means that any VM is allowed to cause a new DisposableVM to be 
created in which that type of thing (i.e., file or URL, depending on the 
policy file containing this line) will then be opened.




The first is the source qube ... the one calling qvm-open-in-vm.
The second is the target 'browser' in your example. The third is 
either 'deny', 'ask' or 'allow'




--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8d6d1884-de95-7f21-b046-cb529474d072%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Re: QSB-068: Disconnecting a video output can cause XScreenSaver to crash

[Andrew David Wong]

On 6/9/21 1:58 PM, Ulrich Windl wrote:

On 6/5/21 2:42 AM, Andrew David Wong wrote:

...

User action required
=

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

   For Qubes 4.0, in dom0:
   - xscreensaver 5.45-5

   For Qubes 4.1, in dom0:
   - xscreensaver 5.45-5


...

What could be wrong?

Regards,
Ulrich



You probably already installed the update without knowing it. What is 
the output of `sudo dnf info xscreensaver-base` in dom0?


--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

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


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] XSAs released on 2021-06-08

[Andrew David Wong]

Dear Qubes Community,

The Xen Project has released one or more new Xen Security Advisories (XSAs).
The security of Qubes OS *is affected* by one or more of these XSAs.
Therefore, *user action is required*.


XSAs that affect the security of Qubes OS (user action required)


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

   - XSA-373
   - XSA-374
   - XSA-375
   - XSA-377

Please see QSB-069 for the actions users must take in order to protect 
themselves, as well as further details about these XSAs:


https://www.qubes-os.org/news/2021/06/08/qsb-069/


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-372 (affects only Arm systems)


Related links
-

   - [XSA list (on xen.org)](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/bulletins/)



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

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org





--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/eb911d62-064f-9cf7-37ec-d3a5a41da84a%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] QSB-069: Multiple Xen and Intel issues

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 069: Multiple Xen 
and Intel issues. The text of this QSB is reproduced below. This QSB and 
its accompanying signatures will always be available in the Qubes 
Security Pack (qubes-secpack).


View QSB-069 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-069-2021.txt

Learn about the qubes-secpack, including how to obtain, verify, and read it:

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/bulletins/

```


---===[ Qubes Security Bulletin 069 ]===---

2021-06-08


   Multiple Xen and Intel issues
   (XSA-373, XSA-374, XSA-375, XSA-377, INTEL-SA-00442)


User action required
=

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

 For Qubes 4.0, in dom0:
 - Xen packages, version 4.8.5-34
 - Linux kernel packages, versions 5.12.9-1 (for users of the "latest"
   kernel flavor)
 - microcode_ctl package, version 2.1-33.qubes1 (for Intel CPU users)

 For Qubes 4.1, in dom0:
 - Xen packages, version 4.14.1-5
 - Linux kernel packages, versions 5.10.42-1, 5.12.9-1 (for users of
   the "latest" kernel flavor)
 - microcode_ctl package, version 2.1-33.qubes1 (for Intel CPU users)

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update Tool or its command-line equivalents. [2]

Dom0 must be restarted afterward in order for the updates to take
effect.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.


Summary


The following security advisories were published on 2021-06-08:

XSA-373 [3] "Inappropriate x86 IOMMU timeout detection / handling":

| IOMMUs process commands issued to them in parallel with the operation
| of the CPU(s) issuing such commands.  In the current implementation in
| Xen, asynchronous notification of the completion of such commands is
| not used.  Instead, the issuing CPU spin-waits for the completion of
| the most recently issued command(s).  Some of these waiting loops try
| to apply a timeout to fail overly-slow commands.  The course of action
| upon a perceived timeout actually being detected is inappropriate:
|  - on Intel hardware guests which did not originally cause the timeout
|may be marked as crashed,
|  - on AMD hardware higher layer callers would not be notified of the
|issue, making them continue as if the IOMMU operation succeeded.

XSA-374 [4] "Guest triggered use-after-free in Linux xen-netback":

| A malicious or buggy network PV frontend can force Linux netback to
| disable the interface and terminate the receive kernel thread
| associated with queue 0 in response to the frontend sending a
| malformed packet.
|
| Such kernel thread termination will lead to a use-after-free in Linux
| netback when the backend is destroyed, as the kernel thread associated
| with queue 0 will have already exited and thus the call to
| kthread_stop will be performed against a stale pointer.

XSA-375 [5] "Speculative Code Store Bypass":

| Modern superscalar processors may employ sophisticated decoding and
| caching of the instruction stream to improve performance.  However, a
| consequence is that self-modifying code updates may not take effect
| instantly.
|
| Whatever the architectural guarantees, some CPUs have
| microarchitectural behaviour whereby the stale instruction stream may
| be speculatively decoded and executed.
|
| Speculation of this form can suffer from type confusion in registers,
| and potentially leak data.

XSA-377 [6] "x86: TSX Async Abort protections not restored after S3":

| This issue relates to the TSX Async Abort speculative security
| vulnerability. Please see https://xenbits.xen.org/xsa/advisory-305.html
| for details.
|
| Mitigating TAA by disabling TSX (the default and preferred option)
| requires selecting a non-default setting in MSR_TSX_CTRL.  This
| setting isn't restored after S3 suspend.

INTEL-SA-00442 [7] "Intel® VT-d Advisory":

| A potential security vulnerability in some Intel® Virtualization
| Technology for Directed I/0 (VT-d) products may allow escalation of
| privilege. Intel is releasing firmware updates to mitigate this
| potential vulnerability.

Impact
===

XSA-373:

As the Xen Security Team explains, "A malicious guest may be able to
elevate its privileges to that of the host, cause host or guest Denial
of Service (DoS), or cause information leaks." Only a guest with a PCI
device can leverage this vulnerability, such as `sys-net` or `sys-usb`
in a default Qubes OS configuration.

XSA-374:

A malicious or 

[qubes-users] QSB-068: Disconnecting a video output can cause XScreenSaver to crash

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 068: Disconnecting 
a video output can cause XScreenSaver to crash. The text of this QSB is 
reproduced below. This QSB and its accompanying signatures will always 
be available in the Qubes Security Pack (qubes-secpack).


View QSB-068 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-068-2021.txt

Learn about the qubes-secpack, including how to obtain, verify, and read it:

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/bulletins/

```


 ---===[ Qubes Security Bulletin 068 ]===---

 2021-06-04


 Disconnecting a video output can cause XScreenSaver to crash


User action required
=

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

  For Qubes 4.0, in dom0:
  - xscreensaver 5.45-5

  For Qubes 4.1, in dom0:
  - xscreensaver 5.45-5

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update Tool or its command-line equivalents. [2]

After installing this update, the XScreenSaver daemon process must be
restarted in order for the changes to take effect. This can be done by
restarting dom0, logging out of dom0 then logging back in, or issuing
the following command in a dom0 terminal:

xscreensaver-command -exit; xscreensaver &


Summary


XScreenSaver is the default screen locker in dom0. It tracks which video
outputs are connected to the system in order to blank them properly. In
some specific hardware configurations, disconnecting an output can cause
XScreenSaver to crash, leaving the screen unlocked.

Impact
===

On hardware configurations with more than 10 video outputs that can be
disconnected, an attacker with physical access to a screen-locked system
may be able to unlock it by physically disconnecting one or more
outputs, bypassing standard screen lock authentication.

Details


On X11, screen locking and blanking is done by creating a window that
obscures the whole screen, which is a standard practice. In
XScreenSaver, each such window is assigned a specific property. When a
video output is disconnected, its corresponding blanking window is
destroyed, and its XScreenSaver-specific property is removed so that it
will not be used by `xscreensaver-command` anymore. This is handled by
the `update_screen_layout()` function in the `driver/screens.c` file:

 985 /* Synchronize the contents of si->ssi to the current state of 
the monitors.
 986Doesn't change anything if nothing has changed; otherwise, 
alters and

 987reuses existing saver_screen_info structs as much as possible.
 988Returns True if anything changed.
 989  */
 990 Bool
 991 update_screen_layout (saver_info *si)
 992 {
 993   monitor **monitors = scan_monitors (si);
 994   int count = 0;
 995   int good_count = 0;
...
1009   while (monitors[count])
1010 {
1011   if (monitors[count]->sanity == S_SANE)
1012 good_count++;
1013   count++;
1014 }
1015
1016   if (si->ssi_count == 0)
1017 {
1018   si->ssi_count = 10;
1019   si->screens = (saver_screen_info *)
1020 calloc (sizeof(*si->screens), si->ssi_count);
1021 }
1022
1023   if (si->ssi_count <= good_count)
1024 {
1025   si->ssi_count = good_count + 10;
1026   si->screens = (saver_screen_info *)
1027 realloc (si->screens, sizeof(*si->screens) * 
si->ssi_count);

1028   memset (si->screens + si->nscreens, 0,
1029   sizeof(*si->screens) * (si->ssi_count - 
si->nscreens));

1030 }
...
1092   for (; j < count; j++)
1093 {
1094   saver_screen_info *ssi = >screens[j];
1095   if (!ssi->screensaver_window)
1096 continue;
1097   fprintf (stderr, "%s: %d: screen now unused, disabling.\n",
1098blurb(), j);
1099   /* Undo store_saver_id() so that xscreensaver-command 
doesn't attempt
1100  to communicate with us through this window. It might 
make more
1101  sense to destroy the window, but I'm not 100% sure 
that there are
1102  no outstanding grabs on it that have yet been 
transferred.

1103*/
1104   XDeleteProperty (si->dpy, ssi->screensaver_window,
1105XA_SCREENSAVER_VERSION);
1106 }

The initial portion of the function counts how many outputs are defined
(the `count` variable) and how many of them are connected (the
`good_count` variable). Then, the `si->screens` array is allocated or
re-allocated to fit information about 

[qubes-users] [UPDATE] Re: NitroPad T430 passes hardware certification for Qubes 4.0!

[Andrew David Wong]

UPDATE: Please be advised that the i7-3632QM option is *not* compatible 
with Qubes OS, as it does not support VT-d. The option specifically 
tested by the Qubes team is the i5-3320M.


On 6/1/21 12:23 PM, Andrew David Wong wrote:

Dear Qubes Community,

It is our pleasure to announce that the NitroPad T430 [01] has become
the third Qubes-certified Laptop [02] for Qubes 4.0! This makes Nitrokey
[03] the first vendor to have *two* products that pass Qubes hardware
certification, the other being the NitroPad X230 [04].


## What is Qubes Certified Hardware?

Qubes Certified Hardware [05] is hardware that has been certified by the
Qubes developers as compatible with Qubes OS. Beginning with Qubes 4.0,
in order to achieve certification, the hardware must satisfy a rigorous
set of requirements [06], 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 Laptops [02], in particular, are regularly tested by the
Qubes developers to ensure compatibility with all of Qubes' features.
The developers test all new major versions and updates to ensure that no
regressions are introduced.

It is important to note, however, that Qubes Hardware Certification
certifies only that a particular hardware *configuration* is *supported*
by Qubes. The Qubes OS Project takes no responsibility for any vendor's
manufacturing, shipping, payment, or other practices, nor can we control
whether physical hardware is modified (whether maliciously or otherwise)
*en route* to the user. (However, see below for information about how
this risk is mitigated.)


## About the NitroPad T430

Key features of the NitroPad T430 [01] include:

   - Tamper detection through measured boot with Coreboot [07], Heads
     [08], and Nitrokey USB hardware, including support for Anti Evil
     Maid (AEM) [09]

   - Deactivated Intel Management Engine [10]

   - User-replaceable cryptographic keys

   - Included Nitrokey USB key

   - Professional ThinkPad hardware based on the ThinkPad T430 [11]

   - Security-conscious shipping to mitigate against third-party
     interdiction [12]

For further details, please see the NitroPad T430 [01] product page.


## How to get one

Please see the NitroPad T430 [01] on the Nitrokey website [03] for
purchasing information.


[01] https://shop.nitrokey.com/shop/product/nitropad-t430-119
[02] 
https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptops

[03] https://www.nitrokey.com/
[04] https://www.qubes-os.org/doc/certified-hardware/#nitropad-x230
[05] https://www.qubes-os.org/doc/certified-hardware/
[06] 
https://www.qubes-os.org/doc/certified-hardware/#hardware-certification-requirements 


[07] https://www.coreboot.org/
[08] https://github.com/osresearch/heads/
[09] https://www.qubes-os.org/doc/anti-evil-maid/
[10] https://libreboot.org/faq.html#intelme
[11] https://www.thinkwiki.org/wiki/Category:T430
[12] https://en.wikipedia.org/wiki/Interdiction


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/06/01/nitropad-t430-qubes-certification/




--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

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


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] NitroPad T430 passes hardware certification for Qubes 4.0!

[Andrew David Wong]

Dear Qubes Community,

It is our pleasure to announce that the NitroPad T430 [01] has become
the third Qubes-certified Laptop [02] for Qubes 4.0! This makes Nitrokey
[03] the first vendor to have *two* products that pass Qubes hardware
certification, the other being the NitroPad X230 [04].


## What is Qubes Certified Hardware?

Qubes Certified Hardware [05] is hardware that has been certified by the
Qubes developers as compatible with Qubes OS. Beginning with Qubes 4.0,
in order to achieve certification, the hardware must satisfy a rigorous
set of requirements [06], 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 Laptops [02], in particular, are regularly tested by the
Qubes developers to ensure compatibility with all of Qubes' features.
The developers test all new major versions and updates to ensure that no
regressions are introduced.

It is important to note, however, that Qubes Hardware Certification
certifies only that a particular hardware *configuration* is *supported*
by Qubes. The Qubes OS Project takes no responsibility for any vendor's
manufacturing, shipping, payment, or other practices, nor can we control
whether physical hardware is modified (whether maliciously or otherwise)
*en route* to the user. (However, see below for information about how
this risk is mitigated.)


## About the NitroPad T430

Key features of the NitroPad T430 [01] include:

  - Tamper detection through measured boot with Coreboot [07], Heads
[08], and Nitrokey USB hardware, including support for Anti Evil
Maid (AEM) [09]

  - Deactivated Intel Management Engine [10]

  - User-replaceable cryptographic keys

  - Included Nitrokey USB key

  - Professional ThinkPad hardware based on the ThinkPad T430 [11]

  - Security-conscious shipping to mitigate against third-party
interdiction [12]

For further details, please see the NitroPad T430 [01] product page.


## How to get one

Please see the NitroPad T430 [01] on the Nitrokey website [03] for
purchasing information.


[01] https://shop.nitrokey.com/shop/product/nitropad-t430-119
[02] 
https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptops

[03] https://www.nitrokey.com/
[04] https://www.qubes-os.org/doc/certified-hardware/#nitropad-x230
[05] https://www.qubes-os.org/doc/certified-hardware/
[06] 
https://www.qubes-os.org/doc/certified-hardware/#hardware-certification-requirements

[07] https://www.coreboot.org/
[08] https://github.com/osresearch/heads/
[09] https://www.qubes-os.org/doc/anti-evil-maid/
[10] https://libreboot.org/faq.html#intelme
[11] https://www.thinkwiki.org/wiki/Category:T430
[12] https://en.wikipedia.org/wiki/Interdiction


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/06/01/nitropad-t430-qubes-certification/

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/639e57b0-476b-b4be-5acb-88e8430b2864%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] whonox update fails

[Andrew David Wong]

On 5/31/21 1:56 PM, haaber wrote:

Updating whonix-gw-15
Error on updating whonix-gw-15: Command '['sudo', 'qubesctl',
'--skip-dom0', '--targets=whonix-gw-15', '--show-output', 'state.sls',
'update.qubes-vm']' returned non-zero exit status 1
whonix-gw-15: ERROR (exception list index out of range)

Updating whonix-ws-15
Error on updating whonix-ws-15: Command '['sudo', 'qubesctl',
'--skip-dom0', '--targets=whonix-ws-15', '--show-output', 'state.sls',
'update.qubes-vm']' returned non-zero exit status 1
whonix-ws-15: ERROR (exception list index out of range)


Any hints?  Thank you.



It might be this:

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

I'm basing this on seeing "exception list index out of range" mentioned 
there too, but beyond that, I'm not certain.


--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/47a5a3ee-d369-72c9-19cc-85a44d6488bc%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Re: [qubes-devel] Fedora 32 has reached EOL

[Andrew David Wong]

On 5/25/21 12:02 PM, 'icequbes1' via qubes-users wrote:




Dear Qubes Community,

Fedora 32 has reached EOL (end-of-life [1]). If you have not already
done so, we strongly recommend upgrading [2] your Fedora 32 TemplateVMs
and StandaloneVMs to Fedora 33 immediately. We provide a fresh Fedora 33
TemplateVM package through the official Qubes repositories, which you
can install in dom0 by following the standard installation instructions
[3].



Perhaps everyone is upgrading their templates after this message, but the 
yum.qubes-os.org repository server appears to be down, blocking dom0 updates 
(unless one uses a mirror or the hidden service).



There is an open issue for this now:

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

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5421bec8-c7fc-d1f1-6c6e-c80ac8ebd257%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] Fedora 32 has reached EOL

[Andrew David Wong]

Dear Qubes Community,

Fedora 32 has reached EOL (end-of-life [1]). If you have not already
done so, we strongly recommend upgrading [2] your Fedora 32 TemplateVMs
and StandaloneVMs to Fedora 33 immediately. We provide a fresh Fedora 33
TemplateVM package through the official Qubes repositories, which you
can install in dom0 by following the standard installation instructions
[3]. Alternatively, we also provide step-by-step instructions for
performing an in-place upgrade [4] of an existing Fedora TemplateVM.
After upgrading your TemplateVMs, please remember to switch all qubes
that were using the old template to use the new one [5].

For a complete list of TemplateVM versions supported for your specific
version of Qubes, see Supported TemplateVM Versions [6].

Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL [7].


[1] https://fedoraproject.org/wiki/End_of_life
[2] https://www.qubes-os.org/doc/templates/fedora/#upgrading
[3] https://www.qubes-os.org/doc/templates/fedora/#installing
[4] https://www.qubes-os.org/doc/template/fedora/upgrade/
[5] https://www.qubes-os.org/doc/templates/#switching
[6] https://www.qubes-os.org/doc/supported-versions/#templatevms
[7] https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/05/25/fedora-32-eol/

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e66102bb-1519-f645-5c37-6367a428ff90%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Trouble updating dom0

[Andrew David Wong]

On 5/19/21 1:20 AM, abramelin via qubes-users wrote:

Hello. I just did a fresh install of Qubes R4.0.4, and it fails to update dom0 
when I do it through the Qubes Updater. Here's the error message:

```
Updating dom0

Error on updating dom0: Command '['sudo', 'qubesctl', '--dom0-only', 
'--no-color', 'pkg.upgrade', 'refresh=True']' returned non-zero exit status 1
[ERROR   ] Command '['systemd-run', '--scope', 'qubes-dom0-update', '--quiet', 
'-y', '--clean', '--action=upgrade']' failed with return code: 1
[ERROR   ] stderr: Running scope as unit: 
run-r1316d3efb0a745058090563dc106a7b8.scope
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some 
time...
*** ERROR while receiving updates:
Domain sys-firewall sent not signed rpm: 
qubes-mgmt-salt-4.0.25-1.fc25.noarch.rpm
--> if you want to use packages that were downloaded correctly, use dnf 

directly now

[ERROR   ] retcode: 1
Error running 'pkg.upgrade': Problem encountered upgrading packages. Additional 
info follows:

changes:
 --
result:
 --
 pid:
 6542
 retcode:
 1
 stderr:
 Running scope as unit: run-r1316d3efb0a745058090563dc106a7b8.scope
 Using sys-firewall as UpdateVM to download updates for Dom0; this may 
take some time...
 *** ERROR while receiving updates:
 Domain sys-firewall sent not signed rpm: 
qubes-mgmt-salt-4.0.25-1.fc25.noarch.rpm
 --> if you want to use packages that were downloaded correctly, use 
dnf directly now
 stdout:
```

The message looks self-explanatory to a degree, namely that it receives 

an unsigned rpm, but I don't know if that's the only issue, nor how to solve 
any of it. I did update the fedora-32 TemplateVM beforehand. Any ideas?




This is a known bug. Please see:

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

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

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


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Re: Fedora 32 approaching EOL

[Andrew David Wong]

On 5/12/21 2:52 PM, Ulrich Windl wrote:

On 4/30/21 1:31 AM, Andrew David Wong wrote:

Dear Qubes Community,

Fedora 32 is scheduled to reach EOL (end-of-life [1]) on 2021-05-25.


I have a question on https://www.qubes-os.org/doc/template/fedora/upgrade/:

Towards the end of the update procedure "Detailed instructions for 
standard Fedora TemplateVMs" there is the command

[user@dom0 ~]$ sudo dnf remove qubes-template-fedora-

However I wonder: I did not install a fedora- template per 
instructions, and I wonder about this asymmetry.




I have updated the documentation to address this.

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a0722ba3-95b6-66c5-0a28-bc50c8cdfe8f%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] XSAs released on 2021-05-04

[Andrew David Wong]

Dear Qubes Community,

The Xen Project has released one or more new Xen Security Advisories (XSAs).
The security of Qubes OS *is not affected* by these XSAs.
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-370 (Qubes OS does not support 32-bit PV guests. In Qubes 4.0, 
PV guests cannot switch from 32-bit to 64-bit on their own, and we ship 
only 64-bit kernels. In Qubes 4.1, 32-bit PV is disabled at build time.)



Related links
-

 - Qubes Security Pack (qubes-secpack): 
https://www.qubes-os.org/security/pack/
 - Qubes Security Bulletins (QSBs): 
https://www.qubes-os.org/security/bulletins/

 - XSA Tracker: https://www.qubes-os.org/security/xsa/


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

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

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


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Re: New App Menu Survey! 5-10 minutes of your time (from Nina)

[Andrew David Wong]

On 5/2/21 9:13 AM, Viktor Ransmayr wrote:

Hello community,

a...@qubes-os.org schrieb am Samstag, 1. Mai 2021 um 12:58:17 UTC+2:



I bring the following message from Nina Eleanor Alter, our resident
expert on design and user research:

-

Hello! This survey will only remain live for 14 days, so please take a
few moments, if you are so inclined, to let us know your thoughts on our
work so far on designing a new App Menu specific to Qubes OS. Former
users, new users, longtime users, technical users, and non-technical
users -- we would love to hear from as many folks as possible who have
used or are currently using Qubes.

https://survey.qubes-os.org/index.php?r=survey/index=434783=en



Am I the only one having problems with the two videos about Bessie (
https://vimeo.com/542041258 ) & Jackie ( https://vimeo.com/541946756 )?

What do I have to do to enable sound for MP4 content in Firefox?

With kind regards,

Viktor



It is not entirely clear to me whether there is supposed to be sound in 
the videos. As far as I can tell, I do not think there is supposed to be 
any.


--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/804890ac-d85f-9bc1-d027-8309ee76517f%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] New App Menu Survey! 5-10 minutes of your time (from Nina)

[Andrew David Wong]

Dear Qubes Community,

I bring the following message from Nina Eleanor Alter, our resident 
expert on design and user research:


-

Hello! This survey will only remain live for 14 days, so please take a 
few moments, if you are so inclined, to let us know your thoughts on our 
work so far on designing a new App Menu specific to Qubes OS. Former 
users, new users, longtime users, technical users, and non-technical 
users -- we would love to hear from as many folks as possible who have 
used or are currently using Qubes.


https://survey.qubes-os.org/index.php?r=survey/index=434783=en

-

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/05/01/new-app-menu-survey/

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0ce372db-47ec-de4f-a984-8e263bdb1eb1%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] Fedora 32 approaching EOL

[Andrew David Wong]

Dear Qubes Community,

Fedora 32 is scheduled to reach EOL (end-of-life [1]) on 2021-05-25.

We strongly recommend that all Qubes users upgrade [2] their Fedora
32 TemplateVMs and StandaloneVMs to Fedora 33 before Fedora 32 reaches
EOL.

We provide a fresh Fedora 33 TemplateVM package through the official
Qubes repositories, which you can install in dom0 by following the
standard installation instructions [3]. Alternatively, we also provide
step-by-step instructions for performing an in-place upgrade [4] of an
existing Fedora TemplateVM. After upgrading your TemplateVMs, please
remember to switch all qubes that were using the old template to use
the new one [5].

For a complete list of TemplateVM versions supported for your specific
version of Qubes, see Supported TemplateVM Versions [6].

Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL [7].

[1] https://fedoraproject.org/wiki/End_of_life
[2] https://www.qubes-os.org/doc/templates/fedora/#upgrading
[3] https://www.qubes-os.org/doc/templates/fedora/#installing
[4] https://www.qubes-os.org/doc/template/fedora/upgrade/
[5] https://www.qubes-os.org/doc/supported-versions/#templatevms
[6] https://www.qubes-os.org/doc/templates/#switching
[7] https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/04/29/fedora-32-approaching-eol/

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/693f7ce1-1074-a4bb-a053-82edcc34684c%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] Re: Get paid to support Qubes development through automated testing! (six-month contract)

[Andrew David Wong]

On 4/10/21 8:28 AM, Andrew David Wong wrote:

Dear Qubes Community,

The Qubes OS Project is seeking an expert in automated testing. We use
OpenQA and Travis to test changes to the Qubes OS source code and
automated building from source. We're looking for someone who can help
with improving both the automated tests themselves and the testing
infrastructure.

This is a paid position on a six-month part-time contract with a
budgeted rate of $30-50 USD per hour through the Internews BASICS
project (Building Analytical and Support Infrastructure for Critical
Security tools):

https://phf.tbe.taleo.net/phf04/ats/careers/v2/viewRequisition?cws=38=INTERNEWS=1392 



This announcement is also available on the Qubes website:

https://www.qubes-os.org/news/2021/04/10/get-paid-to-support-qubes-development-through-automated-testing/ 



Correction: "Travis" should instead be "GitLab CI."

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c4f485bf-bc56-9b61-bdb0-c72f02f9de10%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] Get paid to support Qubes development through automated testing! (six-month contract)

[Andrew David Wong]

Dear Qubes Community,

The Qubes OS Project is seeking an expert in automated testing. We use
OpenQA and Travis to test changes to the Qubes OS source code and
automated building from source. We're looking for someone who can help
with improving both the automated tests themselves and the testing
infrastructure.

This is a paid position on a six-month part-time contract with a
budgeted rate of $30-50 USD per hour through the Internews BASICS
project (Building Analytical and Support Infrastructure for Critical
Security tools):

https://phf.tbe.taleo.net/phf04/ats/careers/v2/viewRequisition?cws=38=INTERNEWS=1392

This announcement is also available on the Qubes website:

https://www.qubes-os.org/news/2021/04/10/get-paid-to-support-qubes-development-through-automated-testing/

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e464cb55-4e6c-8959-bf54-d5a24805c8cb%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] https://www.qubes-os.org/news/2021/03/19/qsb-067/

[Andrew David Wong]

On 4/3/21 1:05 PM, Ulrich Windl wrote:

Hi!

Following https://www.qubes-os.org/news/2021/03/19/qsb-067/, the command
sudo qubesctl --skip-dom0 --templates --standalones state.sls 
update.qubes-vm


does not work here:
[master@dom0 ~]$ sudo qubesctl --skip-dom0 --templates --standalones 
state.sls update.qubes-vm

usage: qubesctl [-h] [--show-output] [--force-color] [--skip-dom0]
     [--max-concurrency MAX_CONCURRENCY]
     [--targets TARGETS | --templates | --standalones | 
--app | --all]

     ...
qubesctl: error: argument --standalones: not allowed with argument 
--templates


Am I confused? What's wrong?

Regards,
Ulrich



As the error message states, you can't use both --templates and 
--standalones at the same time. Try dropping one of the two options.


I've opened a bug report for this:

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

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f43be02d-1236-a225-665a-1c2198b99aa2%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] XSAs released on 2021-03-30

[Andrew David Wong]

Dear Qubes Community,

The Xen Project has released one or more new Xen Security Advisories (XSAs).
The security of Qubes OS *is not affected* by these XSAs.
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-371 (DoS only)


Related links
-

 - Qubes Security Pack (qubes-secpack): 
https://www.qubes-os.org/security/pack/
 - Qubes Security Bulletins (QSBs): 
https://www.qubes-os.org/security/bulletins/

 - XSA Tracker: https://www.qubes-os.org/security/xsa/


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

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/43687365-fcf2-347f-d06e-a1363ad07549%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Re: cannot verify signatures R4.0.4

[Andrew David Wong]

On 3/26/21 6:50 PM, Franz wrote:

On Fri, Mar 26, 2021 at 9:10 AM Franz <169...@gmail.com> wrote:


Hello,
everything seems to work fine:

gpg2 --check-signatures "Qubes OS Release 4 Signing Key"
pub   rsa4096 2017-03-06 [SC]
   5817A43B283DE5A9181A522E1848792F9E2795E9
uid   [  full  ] Qubes OS Release 4 Signing Key
sig!31848792F9E2795E9 2017-03-06  Qubes OS Release 4 Signing Key
sig! DDFA1A3E36879494 2017-03-08  Qubes Master Signing Key
gpg: 2 good signatures

gpg2 -k "Qubes OS Release"
pub   rsa4096 2014-11-19 [SC]
   C52261BE0A823221D94CA1D1CB11CA1D03FA5082
uid   [  full  ] Qubes OS Release 3 Signing Key
pub   rsa4096 2017-03-06 [SC]
   5817A43B283DE5A9181A522E1848792F9E2795E9
uid   [  full  ] Qubes OS Release 4 Signing Key

but when I try to verify get unexpected error, even after downloading two
times the files, and even after trying with Fedora and Debian:

gpg2 -v --verify qubes-release-4-signing-key.asc Qubes-R4.0.4-x86_64.iso
gpg: verify signatures failed: Unexpected error



I found the problem: I downloaded
Qubes release signing key
rather than
Detached PGP signature



Yes, we already have a Troubleshooting FAQ entry for this situation:

https://www.qubes-os.org/security/verifying-signatures/#why-am-i-getting-verify-signatures-failed-unexpected-data

(It looks like GPG may have slightly changed their wording from 
"unexpected data" to "Unexpected error," but it should still be close 
enough to point you in the right direction.)



Well frankly, IMO the name of the wrong file seems more appropriate than the 
right one.


No, a key is completely different from a detached signature file. It 
would be incorrect to call the signature file a key. It would actually 
be *more* confusing, since then there would be two different types of 
things called "keys."



How is  "Detached PGP signature" supposed to be easy to understand? :-)
Detached from what?


Detached from the thing being verified (in this case, the ISO) as 
opposed to being included (as in a clearsigned text file, such as our 
signed hash values). That's just what it's called in the PGP/GPG world:


https://www.gnupg.org/gph/en/manual/x135.html


Well, I am sure it is detached from something, but I lost hours for nothing and 
other users may simply avoid verifying the iso if it is too complicated.


That's why we provide such detailed step-by-step instructions and a 
troubleshooting FAQ at the bottom of the page:


https://www.qubes-os.org/security/verifying-signatures/


Once there was only one file that could be downloaded.


No, that was never the case with Qubes ISO verification. At minimum, 
you'd theoretically need two things: The PGP key and the clearsigned 
data (data + sig in a single file). However, in all of my years using 
and working on Qubes, I can't recall ever seeing a PGP signature 
included in an ISO as a single file (i.e., a "clearsigned ISO"). Not 
sure if it's even possible. Even if it were, it may not be desirable, 
since the ability to handle the ISO on its own is useful. (This is why 
we also include signed hash values as an alternative verification method.)



Well I understand the additional files may have some additional use


It's not like we're including extra files for the heck of it. All of the 
files we're providing to you are necessary for secure verification. None 
of them are optional in that process. Please carefully read this page again:


https://www.qubes-os.org/security/verifying-signatures/

> but there are a lot of people that are not interested in that and 
just need an easy and fast way to get it going.


For a user who primarily seeks security, it generally doesn't make sense 
to unsecurely install a high-security OS, since this can easily be a 
self-defeating exercise. Therefore, we our main focus is on 
high-security verification.


Nonetheless, we also understand that different users seek varying levels 
of security and that some are attracted to Qubes for primary reasons 
other than security (e.g., control and compartmentalization, perhaps 
with security as a bonus). We understand that such users may appreciate 
another verification method that trades a small amount of security in 
exchange for a great amount of convenience, and there has been some 
exploration on this front:


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


So perhaps it may be more appropriate to add to the detached file also the
wording "use this file to follow the Qubes verification tutorial"


Sure, if it's possible to include extra comment text that doesn't 
interfere with the signature, it wouldn't hurt to point to the guide. 
I'll ask the team about this.


--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this 

Re: [qubes-users] Re: QSB-067: Multiple RPM vulnerabilities

[Andrew David Wong]

On 3/19/21 4:35 PM, Marek Marczykowski-Górecki wrote:

On Fri, Mar 19, 2021 at 03:42:23PM -0700, Andrew David Wong wrote:

On 3/19/21 3:12 PM, Vít Šesták wrote:

It seems to have been fixed now. The dom0 updates have passed. The DomU
Fedora updates have succeeded with updating the macros.qubes file, which is
supposingly the workaround by Qubes team.

Regards,
Vít Šesták 'v6ak'




I now realize that we neglected to state, in the QSB, what the desired
result from updating Fedora-based TemplateVMs and StandaloneVMs should be. I
presume this is it:



   --
 ID: /usr/lib/rpm/macros.d/macros.qubes
   Function: file.managed
 Result: True
Comment: File /usr/lib/rpm/macros.d/macros.qubes updated
Started: 
   Duration: 
Changes:
 --
 diff:
 New file
   --
 ID: dnf-makecache
   Function: cmd.script
 Result: True
Comment: DNF cache successfully created
Started: 
   Duration: 
Changes:
   --



Marek or Demi, can you confirm?


Yes this seems right (in subsequent runs, the
/usr/lib/rpm/macros.d/macros.qubes state will not have "New file"
comment, but will still have "Result: True").
Below you should also see a summary with "Failed: 0".



Thanks, that is indeed the output I received.

However, on a few update attempts, I saw this:

  Function: cmd.script
Result: False
   Comment: Could not create DNF metadata cache
   Started: 
  Duration: 
   Changes:
  --
ID: update
  Function: pkg.uptodate
Result: False
   Comment: One or more requisite failed: update.qubes-vm.dnf-makecache
   Started: 
  Duration: 
   Changes:
  --

Subsequent attempts were successful (had the expected output), though.

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/39c31626-3eb9-60b3-5d99-27fda10c0d2f%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Re: QSB-067: Multiple RPM vulnerabilities

[Andrew David Wong]

it.
This way, bypassing the signature check in DNF is not enough to
compromise an entire TemplateVM. Note that this change also prevents the
installation of unsigned RPM packages, even when explicitly requested.
See the "Side effects" section below.

For the dom0 aspect of these issues in Qubes 4.0, we update RPM to a
version that is not vulnerable. We have decided to update to the next
major version of RPM (from 4.13 to 4.14). This is because, besides the
security fix itself (which could be backported), version 4.14 has
significantly improved integrity verification. In 4.14, the macro
_pkgverify_level can be used to require that all packages be signed by a
trusted key. It defaults to "digest", meaning that only checksums must
be present, but we have set it to "all", requiring that all packages be
signed. Additionally, the checks performed before importing a package
have been significantly enhanced, which substantially reduces the attack
surface prior to integrity verification.

In the near future, we will also deploy an extra tool to perform
preliminary validation of all RPM packages in dom0 before handing them
over to RPM.


Impact
===

The impact differs between Fedora templates and dom0:

1. For Fedora templates, an attacker who controls packages that the user
downloads can completely bypass package signature verification and
fully compromise Fedora templates.

2. For dom0, an attacker who controls packages that the user downloads
can corrupt the RPM database and (almost silently) prevent further
updates of select packages.

The attack requires control over the contents of downloaded packages.
This requirement differs slightly between Fedora templates and dom0:

1. For Fedora templates, the attacker would either have to
a. compromise the Fedora infrastructure that is serving updates or
b. perform a man-in-the-middle attack on the HTTPS connection used to
download the repository metadata (which contains package hashes).

2. For dom0, the attacker would either have to attack the user's
repository access (as in the Fedora template case) or compromise the
UpdateVM (sys-firewall in the default configuration).


Side effects
=

The mitigation forces signature verification in RPM regardless of other
options. This means that RPM will refuse to install packages that are
unsigned (or signed with an untrusted signature), even when explicitly
requested to do so. This breaks use cases such as installing
locally-built packages and installing manually-downloaded packages the
integrity of which was verified separately (which is often the case for
closed-source software).

In such cases, neither `dnf install /path/to/the/package.rpm` nor `rpm
-i /path/to/the/package.rpm` will work any longer. Instead, to install a
package without a trusted signature (that has been verified by other
means), use the following command:

rpm --define '_pkgverify_level digest' -i /path/to/the/package.rpm

If the package has any dependencies, the above command will list them,
and they will have to be installed with `dnf` manually.


Credits


These issues were discovered and reported by Demi M. Obenour.


References
===

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1934125
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1927747
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1927741
[4] https://www.qubes-os.org/doc/updating-qubes-os/

--
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/2021/03/19/qsb-067/








--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org







--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/150dd971-36b9-a0f4-940c-cc31107f77be%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Re: QSB-067: Multiple RPM vulnerabilities

[Andrew David Wong]

ed before importing a package
have been significantly enhanced, which substantially reduces the attack
surface prior to integrity verification.

In the near future, we will also deploy an extra tool to perform
preliminary validation of all RPM packages in dom0 before handing them
over to RPM.


Impact
===

The impact differs between Fedora templates and dom0:

1. For Fedora templates, an attacker who controls packages that the user
downloads can completely bypass package signature verification and
fully compromise Fedora templates.

2. For dom0, an attacker who controls packages that the user downloads
can corrupt the RPM database and (almost silently) prevent further
updates of select packages.

The attack requires control over the contents of downloaded packages.
This requirement differs slightly between Fedora templates and dom0:

1. For Fedora templates, the attacker would either have to
a. compromise the Fedora infrastructure that is serving updates or
b. perform a man-in-the-middle attack on the HTTPS connection used to
download the repository metadata (which contains package hashes).

2. For dom0, the attacker would either have to attack the user's
repository access (as in the Fedora template case) or compromise the
UpdateVM (sys-firewall in the default configuration).


Side effects
=

The mitigation forces signature verification in RPM regardless of other
options. This means that RPM will refuse to install packages that are
unsigned (or signed with an untrusted signature), even when explicitly
requested to do so. This breaks use cases such as installing
locally-built packages and installing manually-downloaded packages the
integrity of which was verified separately (which is often the case for
closed-source software).

In such cases, neither `dnf install /path/to/the/package.rpm` nor `rpm
-i /path/to/the/package.rpm` will work any longer. Instead, to install a
package without a trusted signature (that has been verified by other
means), use the following command:

rpm --define '_pkgverify_level digest' -i /path/to/the/package.rpm

If the package has any dependencies, the above command will list them,
and they will have to be installed with `dnf` manually.


Credits


These issues were discovered and reported by Demi M. Obenour.


References
===

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1934125
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1927747
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1927741
[4] https://www.qubes-os.org/doc/updating-qubes-os/

--
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/2021/03/19/qsb-067/








--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2edcc978-d815-9012-9c8f-a2e7bb696204%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] QSB-067: Multiple RPM vulnerabilities

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 067: Multiple RPM
vulnerabilities. The text of this QSB is reproduced below. This QSB and
its accompanying signatures will always be available in the Qubes
Security Pack (qubes-secpack).

View QSB-067 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-067-2021.txt

Learn about the qubes-secpack, including how to obtain, verify, and read it:

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/bulletins/

```


 ---===[ Qubes Security Bulletin 067 ]===---

 2021-03-19


 Multiple RPM vulnerabilities


User action required
=

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

  For Qubes 4.0:
  - rpm 4.14.2.1 (plus rebuilt packages to link with the new rpm)
  - qubes-core-dom0-linux 4.0.29
  - qubes-mgmt-salt-dom0-update 4.0.10

  For Qubes 4.1:
  - qubes-core-dom0-linux 4.1.10
  - qubes-mgmt-salt-dom0-update 4.1.6

The packages are to be installed in dom0 via the Qubes Update tool [4]
or via the qubes-dom0-update command as follows:

  For updates from the stable repository (not immediately available):
  $ sudo qubes-dom0-update

  For updates from the security-testing repository:
  $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing

After installing the updates in dom0, it is necessary to install updates
in Fedora-based TemplateVMs and StandaloneVMs. This can be
done via the Qubes Update tool [4] or using qubesctl (salt) as follows:

  $ sudo qubesctl --skip-dom0 --templates --standalones state.sls 
update.qubes-vm


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.


Summary


Demi M. Obenour has discovered several issues in the RPM package
manager:

- CVE-2021-20271[1] RPM: Signature checks bypass via corrupted RPM
  package
- CVE-2021-3421[2] RPM: unsigned signature header leads to string
  injection into an RPM database
- CVE-2021-20266[3] RPM: missing length checks in hdrblobInit()

These issues allow an attacker who controls packages the user downloads
to inject malicious content that, under some conditions, may not be
detected by signature verification. Specifically, they allow the
attacker to modify parts of the package header that are not protected by
the signature and that are later integrated into the RPM database. This
allows for corrupting the RPM database and preventing further updates of
select packages.  In the case of Fedora TemplateVMs, this also allows
for arbitrary code execution.

The CVE-2021-20271 exploit takes advantage of multiple headers in the
RPM package format. In a proper RPM package, the signature is placed in
a separate header (called the "signature header") and, if present, is
verified by librpm when loading the file (according to the requested
verification level). An RPM package also contains a "main header" that
includes all the other package metadata. The main header is protected by
a signature in the signature header. The payload is protected either by
a signature in the signature header or by a SHA-256 hash located in the
main header. The ability to distinguish between these two headers is
available to librpm internals but not to external librpm users.

A malformed package may contain a signature in the main header instead
of the signature header. Librpm will reject such a package only if a
strict signature check was requested. Otherwise, it will treat the
package as unsigned. DNF, on the other hand, has no way to check whether
the signature was in the correct header.  It will load the package and,
seeing a signature, will assume that it was verified by librpm. This
allows for bypassing package signature verification.

The other bugs (CVE-2021-20266, CVE-2021-3421) concern incorrect parsing
of the signature header (which, while it contains the signature, is
itself unsigned). These bugs lead either to crashing or to corrupting
the RPM database (if such a malformed package is installed).

While Fedora will release its own patches in due course, we apply a
mitigation that prevents the privilege escalation aspect of these
issues. We configure RPM to always verify package signatures, even if a
higher level package manager (like DNF) does not explicitly request it.
This way, bypassing the signature check in DNF is not enough to
compromise an entire TemplateVM. Note that this change also prevents the
installation of unsigned RPM packages, even when explicitly requested.
See the "Side effects" section below.

For the dom0 aspect of these issues in Qubes 4.0, we update RPM to a
version that is not vulnerable. We have decided to update to the next
major version of RPM (from 4.13 to 4.14). This is because, besides the
security fix itself (which could be 

[qubes-users] XSAs released on 2021-03-18

[Andrew David Wong]

Dear Qubes Community,

The Xen Project has released one or more new Xen Security Advisories (XSAs).
The security of Qubes OS **is not affected** by these XSAs.
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-368 (DoS only)


Related links
-

 - Qubes Security Pack (qubes-secpack): 
https://www.qubes-os.org/security/pack/
 - Qubes Security Bulletins (QSBs): 
https://www.qubes-os.org/security/bulletins/

 - XSA Tracker: https://www.qubes-os.org/security/xsa/


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

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ed27a690-3631-1ae6-3717-88b31cdafa66%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] Qubes Canary 026

[Andrew David Wong]

Dear Qubes Community,

*Note:* When preparing the announcement for this canary, we discovered
a typographical error in the title (the canary number "025" had not been
updated to "026"). However, one of the canary signers is not available
to re-sign an updated canary before the canary deadline. Rather than
invalidate this signer's signature by updating the canary text
immediately, we have decided to proceed with this announcement with the
existing canary text, accompanied with this note explaining the error.
As soon as all signers are available, the error will be fixed, and the
updated canary will be re-signed by all parties. Thank you for your
understanding.

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

https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-026-2020.txt

Learn about the qubes-secpack, including how to obtain, verify, and
read it:

https://www.qubes-os.org/security/pack/

View all past canaries:

https://www.qubes-os.org/security/canaries/

```


---===[ Qubes Canary 025 ]===---


Statements
---

The Qubes core developers who have digitally signed this file [1]
state the following:

1. The date of issue of this canary is March 7, 2021.

2. There have been 66 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
two weeks of June 2021. 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 news feeds quoted below (Proof of freshness) 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, 07 Mar 2021 14:11:21 +

Source: DER SPIEGEL - International 
(https://www.spiegel.de/international/index.rss)
Monitoring the Right Wing: German Officials Seek to Turn up the Heat on 
the AfD

John Bolton on Halkbank: “Trump Wanted To Make an Impression on Erdoğan”
RT Germany: Berlin Fears Growing Influence of Russian Propaganda Platform
Generation Lockdown: Schoolchildren Around the World Face a Steep Uphill 
Battle

Boom in Somaliland: A Miracle on the Horn of Africa

Source: NYT > World News 
(https://rss.nytimes.com/services/xml/rss/nyt/World.xml)

Colombia Seeks Justice for War Atrocities Via New Court
In Hong Kong, Foreign Tourists Are Replaced by a Local Variety
Pope Francis Meets Iraq’s Top Ayatollah as Both Urge Peace
Chloé Zhao, ‘Nomadland’ Director, Encounters a Backlash in China
In a Land Dominated by Ex-Rebels, Kosovo Women Find Power at the Ballot Box

Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Pope Francis visits regions of Iraq once held by Islamic State
Uighurs: Chinese foreign minister says genocide claims 'absurd'
Nazanin Zaghari-Ratcliffe released but faces new court date
Myanmar coup: Party official dies in custody after security raids
US pastor on leave after Melania Trump 'trophy wife' comments

Source: Blockchain.info
00021d96387dc5ac0d7b6b5567119ab8ae32de4351700136

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


This announcement is also available on the Qubes website:

[qubes-users] Qubes OS 4.0.4 has been released!

[Andrew David Wong]

Dear Qubes Community,

We're pleased to announce the release of Qubes OS 4.0.4! This is the
fourth stable release of Qubes 4.0. It includes many updates over the
initial 4.0 release, including:

- All 4.0 dom0 updates to date
- Fedora 32 TemplateVM
- Debian 10 TemplateVM
- Whonix 15 Gateway and Workstation TemplateVMs
- Linux kernel 5.4 by default

Qubes 4.0.4 is available on the downloads page:

https://www.qubes-os.org/downloads/


What is a point release?


A point release does not designate a separate, new version of Qubes OS.
Rather, it designates its respective major or minor release (in this
case, 4.0) inclusive of all updates up to a certain point. Installing
Qubes 4.0 and fully updating [1] it results in the same system as
installing Qubes 4.0.4.


What should I do?
-

If you installed Qubes 4.0, 4.0.1, 4.0.2, or 4.0.3 and have fully
updated [1], then your system is already equivalent to a Qubes
4.0.4 installation. No further action is required.

Regardless of your current OS, if you wish to install (or reinstall)
Qubes 4.0 for any reason, then the 4.0.4 ISO makes this more convenient
and secure, since it bundles all Qubes 4.0 updates to date. Please see
the installation guide [2] for detailed instructions.

Thank you to all the release candidate users for testing this release
and reporting issues [3]!


[1] https://www.qubes-os.org/doc/updating-qubes-os/
[2] https://www.qubes-os.org/doc/installation-guide/
[3] https://www.qubes-os.org/doc/reporting-bugs/

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/03/04/qubes-4-0-4/

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/235b6cc8-6904-d20f-132d-dd5bb8b651b1%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] XSAs released on 2021-03-04

[Andrew David Wong]

Dear Qubes Community,

The Xen Project released one or more new Xen Security Advisories (XSAs) 
on 2021-03-04.

The security of Qubes OS *is not affected* by these XSAs.
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-367 (not affected; Qubes uses PVH/HVM)
 - XSA-369 (DoS only)


Related links
-


 - Qubes Security Pack (qubes-secpack): 
https://www.qubes-os.org/security/pack/
 - Qubes Security Bulletins (QSBs): 
https://www.qubes-os.org/security/bulletins/

 - XSA Tracker: https://www.qubes-os.org/security/xsa/


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

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/55b3a113-89cb-6f8d-5d84-ffb8c157e03e%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] QSB-066: XML injection through libvirt domain configuration

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 066:
XML injection through libvirt domain configuration.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack 
(qubes-secpack).


View QSB-066 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-066-2021.txt

Learn about the qubes-secpack, including how to obtain, verify, and read it:

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/bulletins/

```


 ---===[ Qubes Security Bulletin 066 ]===---

 2021-03-03


 XML injection through libvirt domain configuration


User action required
=

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

  For Qubes 4.0:
  - qubes-core-dom0 package, version 4.0.58-1

  For Qubes 4.1:
  - qubes-core-dom0 package, version 4.1.20-1

The packages are to be installed in dom0 via the Qube Manager or via
the qubes-dom0-update command as follows:

  For updates from the stable repository (not immediately available):
  $ sudo qubes-dom0-update

  For updates from the security-testing repository:
  $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing

A system restart will be required afterwards.  Alternatively, it is
possible to restart qubesd with the following command in dom0:

  $ systemctl restart qubesd.service

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.


Summary


The libvirt domain configuration is an XML file built by filling a
template with values specific to a particular domain -- mostly its
properties but, in a few cases, "features" (extra properties that can be
freely defined). While most of the properties have strictly-defined
formats, some allow for a very broad range of values -- broad enough to
allow characters that are otherwise special in XML. Using such
characters in XML values requires escaping them, which was not enabled
in the template engine we use (jinja2). The specific VM metadata
properties that allow free text and are used in libvirt XML are as
follows:

 - `kernelopts` property
 - `timezone` feature (although it is validated in the template itself)
 - `video-model` feature
 - `audio-model` feature (Qubes R4.1 only)

Normally, this wouldn't be an issue, since all VM settings come from a
trusted entity (dom0). However, with the introduction of the Admin API
[1] in Qubes 4.0, it is possible to allow less trusted domains (known as
"ManagementVMs") to manage a subset of VMs or their settings, including
the affected properties and features. This, in turn, can be used to
modify unintended parts of the libvirt XML. In the worst case, this
could lead to code execution in dom0.

To fix the issue, we're enabling the autoescape feature of the jinja2
template engine. This will cover the current problematic properties as
well as any others that might be introduced in the future. Additionally,
we're adding an extra validation step for "features" that are otherwise
used in a free text form context (specifically, `net.fake-*` features
are expected to be IP addresses, but they lacked such validation).

Note that a ManagementVM can still break a VM it has control over, for
example, by setting some property to an improper value in a given
context (e.g., too little memory or too short of a startup timeout).
However, after these changes, it should no longer be able to escalate
its permissions beyond what it has been assigned.


Impact
===

Default Qubes 4.0 and 4.1 configurations are not affected.

If a less trusted domain (known as a "ManagementVM") is given Admin API
access to set any of the affected properties or features on any domain
(via the `admin.vm.property.Set` or `admin.vm.feature.Set` qrexec
services), it may use this access to elevate its privileges and
potentially take full control of the system.

Note that `qubes.FeaturesRequest` is enabled by default but *is not*
vulnerable for three reasons.  First, feature names are read from
qubesd, which enforces a whitelist of permitted characters in paths.
None of the permitted characters are metacharacters in XML.  Second,
none of the features for which dom0 will honor a request have their
values incorporated into libvirt XML.  Third, `qubes.FeaturesRequest`
can only unset a feature or set its value to `1`.

Credits


This issue was discovered by Demi Marie Obenour.


References
===

[1] https://www.qubes-os.org/doc/admin-api/

--
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/2021/03/03/qsb-066/


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To 

[qubes-users] "Improvements in testing and building: GitLab CI and reproducible builds" by Marek Marczykowski-Górecki

[Andrew David Wong]

Dear Qubes Community,

We have just published a new article:

"Improvements in testing and building: GitLab CI and reproducible builds"
by Marek Marczykowski-Górecki

https://www.qubes-os.org/news/2021/02/28/improvements-in-testing-and-building/

For those using plain text email, the original Markdown source is 
reproduced below:


---
layout: post
title: "Improvements in testing and building: GitLab CI and reproducible 
builds"

categories: articles
author: Marek Marczykowski-Górecki
---

Over the last couple of months, we have made some significant changes to 
two important parts of the Qubes development process: testing and building.



What are continuous integration (CI) and reproducible builds?
--

Automated testing is a major part of the software development process. 
It spares developers many, many hours of manual testing that would still 
miss some bugs and other problems. In Qubes development, we're using an 
approach called "continuous integration" (CI), in which local changes 
made by the developers are frequently merged and tested remotely, using 
dedicated automated testing solutions. This is very important both for 
maintaining consistent code quality (all changes are tested) and for 
making development easier for the developers. Testing Qubes is not easy. 
Since Qubes is an entire operating system, doing the testing on the same 
system in which you're developing is a bit like building a rocket 
landing system en route to Mars --- not impossible, but very stressful.


The second area of improvement is the build process. The term 
"[reproducible builds]" refers to a process in which the same source 
code always compiles into exactly the same binary (for example, a 
package used to install a program via a package manager like `dnf` or 
`apt`). Why is this difficult to achieve? After all, computers are not 
random. Shouldn't builds be reproducible by default, without requiring 
special effort to make them deterministic? Unfortunately, it's not that 
simple. There are thousands of variables influencing the way binaries 
are built, ranging from the time of day to the availability of remote 
servers and locale settings.


Ensuring that binaries are built the same way every time is surprisingly 
difficult. However, the effort is worth the security benefits. To 
understand these benefits, imagine that an attacker wishes to feed 
unsuspecting users a compromised package. The attacker knows that the 
source code is public, so any malicious code he inserts into it would be 
highly exposed and at risk of detection. On the other hand, he reasons, 
compromising the build infrastructure would allow him to surreptitiously 
insert malicious changes that would make it into the resultant package. 
Since the source code remains untouched, his malicious changes are less 
likely to be detected. This is where the value of reproducible builds 
comes in. If the build process is reproducible, then we will immediately 
notice that building a package from the untouched source code results in 
a package that is *different* from the compromised one. This would be a 
major red flag that would prompt an immediate security investigation.



GitLab-CI migration


As many of you are aware, we migrated from Travis-CI to GitLab-CI late 
last year. While the [direct reason][ci-thread] was a change in the 
Travis-CI terms of service, GitLab-CI gives us many additional benefits. 
Just to name a few:


 - A modern execution environment with native Docker support: We can 
use whatever base environment we like. We are no longer constrained to 
specific (not so fresh) Ubuntu versions.
 - Much more flexible job definitions, including dependencies among 
them: We use this to split jobs into smaller pieces that can run in 
parallel and reduce duplication among them.
 - Out-of-the-box support for caching and artifacts: Another feature 
allowing for a great speed-up of our tests. A specific build environment 
can be stored with a pre-populated cache, for example avoiding the need 
to create a chroot environment each time.
 - Higher time limits and the ability to connect our own workers: This 
allows us to automatically test bigger components like the Linux kernel 
(which previously didn't fit into Travis-CI's hard time limit).


The actual migration was a massive undertaking, with the [GitLab-CI 
configuration] spread across 50 files with over 1,000 lines in total. We 
have opened and merged over 90 pull requests in the process. This was 
mainly done by [Frédéric Pierret].


We still host the actual code on GitHub. We use GitLab only for CI. This 
mode of operation is supported natively by GitLab, but this support is 
quite limited. Most importantly, it [does not support] testing pull 
requests made from repository forks, which is the vast majority of our 
pull requests (if not all of them). For this reason, Frédéric ended up 
creating [our own integration],