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

[Andrew David Wong]

Dear Qubes Community,

The [Xen Project](https://xenproject.org/) has released one or more [Xen 
security advisories (XSAs)](https://xenbits.xen.org/xsa/).
The security of Qubes OS *is affected*.
Therefore, *user action is required*.

## XSAs that DO affect the security of Qubes OS

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

- [XSA-432](https://xenbits.xen.org/xsa/advisory-432.html): See 
[QSB-092](https://www.qubes-os.org/news/2023/08/08/qsb-092/) for details.
- [XSA-434](https://xenbits.xen.org/xsa/advisory-434.html): See 
[QSB-093](https://www.qubes-os.org/news/2023/08/09/qsb-093/) for details.
- [XSA-435](https://xenbits.xen.org/xsa/advisory-435.html): See 
[QSB-093](https://www.qubes-os.org/news/2023/08/09/qsb-093/) for details.

## XSAs that DO NOT affect the security of Qubes OS

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

- (none)

## About this announcement

Qubes OS uses the [Xen 
hypervisor](https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as 
part of its [architecture](https://www.qubes-os.org/doc/architecture/). When 
the [Xen Project](https://xenproject.org/) publicly discloses a vulnerability 
in the Xen hypervisor, they issue a notice called a [Xen security advisory 
(XSA)](https://xenproject.org/developers/security-policy/). Vulnerabilities in 
the Xen hypervisor sometimes have security implications for Qubes OS. When they 
do, we issue a notice called a [Qubes security bulletin 
(QSB)](https://www.qubes-os.org/security/qsb/). (QSBs are also issued for 
non-Xen vulnerabilities.) However, QSBs can provide only *positive* 
confirmation that certain XSAs *do* affect the security of Qubes OS. QSBs 
cannot provide *negative* confirmation that other XSAs do *not* affect the 
security of Qubes OS. Therefore, we also maintain an [XSA 
tracker](https://www.qubes-os.org/security/xsa/), which is a comprehensive list 
of all XSAs publicly disclosed to date, including whether each one affects the 
security of Qubes OS. When new XSAs are published, we add them to the XSA 
tracker and publish a notice like this one in order to inform Qubes users that 
a new batch of XSAs has been released and whether each one affects the security 
of Qubes OS.


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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-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/1977072f-92f4-40da-811e-953472551c73%40qubes-os.org.

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

[Andrew David Wong]

Dear Qubes Community,

We have published [Qubes Security Bulletin 093: Transient execution 
vulnerabilities in AMD and Intel 
CPUs](https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-093-2023.txt).
 The text of this QSB and its accompanying cryptographic signatures are 
reproduced below. For an explanation of this announcement and instructions for 
authenticating this QSB, please see the end of this announcement.

## Qubes Security Bulletin 093

```

 ---===[ Qubes Security Bulletin 093 ]===---

  2023-08-09

  Transient execution vulnerabilities in AMD and Intel CPUs
   (CVE-2023-20569/XSA-434, CVE-2022-40982/XSA-435)

User action required
-

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

  For Qubes 4.1, in dom0:
  - Xen packages, version 4.14.6-1
  - microcode_ctl, version 2.1-55

  For Qubes 4.2, in dom0:
  - Xen packages, version 4.17.2-1
  - microcode_ctl, version 2.1-55

Note on AMD Zen 1 and Zen 2 CPUs: The packages we previously released
for QSB-086 [1] already contain mitigations that are sufficient to
protect these CPUs from CVE-2023-20569/XSA-434. Consequently,
fully-updated [2] Qubes OS installations running on systems with these
CPUs are not affected by the vulnerabilities discussed in this bulletin.

Note on AMD Zen 3 and Zen 4 CPUs: AMD has stated that they plan to
distribute microcode updates for these CPUs to original equipment
manufacturers (OEMs), original design manufacturers (ODMs), and
motherboard manufacturers (MB). [3] These microcode updates are shipped
only as part of system firmware; loading them from the operating system
is not supported. Therefore, until the relevant OEM, ODM, or MB provides
a suitable BIOS or (U)EFI update for a system, the package updates
listed above will not be sufficient to address CVE-2023-20569/XSA-434 on
that system.

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

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

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

Summary


The Xen Project published the following security advisories on
2023-08-08:

XSA-434 [5] "x86/AMD: Speculative Return Stack Overflow"
(CVE-2023-20569):

| Researchers from ETH Zurich have extended their prior research
| (XSA-422, Branch Type Confusion, a.k.a Retbleed) and have discovered
| INCEPTION, also know as RAS (Return Address Stack) Poisoning, and
| Speculative Return Stack Overflow.
|
| The RAS is updated when a CALL instruction is predicted, rather than
| at a later point in the pipeline.  However, the RAS is still
| fundamentally a circular stack.
|
| It is possible to poison the branch type and target predictions such
| that, at a point of the attackers choosing, the branch predictor
| predicts enough CALLs back-to-back to wrap around the entire RAS and
| overwrite a correct return prediction with one of the attackers
| choosing.
|
| This allows the attacker to control RET speculation in a victim
| context, and leak arbitrary data as a result.
|
| For more details, see:
|   https://comsec.ethz.ch/inception
|   https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-7005

XSA-435 [6] "x86/Intel: Gather Data Sampling" (CVE-2022-40982):

| A researcher has discovered Gather Data Sampling, a transient
| execution side-channel whereby the AVX GATHER instructions can forward
| the content of stale vector registers to dependent instructions.
|
| The physical register file is a structure competitively shared between
| sibling threads.  Therefore an attacker can infer data from the
| sibling thread, or from a more privileged context.
|
| For more details, see:
|   
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/gather-data-sampling.html

Impact
---

An attacker who compromises one qube can attempt to exploit one of these
vulnerabilities (the one corresponding to the system's CPU) in order to
infer the contents of data belonging to other qubes. In systems with AMD
CPUs, successfully exploiting CVE-2023-20569/XSA-434 would allow an
attacker to infer the contents of arbitrary host memory. In systems with
Intel CPUs, successfully exploiting CVE-2022-40982/XSA-435 would allow
an attacker to infer data from different CPU contexts on the same core.

Credits


See the original Xen Security Advisories.

References
---

[1] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-086-2022.txt
[2] https://www.qubes-os.org/doc/how-to-update/
[3] 

[qubes-users] Kernel 5.15.XXX

[Michael Singer]

Hi,

since a dom0-update at the beginning of July 2023 I get a black screen after 
the bootloader. I can only boot Qubes if I select Xen 4.14.5 with Linux kernel 
5.15.103 in the bootloader instead of the default (Xen 4.14.5 with Linux kernel 
6.1.35). See here: https://github.com/QubesOS/qubes-issues/issues/8354

Questions:

1) Will the kernel 5.15.103 be automatically deleted during the next 
dom0-update or do I not need to worry?
2) Is it possible to set the kernel 5.15.103 as default?

Kind regards,
Michael Singer

--
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/9eda3f72-5b78-4be9-81c2-8e910b764fc2%40posteo.de.

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

[Andrew David Wong]

## Summary

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

## How milestones work right now

Currently, our milestone guidelines are as follows:

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

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

## Problems with the current system

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

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

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

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

## Analyzing the nature of milestones

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

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

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

## How we plan to use milestones going forward

Issues will no longer immediately be assigned to milestones. 

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

[Andrew David Wong]

Dear Qubes Community,

We have published [Qubes Security Bulletin 092: Buffer overrun in Linux netback 
driver 
(XSA-432)](https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-092-2023.txt).
 The text of this QSB and its accompanying cryptographic signatures are 
reproduced below. For an explanation of this announcement and instructions for 
authenticating this QSB, please see the end of this announcement.

## Qubes Security Bulletin 092

```

 ---===[ Qubes Security Bulletin 092 ]===---

 2023-08-08

   Buffer overrun in Linux netback driver (XSA-432)

User action required
-

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

  For Qubes 4.1, in dom0:
  - Linux kernel packages (kernel*-qubes-vm), versions 6.1.43, 6.4.8,
5.15.124

  For Qubes 4.2, in dom0:
  - Linux kernel packages (kernel*-qubes-vm), versions 6.1.43, 6.4.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]

Service qubes that provide network access (such as sys-net,
sys-firewall, sys-whonix, and VPN qubes) must be restarted afterward in
order for the updates to take effect.

By default, all qubes use a kernel provided by dom0. However, advanced
users may opt to modify a given qube so that it uses an in-qube kernel
instead. [3] In such cases, the fixes contained in the kernel packages
listed above will not apply. Instead, any fix would have to come from
the upstream organization responsible for the distribution running in
that qube. If and when the relevant upstream organization makes such a
fix available, a normal update [2] should be sufficient to apply it. The
Qubes security team has no control over this process, as it concerns the
operations of independent organizations. Those who use in-qube kernels
may wish to consider temporarily switching to a dom0-provided kernel.

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
Linux binaries.

Summary


On 2023-08-08, the Xen Project published XSA-432, "Linux: buffer
overrun in netback due to unusual packet" [4]:

| The fix for XSA-423 added logic to Linux'es netback driver to deal
| with a frontend splitting a packet in a way such that not all of the
| headers would come in one piece.  Unfortunately the logic introduced
| there didn't account for the extreme case of the entire packet being
| split into as many pieces as permitted by the protocol, yet still
| being smaller than the area that's specially dealt with to keep all
| (possible) headers together.  Such an unusual packet would therefore
| trigger a buffer overrun in the driver.
|
| An unprivileged guest can cause Denial of Service (DoS) of the host by
| sending network packets to the backend, causing the backend to crash.
|
| Data corruption or privilege escalation seem unlikely but have not
| been ruled out.

Impact
---

An attacker who manages to compromise a network-connected qube could
attempt to exploit the vulnerability described in this bulletin in order
to attack the service qube (such as sys-net, sys-firewall, sys-whonix,
or a VPN qube) that provides network access to the compromised qube. The
Qubes security team believes that such an attack is unlikely to succeed
and that this vulnerability is not likely to be exploitable beyond
causing a crash. However, if such an attack were successful, it would
allow the attacker to execute arbitrary code in the service qube,
potentially bypassing the restrictions that such service qubes normally
impose. For example:

- An attacker in control of sys-firewall could bypass the firewall rules
  that sys-firewall normally enforces for the qubes connected to it.
- An attacker in control of sys-whonix could bypass Tor, emit clearnet
  traffic, and learn the machine's real public IP address.
- An attacker in control of a VPN qube could observe and modify the
  network traffic of other qubes that are connected to it -- traffic
  that the VPN would normally protect.
- An attacker in control of sys-net could gain direct access to attached
  PCIe devices.

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://www.qubes-os.org/doc/managing-vm-kernels/
[4] https://xenbits.xen.org/xsa/advisory-432.html

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

```

*Source*: 


## [Marek 
Marczykowski-Górecki](https://www.qubes-os.org/team/#marek-marczykowski-górecki)'s
 PGP signature

```
-BEGIN PGP SIGNATURE-

[qubes-users] HCL: Lenovo T470: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz

[RSS]

I have been using Qubes 4.2 alpha RC on this machine as my main drive
for about a month now, and so far hardware support during and after
installation has been flawless. Everything tried works.

-- 
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/20230808155715.160f3dd9%40armor-mail.com.


Qubes-HCL-LENOVO-20HES4CH00-20230808-154404.yml
Description: application/yaml
---
layout:
  'hcl'
type:
  'Notebook'
hvm:
  'yes'
iommu:
  'yes'
slat:
  ''
tpm:
  'unknown'
remap:
  'yes'
brand: |
  LENOVO
model: |
  20HES4CH00
bios: |
  N1QET98W (1.73 )
cpu: |
  Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz
cpu-short: |
  FIXME
chipset: |
  Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM 
Registers [8086:5904] (rev 02)
chipset-short: |
  FIXME
gpu: |
  Intel Corporation HD Graphics 620 [8086:5916] (rev 02) (prog-if 00 [VGA 
controller])
gpu-short: |
  FIXME
network: |
  Intel Corporation Ethernet Connection (4) I219-LM [8086:15d7] (rev 21)
  Intel Corporation Wireless 7265 [8086:095b] (rev 61)
memory: |
  32411
scsi: |
  SSD 512GBRev: 227F
usb: |
  1
certified:
  'no'
versions:
  - works:
  'FIXME:yes|no|partial'
qubes: |
  4.2.0-alpha
xen: |
  4.17.1
kernel: |
  6.1.35-1
remark: |
  FIXME
credit: |
  FIXAUTHOR
link: |
  FIXLINK

Re: [qubes-users] HCL - Gigabyte B650E Aorus Master - AMD Ryzen 9 7950X

[Sven Semmler]

Thank you Edwin for your HCL report, which is online now:

https://www.qubes-os.org/hcl/#gigabyte_b650e-aorus-master_ryzen-9-7950x_integrated-graphics-amd-radeon-rx-navi-10_edwin-t%C3%B6r%C3%B6k_4-2-0-alpha

/Sven

--
https://keys.openpgp.org/vks/v1/by-fingerprint/DA5975C9ABC40C833B2F620B2A632C537D744BC7

--
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/470aefb0-70b8-c58c-fb2c-d4fb9bb16e0c%40SvenSemmler.org.

[qubes-users] HCL - Gigabyte B650E Aorus Master - AMD Ryzen 9 7950X

['Edwin Török' via qubes-users]

Architecture:    x86_64
  CPU op-mode(s):    32-bit, 64-bit
  Address sizes: 48 bits physical, 48 bits virtual
  Byte Order:    Little Endian
CPU(s):  32
  On-line CPU(s) list:   0-31
Vendor ID:   AuthenticAMD
  Model name:    AMD Ryzen 9 7950X 16-Core Processor
    CPU family:  25
    Model:   97
    Thread(s) per core:  2
    Core(s) per socket:  16
    Socket(s):   1
    Stepping:    2
    Frequency boost: enabled
    CPU(s) scaling MHz:  52%
    CPU max MHz: 5879.8818
    CPU min MHz: 3000.
    BogoMIPS:    8999.60
    Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep
mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx
mmxext f
 xsr_opt pdpe1gb rdtscp lm constant_tsc
rep_good amd_lbr_v2 nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl
pni pclmul
 qdq monitor ssse3 fma cx16 sse4_1 sse4_2
x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm
extapic cr
 8_legacy abm sse4a misalignsse 3dnowprefetch
osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext
perfctr_llc m
 waitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba
perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase bmi1 avx2
smep bmi2
  erms invpcid cqm rdt_a avx512f avx512dq
rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw
avx512vl xs
 aveopt xsavec xgetbv1 xsaves cqm_llc
cqm_occup_llc cqm_mbm_total cqm_mbm_local avx512_bf16 clzero irperf
xsaveerptr rdpr
 u wbnoinvd cppc arat npt lbrv svm_lock
nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter
pfthreshold 
 avic v_vmsave_vmload vgif x2avic v_spec_ctrl
vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq
avx512_vnn
 i avx512_bitalg avx512_vpopcntdq rdpid
overflow_recov succor smca fsrm flush_l1d
Virtualization features: 
  Virtualization:    AMD-V
Caches (sum of all): 
  L1d:   512 KiB (16 instances)
  L1i:   512 KiB (16 instances)
  L2:    16 MiB (16 instances)
  L3:    64 MiB (2 instances)
NUMA:    
  NUMA node(s):  1
  NUMA node0 CPU(s): 0-31
Vulnerabilities: 
  Itlb multihit: Not affected
  L1tf:  Not affected
  Mds:   Not affected
  Meltdown:  Not affected
  Mmio stale data:   Not affected
  Retbleed:  Not affected
  Spec store bypass: Mitigation; Speculative Store Bypass disabled
via prctl
  Spectre v1:    Mitigation; usercopy/swapgs barriers and
__user pointer sanitization
  Spectre v2:    Mitigation; Enhanced / Automatic IBRS, IBPB
conditional, RSB filling, PBRSB-eIBRS Not affected
  Srbds: Not affected
  Tsx async abort:   Not affected
edwin ~ [4.14.1] ❯ cat /mnt/home/edwin/Qubes-HCL-
Gigabyte_Technology_Co___Ltd_-B650E_AORUS_MASTER-20230807-162029.yml 
---
layout:
  'hcl'
type:
  'Desktop'
hvm:
  'yes'
iommu:
  'yes'
slat:
  'yes'
tpm:
  '2.0'
remap:
  'yes'
brand: |
  Gigabyte Technology Co., Ltd.
model: |
  B650E AORUS MASTER
bios: |
  F3c
cpu: |
  AMD Ryzen 9 7950X 16-Core Processor
cpu-short: |
  FIXME
chipset: |
  Advanced Micro Devices, Inc. [AMD] Device [1022:14d8]
chipset-short: |
  FIXME
gpu: |
  Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600
OEM/5600 XT / 5700/5700 XT] [1002:731f] (rev c0) (prog-if 00 [VGA
controller])
  Advanced Micro Devices, Inc. [AMD/ATI] Raphael [1002:164e] (rev c1)
(prog-if 00 [VGA controller])
gpu-short: |
  FIXME
network: |
  Intel Corporation Ethernet Controller I225-V [8086:15f3] (rev 01)
  MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter
[14c3:0616]
  0616]
memory: |
  64663
scsi: |
  SanDisk SDSSDXPS Rev: 00RL
  TOSHIBA MG09ACA1 Rev: 0104
  TOSHIBA HDWD130  Rev: ACF0
usb: |
  4
certified:
  'no'
versions:
  - works:
  'partial'
    qubes: |
  4.2.0-alpha
    xen: |
  4.17.1
    kernel: |
  6.1.35-1
    remark: |
  Must create a GPT partition table on the boot media with 'gdisk',
see https://github.com/QubesOS/qubes-issues/issues/8395
  Must ensure that installation target is NOT 4Kn, had to reformat
NVME namespace to 512 byte, see
https://github.com/QubesOS/qubes-issues/issues/7398#issuecomment-1668545707
  Must enable IOMMU in BIOS (default is Auto which doesn't work.
Enable it under 'Misc settings and AMD CBS -> NBIO settings').
  Must NOT use a USB qube. Using a USB qube results in an instant
host reboot as soon as the USB qube is booted (same issue happen on KVM
when attempting to pass through any USB controller, even if the
controller is in an IOMMU group of its own). There is a newer BIOS with
newer AGESA available, I'll have to 

Re: [qubes-users] Installation problem on Dell Inspiron R15 laptop

[Tobias Killer]

Am 04.08.23 um 08:36 schrieb Omri:

Regarding the installation media - I installed it according the
installation instructions described on the website (with Rufus) and I use
windows 11 to make the installation media.


Okay.


According to what I understand, the bash command in the link compares the
size of both the media and the file downloaded. I compared with the the
"properties" window of the "File Explorer" and the media has almost 1 MB
more than the ISO file I downloaded. Is it right?


It is probably right that the "properties" window of the "File Explorer" 
shows a size (partition size?) that is a little bit bigger than the ISO 
file. At least, it makes sense.


However, the bash command does not compare the sizes. It compares the 
relevant *content* on your installation medium with that of the ISO 
file. If they are different, a message like


```
Binary files - and Qubes-R4.1.0-x86_64.iso differ
```

will show up when the command terminates, else not.

You may wonder why the content could be different. I don't know the 
answer but my experience is that sometimes there are faulty spots on a 
USB flash drive. This could lead to everything: Hanging installation, 
graphical glitches or even an unbootable device (in this case, the 
device is the mentioned USB flash drive).


Do you have an installed Linux anywhere (or a live Linux)? You could use 
that in order to execute the appropriate command. Else: Does anybody 
know how to compare the installation medium and the ISO file under 
Windows 11?


You could also just rewrite your installation medium with Rufus again 
and try installation again.


Best regards,
Tobias Killer

--
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/da46484a-7a2f-5f7d-3220-b49d502d6631%40posteo.de.

Re: [qubes-users] Installation problem on Dell Inspiron R15 laptop

[Omri]

Hi,
Thanks for your kind help.

Regarding the installation media - I installed it according the 
installation instructions described on the website (with Rufus) and I use 
windows 11 to make the installation media.
According to what I understand, the bash command in the link compares the 
size of both the media and the file downloaded. I compared with the the 
"properties" window of the "File Explorer" and the media has almost 1 MB 
more than the ISO file I downloaded. Is it right?

Regarding the low RAM - I know it's not ideal but it's for educational 
purposes about the OS itself, nothing too demanding, so I don't expect it 
to run smoothly and I won't be using many softwares.
With this little RAM, should I be able to install it and use it at all, or 
will it probably not going to work?
Also, assuming I'll manage to install it, how bad will it behave? Should I 
give up on trying to install Qubes OS on this hardware at all?

Thanks in advance,
Omri

-- 
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/97df843e-758f-48f9-b5df-bdbc5081e0f4n%40googlegroups.com.

Re: [qubes-users] Installation problem on Dell Inspiron R15 laptop

[Tobias Killer]

Am 01.08.23 um 16:29 schrieb Omri:

Hello group,

  


I'm trying for the last few days to install Qubes OS (no matter what
version) on my old laptop.

The laptop is:


- Dell Inspiron R15 (bought around 2013)
- CPU – Intel Core i7 - 3517U
   - VT-d ; VT-x ; EPT - included, according to Intel's website (
   
https://www.intel.com/content/www/us/en/products/sku/65714/intel-core-i73517u-processor-4m-cache-up-to-3-00-ghz/specifications.html
   (
   - On the BIOS though, there's no activation for any of these features
   specifically, but it has virtualization enable/unable in general.
- RAM – 8 GB
- Storage – 1 TB

  


It currently runs Windows 10 with no apparent problems other than slow
speed.

When I tried to install Qubes, at first it looked ok but quickly becomes
gibberish.

[image: 3. first few lines (sorry the camera lost focus).png] img 1 - first
few lines. the camera lost focus (sorry) but everything (4 lines) is
properly readable and makes sense.

[image: 4. text in dotted unreadable characters.png] img 2 - text appears
in dotted characters of no language and doesn't make sense (it's not even
Braille). Also, text cursor (underscore) appears oddly twice.

[image: 5. more of this text. it is now accepts input.png] img 3 - more of
this text... At the end it allows keyboard input but I can't know what
input to enter. If pressing "Enter" key, it reshows the last line.

* Between each image there's an empty black screen for about half a second.

** Couldn't attache images\videos


It than accepts input, but I can't know what input to enter.

I tried numerous versions, almost all of them; some did better, some less.
Version 4.0 looked better than all the others and this is what is shown in
the video.

Other versions asked me first if I want to "test and install", "install"
and so on, the normal menu.


I tried to look in the documentation and in forums. In addition, I've asked
in some forums – none of them helped.

I'm new to Qubes so it's possible my answer is out there but I didn't
notice.

  


Any tip, lead or advice would be much appreciated.

  


Thanks in advance,

Omri



Hello,

Is your installation medium fine? Maybe, you should check if there is no 
difference between the image on the installation medium and the original 
ISO image file. Do you use Linux? If yes, see


https://github.com/QubesOS/qubes-issues/issues/7030#issuecomment-1042944011

(Do not forget to replace `/dev/sda` with the actual installation medium 
and use the correct size and ISO image.)


If you need more help on this, don't hesitate to ask!

Best regards,
Tobias Killer

--
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/854c0d4e-52e2-2f8e-281c-3b49eb047d33%40posteo.de.

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

[Andrew David Wong]

Dear Qubes Community,

We have updated [Qubes Security Bulletin 090: Zenbleed (CVE-2023-20593, 
XSA-433)](https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-090-2023.txt).
 The text of this updated QSB (including a changelog) and its accompanying 
cryptographic signatures are reproduced below. For an explanation of this 
announcement and instructions for authenticating this QSB, please see the end 
of this announcement.

## Qubes Security Bulletin 090

```

 ---===[ Qubes Security Bulletin 090 ]===---

  2023-07-24

 Zenbleed (CVE-2023-20593, XSA-433)

Changelog
--

2023-07-24: Original QSB published
2023-08-01: Updated Xen packages with upstream bug fix (XSA-433 v3 [3])

User action required
-

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

  For Qubes 4.1, in dom0:
  - linux-firmware 20230625-146
  - Xen packages 4.14.5-22

  For Qubes 4.2, in dom0:
  - linux-firmware 20230625-147
  - Xen packages 4.17.1-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 and initramfs binaries.

Summary


On 2023-07-24, the Xen Project published XSA-433, "x86/AMD: Zenbleed"
[3]:
| Researchers at Google have discovered Zenbleed, a hardware bug causing
| corruption of the vector registers.
|
| When a VZEROUPPER instruction is discarded as part of a bad transient
| execution path, its effect on internal tracking are not unwound
| correctly.  This manifests as the wrong micro-architectural state
| becoming architectural, and corrupting the vector registers.
|
| Note: While this malfunction is related to speculative execution, this
|   is not a speculative sidechannel vulnerability.
|
| The corruption is not random.  It happens to be stale values from the
| physical vector register file, a structure competitively shared between
| sibling threads.  Therefore, an attacker can directly access data from
| the sibling thread, or from a more privileged context.
|
| For more details, see:
|   https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html
|
| 
https://github.com/google/security-research/security/advisories/GHSA-v6wh-rxpg-cmm8


Impact
---

As explained in XSA-433, this vulnerability is specific to the AMD Zen 2
microarchitecture, and AMD does not believe that other
microarchitectures are affected. Exploiting this vulnerability would
allow an attacker to read data from different contexts on the same core.
Examples of such data include key material, ciphertext and plaintext
from AES-NI operations, and the contents of REP-MOVS instructions, which
are commonly used to implement `memcpy()`.

In order to exploit this vulnerability, an attacker must be capable of
executing code at any privilege level in any qube, e.g., JavaScript in a
web browser. Moreover, the code to reliably exploit this vulnerability
is publicly available. Accordingly, there is a high risk of this
vulnerability being exploited in practice.

Credits


Tavis Ormandy of Google Project Zero.

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

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

```

*Source*: 


## [Marek 
Marczykowski-Górecki](https://www.qubes-os.org/team/#marek-marczykowski-górecki)'s
 PGP signature

```
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEELRdx/k12ftx2sIn61lWk8hgw4GoFAmTJuBUACgkQ1lWk8hgw
4Grm8g/8D4eC/PRmV2Kl5CSDZ4XPsM0UeV0UF6GhlSNXbMwkx2kzNkTJpi9ftJcz
cg/3y5z74aiVUFrHZmzya+PN+eza+Nh4AJdutuTwKs1TiUjiJ/hV0zt0mE+oUBa0
baQPbkFYciI7sv8q5TD5+P52ASgAd7IP0SAVp34sPPXZF1Mkw+Z4KcKR4Ua0pdzm
/WjrNWrDWPUWNT3SAZ9qaPdzMjtmHBYv1746XlPNh4kTkWCYI6ppX2AFSs72w7H4
DVylnA49mVOza2+ZRw518+wSJWoMFnl7QStVqqSPeQ5Ycf/ZZKIQmZq569tq0cAE
aYxA+eOTBG4u7sKBAWD7sMtmiJAmPm3g2NBjc27RdXawHlP1tgZeHXByfyRTAgBQ
MhKagCPQe8QUKxjX22G2fbhqf8V9Efkej7GbvJFRACZDtl7p+HJlC5MaYDl3X6zJ
iqMPjkLvdWz6dOGNy1djnF7rjaN8CsJHVbldSAsir6GWqBdjycRjzA4O3Z3ZuaRT
UdVuGa+Ec8M8x44snBv67AhTDT8FycFNjIw/3kak69+7Kc7o/mTUOPJ4jjvNqq/M
ku/a5m8RWPr9+Ysz2HOiqVvZqQ111M6nYCIxqJuEuyV5kqQMRwhl6vwbjjVZjTva
85KxOSQXPJgEz8jMTOPYBFZqLxOqf1mF4nuS0llMYkmlB3kgnSE=
=gT88
-END PGP SIGNATURE-
```

*Source*: 


## [Simon Gaiser (aka 
HW42)](https://www.qubes-os.org/team/#simon-gaiser-aka-hw42)'s PGP 

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

[Andrew David Wong]

Dear Qubes Community,

The [Xen Project](https://xenproject.org/) has released one or more [Xen 
security advisories (XSAs)](https://xenbits.xen.org/xsa/).
The security of Qubes OS *is not affected*.
Therefore, *no user action is required*.

## XSAs that DO affect the security of Qubes OS

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

- (none)

## XSAs that DO NOT affect the security of Qubes OS

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

- [XSA-436](https://xenbits.xen.org/xsa/advisory-436.html)
  - This affects only ARM processors, which Qubes OS does not support.

## About this announcement

Qubes OS uses the [Xen 
hypervisor](https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as 
part of its [architecture](https://www.qubes-os.org/doc/architecture/). When 
the [Xen Project](https://xenproject.org/) publicly discloses a vulnerability 
in the Xen hypervisor, they issue a notice called a [Xen security advisory 
(XSA)](https://xenproject.org/developers/security-policy/). Vulnerabilities in 
the Xen hypervisor sometimes have security implications for Qubes OS. When they 
do, we issue a notice called a [Qubes security bulletin 
(QSB)](https://www.qubes-os.org/security/qsb/). (QSBs are also issued for 
non-Xen vulnerabilities.) However, QSBs can provide only *positive* 
confirmation that certain XSAs *do* affect the security of Qubes OS. QSBs 
cannot provide *negative* confirmation that other XSAs do *not* affect the 
security of Qubes OS. Therefore, we also maintain an [XSA 
tracker](https://www.qubes-os.org/security/xsa/), which is a comprehensive list 
of all XSAs publicly disclosed to date, including whether each one affects the 
security of Qubes OS. When new XSAs are published, we add them to the XSA 
tracker and publish a notice like this one in order to inform Qubes users that 
a new batch of XSAs has been released and whether each one affects the security 
of Qubes OS.


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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-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/d78c1ed3-28ce-6134-1ad9-074cdc1f477d%40qubes-os.org.

[qubes-users] Installation problem on Dell Inspiron R15 laptop

[Ulrich Windl (Google)]

Hi!

Actually you won't have much fun with only 8 GB RAM; 16 is probably OK, and 32 
or more is nice. Remember that at least four operating systems have to run 
(Dom0, net, firewall, app).

Kind regards,
Ulrich

-- 
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/f3ffd60a-f3c7-41c0-a1a1-47fbe22ae596%40gmail.com.

Re: [qubes-users] Re: Configure WireGuard on Qubes

[RSS]

I used

https://privsec.dev/posts/qubes/using-mullvad-vpn-on-qubes-os/

to setup a dedicated VPN VM with the Mullvad GUI. Has some
idiosyncrasies, but works really not bad. Been using it for a couple
weeks already as a daily drive.

On Sun, 30 Jul 2023 01:30:52 -0700 (PDT)
klem klen  wrote:

> I should have added.  We are on a similar path.   I am looking to use
> the gui app for Mullvad instead.  The app provides access to all the
> Mullvad Servers/Nodes all around the world.  Has Bridges.  Makes it
> easy to delete connections, I am allowed five, but use multiple
> computers and end up starting more than five.   
> 
> Can not get it to install on sys-vpn, yet.  
> 
> There is a post about using Mullvad VPN gui app in a single App Qube,
> that is not persistent.  Which is a problem with other third party
> software., persistent, in my humble opinion, also means, it needs a
> ready to open Tab.  
> 
> 
> On Saturday, July 29, 2023 at 5:11:58 PM UTC-5 ale...@magenta.de
> wrote:
> 
> > I couldn't find a usable description of how to set up the most
> > secure WireGuard configuration on Qubes. I am aiming to create a
> > flexible network arrangement with chosen VMs going through
> > WireGuard only and others through Tor only.
> >
> > I have tried the information at 
> > https://github.com/tasket/Qubes-vpn-support but found it is out of
> > date and written before WireGuard was added to the kernel. I also
> > thought it was not written for a beginner to understand and adapt
> > to their needs.
> >
> > I have also tried the information at
> > https://github.com/Qubes-Community/ but again it is not written
> > well for a beginner.
> >
> > Implementing WireGuard for secure network access is necessary
> > before I can connect this installation to the Internet so I hope
> > someone can help me to set this up.
> >  
> 
> -- 
> 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/a90392bf-d63b-4e60-9ad1-7305bfc97493n%40googlegroups.com.

-- 
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/20230731170547.0989bf2b%40armor-mail.com.

[qubes-users] Re: Configure WireGuard on Qubes

[klem klen]

I should have added.  We are on a similar path.   I am looking to use the 
gui app for Mullvad instead.  The app provides access to all the Mullvad 
Servers/Nodes all around the world.  Has Bridges.  Makes it easy to delete 
connections, I am allowed five, but use multiple computers and end up 
starting more than five.   

Can not get it to install on sys-vpn, yet.  

There is a post about using Mullvad VPN gui app in a single App Qube, that 
is not persistent.  Which is a problem with other third party software., 
persistent, in my humble opinion, also means, it needs a ready to open 
Tab.  


On Saturday, July 29, 2023 at 5:11:58 PM UTC-5 ale...@magenta.de wrote:

> I couldn't find a usable description of how to set up the most secure 
> WireGuard configuration on Qubes. I am aiming to create a flexible 
> network arrangement with chosen VMs going through WireGuard only and 
> others through Tor only.
>
> I have tried the information at 
> https://github.com/tasket/Qubes-vpn-support but found it is out of date 
> and written before WireGuard was added to the kernel. I also thought it 
> was not written for a beginner to understand and adapt to their needs.
>
> I have also tried the information at https://github.com/Qubes-Community/ 
> but again it is not written well for a beginner.
>
> Implementing WireGuard for secure network access is necessary before I 
> can connect this installation to the Internet so I hope someone can help 
> me to set this up.
>

-- 
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/a90392bf-d63b-4e60-9ad1-7305bfc97493n%40googlegroups.com.

[qubes-users] Re: Configure WireGuard on Qubes

[klem klen]

https://forum.qubes-os.org/t/wireguard-vpn-setup/19141

On Saturday, July 29, 2023 at 5:11:58 PM UTC-5 ale...@magenta.de wrote:

> I couldn't find a usable description of how to set up the most secure 
> WireGuard configuration on Qubes. I am aiming to create a flexible 
> network arrangement with chosen VMs going through WireGuard only and 
> others through Tor only.
>
> I have tried the information at 
> https://github.com/tasket/Qubes-vpn-support but found it is out of date 
> and written before WireGuard was added to the kernel. I also thought it 
> was not written for a beginner to understand and adapt to their needs.
>
> I have also tried the information at https://github.com/Qubes-Community/ 
> but again it is not written well for a beginner.
>
> Implementing WireGuard for secure network access is necessary before I 
> can connect this installation to the Internet so I hope someone can help 
> me to set this up.
>

-- 
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/2ea4263e-4926-491d-b053-199bfd84c030n%40googlegroups.com.

Re: [qubes-users] Disabling Hibernation universally

[Andrew David Wong]

On 7/29/23 8:48 AM, ales...@magenta.de wrote:
> I am still in the process of configuring Qubes (4.1.1). I am trying now to 
> disable Hibernation at all level of the system.
> 
> I couldn't find any reference of Hibernation in the official documentation or 
> the Wiki. Could someone describe the way to disable it universally?
> 

Xen does not hibernation, so it is already "disabled" by default.

-- 
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/1601b435-abc4-5d3e-c08a-c265259336f9%40qubes-os.org.

[qubes-users] Configure WireGuard on Qubes

[alesser]

I couldn't find a usable description of how to set up the most secure 
WireGuard configuration on Qubes. I am aiming to create a flexible 
network arrangement with chosen VMs going through WireGuard only and 
others through Tor only.


I have tried the information at 
https://github.com/tasket/Qubes-vpn-support but found it is out of date 
and written before WireGuard was added to the kernel. I also thought it 
was not written for a beginner to understand and adapt to their needs.


I have also tried the information at https://github.com/Qubes-Community/ 
but again it is not written well for a beginner.


Implementing WireGuard for secure network access is necessary before I 
can connect this installation to the Internet so I hope someone can help 
me to set this up.


--
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/9bcea286-c7db-da5a-349b-3af3329b22c3%40magenta.de.

[qubes-users] "GVFS is not available"

[alesser]

I am using a fresh installation of Qubes 4.1.1.

When I use the File Manager Preferences tab there is a message 
indicating that GVFS is not available. "Important features including 
trash support, removable media and remote location browsing will not work".


I also notice that I cannot use removable storage with any of my VMs, if 
I attach a storage device to a VM the OS indicates success but the 
device is not available anywhere.


I think part of the problem is probably that I do not have a sys-usb.

Can someone help me correct these problems?

--
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/7a2a6857-4347-00d5-5a64-50c2afa20043%40magenta.de.

[qubes-users] Disabling Hibernation universally

[alesser]

I am still in the process of configuring Qubes (4.1.1). I am trying now 
to disable Hibernation at all level of the system.


I couldn't find any reference of Hibernation in the official 
documentation or the Wiki. Could someone describe the way to disable it 
universally?


--
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/502fda89-067b-c55a-c33e-dc436a6c24dd%40magenta.de.

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

[Andrew David Wong]

Dear Qubes Community,

We have published [Qubes Security Bulletin 091: Windows PV drivers potentially 
compromised](https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-091-2023.txt).
 The text of this QSB and its accompanying cryptographic signatures are 
reproduced below. For an explanation of this announcement and instructions for 
authenticating this QSB, please see the end of this announcement.

## Qubes Security Bulletin 091

```

 ---===[ Qubes Security Bulletin 091 ]===---

 2023-07-26

 Windows PV drivers potentially compromised

User action required
-

At the time of writing, no fix is available, so no user action is
required. However, users may wish to consider discontinuing the use of
Qubes Windows Tools (QWT) in security-sensitive Windows qubes until a
fix is available. Users with especially high security requirements may
wish to consider recreating existing Windows qubes without QWT or
replacing existing Windows qubes with qubes running a different
operating system.

Summary


On 2023-07-24, the Xen Project published "Xen Security Notice 1:
winpvdrvbuild.xenproject.org potentially compromised" [1], which states:

| Software running on the Xen Project hosted subdomain
| winpvdrvbuild.xenproject.org is outdated and vulnerable to several
| CVEs.  Some of the reported issues include remote code execution.  The
| affected host was running the Jenkins build system for the Windows PV
| Drivers subproject.

| Since the list of CVEs reported include remote code execution we no
| longer have confidence that binaries previously available at:
|
| https://xenbits.xen.org/pvdrivers/win/
|
| are trustworthy.  This includes binaries signed with Xen Project's EV
| key that is cross-signed by Microsoft.

Qubes Windows Tools includes the Xen Project's Windows PV Drivers.

Impact
---

If the Xen Project's Windows PV Drivers were compromised at build time,
all Windows qubes that have Qubes Windows Tools (QWT) installed may also
be compromised. If the drivers were not compromised at build time, then
there is no known vulnerability.

Dom0 is not affected, even though the `qubes-windows-tools` package is
installed in dom0, since neither the dom0 package build process nor dom0
itself interprets these driver files. Rather, the purpose of this
package is merely to make the driver files available to the Windows
qubes in which QWT are installed.

Discussion
---

We decided to use the Xen Project's official Windows PV Driver binaries
in Qubes Windows Tools (QWT) (rather than building our own binaries from
source) because the Xen Project's official binaries are signed by a
special key that Windows accepts by default, which avoids the need to
enable test-signing mode in Windows when installing the drivers. (We
have no such key.) We used this approach for all versions of QWT
released for Qubes 4.0 (driver version 8.2.1, May 2017), Qubes 4.1
(driver version 8.2.2, April 2019), and Qubes 4.2 (same as Qubes 4.1).

While we have no way to know whether driver versions 8.2.1 or 8.2.2 have
actually been compromised, it is worth noting that if the binaries were
not compromised at build time, they could not have been tampered with
after that time, since they were stored on another system and signed
with a timestamped signature proving they were not modified afterward.

At the time of writing, the Xen Project has not published replacement
binaries signed by a Microsoft-approved key. The process for doing this
has changed since the last version of Windows PV Drivers was released,
and we have no information as to whether or when new signed binaries
will be available. [2]

In order to avoid similar problems in the future, we are working on a
more permanent solution regarding the need for signed PV drivers in QWT.
In the meantime, we will replace the `qubes-windows-tools` package with
a dummy package containing only warning text.

Credits


See the original Xen Security Notice.

References
---

[1] 
https://lists.xenproject.org/archives/html/xen-announce/2023-07/msg0.html
[2] 
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/deprecation-of-software-publisher-certificates-and-commercial-release-certificates

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

```

*Source*: 


## [Marek 
Marczykowski-Górecki](https://www.qubes-os.org/team/#marek-marczykowski-górecki)'s
 PGP signature

```
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEELRdx/k12ftx2sIn61lWk8hgw4GoFAmTCHCgACgkQ1lWk8hgw
4Grc+g//Xk6OJ5XDnRfYBAxbU19c+h+hAwUKmuYW413B4Vzs9NtPLOCO6Nw4Ckh6
YCWrg9yusY4DglBOaelTgVsVoS6JgrkdqXzFCi0DUXJHdsw/GsKoezVBbwMlC3mp
XoNgfL/meHuqRIjCf6BGj9SmDYvGJH4zQKqTe+RI9Zgk6sCSkH46WLHrdsoN4/FW
pvYD7fSLAkba1P/rXoJPRYvym8GMnrCMDgpWiI2jMp43AStjLIg1Cuyb4Zrwo6X4
uBHDdXrrMLpIGAA/P4agHMY5uNDQDF+UZA65Hk54Ko+3FbgAtxmYUx0IbdS4AcgY

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

[Andrew David Wong]

Dear Qubes Community,

The [Xen Project](https://xenproject.org/) has released one or more [Xen 
security advisories (XSAs)](https://xenbits.xen.org/xsa/).
The security of Qubes OS *is affected*.
Therefore, *user action is required*.

## XSAs that DO affect the security of Qubes OS

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

- [XSA-433](https://xenbits.xen.org/xsa/advisory-433.html)
  - See [QSB-090](https://www.qubes-os.org/news/2023/07/24/qsb-090/) for 
details.

## XSAs that DO NOT affect the security of Qubes OS

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

- (none)

## About this announcement

Qubes OS uses the [Xen 
hypervisor](https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as 
part of its [architecture](https://www.qubes-os.org/doc/architecture/). When 
the [Xen Project](https://xenproject.org/) publicly discloses a vulnerability 
in the Xen hypervisor, they issue a notice called a [Xen security advisory 
(XSA)](https://xenproject.org/developers/security-policy/). Vulnerabilities in 
the Xen hypervisor sometimes have security implications for Qubes OS. When they 
do, we issue a notice called a [Qubes security bulletin 
(QSB)](https://www.qubes-os.org/security/qsb/). (QSBs are also issued for 
non-Xen vulnerabilities.) However, QSBs can provide only *positive* 
confirmation that certain XSAs *do* affect the security of Qubes OS. QSBs 
cannot provide *negative* confirmation that other XSAs do *not* affect the 
security of Qubes OS. Therefore, we also maintain an [XSA 
tracker](https://www.qubes-os.org/security/xsa/), which is a comprehensive list 
of all XSAs publicly disclosed to date, including whether each one affects the 
security of Qubes OS. When new XSAs are published, we add them to the XSA 
tracker and publish a notice like this one in order to inform Qubes users that 
a new batch of XSAs has been released and whether each one affects the security 
of Qubes OS.


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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-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/e9bc749c-703f-8c92-7e41-52f5e118bfa8%40qubes-os.org.

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

[Andrew David Wong]

Dear Qubes Community,

We have published [Qubes Security Bulletin 090: Zenbleed (CVE-2023-20593, 
XSA-433)](https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-090-2023.txt).
 The text of this QSB and its accompanying cryptographic signatures are 
reproduced below. For an explanation of this announcement and instructions for 
authenticating this QSB, please see the end of this announcement.

## Qubes Security Bulletin 090

```

 ---===[ Qubes Security Bulletin 090 ]===---

  2023-07-24

 Zenbleed (CVE-2023-20593, XSA-433)

User action required
-

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

  For Qubes 4.1, in dom0:
  - linux-firmware 20230625-146
  - Xen packages 4.14.5-21

  For Qubes 4.2, in dom0:
  - linux-firmware 20230625-147
  - Xen packages 4.17.1-3

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

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

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

Summary


On 2023-07-24, the Xen Project published XSA-433, "x86/AMD: Zenbleed"
[3]:
| Researchers at Google have discovered Zenbleed, a hardware bug causing
| corruption of the vector registers.
|
| When a VZEROUPPER instruction is discarded as part of a bad transient
| execution path, its effect on internal tracking are not unwound
| correctly.  This manifests as the wrong micro-architectural state
| becoming architectural, and corrupting the vector registers.
|
| Note: While this malfunction is related to speculative execution, this
|   is not a speculative sidechannel vulnerability.
|
| The corruption is not random.  It happens to be stale values from the
| physical vector register file, a structure competitively shared between
| sibling threads.  Therefore, an attacker can directly access data from
| the sibling thread, or from a more privileged context.
|
| For more details, see:
|   https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html
|
| 
https://github.com/google/security-research/security/advisories/GHSA-v6wh-rxpg-cmm8


Impact
---

As explained in XSA-433, this vulnerability is specific to the AMD Zen 2
microarchitecture, and AMD does not believe that other
microarchitectures are affected. Exploiting this vulnerability would
allow an attacker to read data from different contexts on the same core.
Examples of such data include key material, ciphertext and plaintext
from AES-NI operations, and the contents of REP-MOVS instructions, which
are commonly used to implement `memcpy()`.

In order to exploit this vulnerability, an attacker must be capable of
executing code at any privilege level in any qube, e.g., JavaScript in a
web browser. Moreover, the code to reliably exploit this vulnerability
is publicly available. Accordingly, there is a high risk of this
vulnerability being exploited in practice.

Credits


Tavis Ormandy of Google Project Zero.

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

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

```

*Source*: 


## [Marek 
Marczykowski-Górecki](https://www.qubes-os.org/team/#marek-marczykowski-górecki)'s
 PGP signature

```
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEELRdx/k12ftx2sIn61lWk8hgw4GoFAmS/KlsACgkQ1lWk8hgw
4GoXhQ//Sz9mT1IPGqmifJnpxz9wbPrhDQQ5vb9gKQZgvPSv4L4PY2MRYb7zmGR5
bI62gFp7hgKFU7T+0pNLDUPsA3fBCJtrdfkQLn2vkkV0gE7NXY48dtYIWPQ0smSv
cd+wfG6yrVnGKc08yWRsA8Zp2zSKaHrERKi5DQZjZexBtt9PVMk3hCkmEHjFCNqs
dFey8WXJsF5nUJqTPd4FWsLRW+ktvGv3RJ8j/XtjwYsYljgX/sGtTgJUW4yrks7f
NaIQ3c+B4nEz33zgR5bAdMLGCX0xxXPyCRwNNg5FUpBOZIlV4W1vl1EMUDVoa/s6
c8KHTI5a127i+RWI9KKY6zINscqYXWEaH2ppojzN8bIZpFuB1BJu63oXpycUPGOS
TfKWaY5T7v3casxaQtf18polAxi9LS2KRYcTPUAaRUrpxfte8mTqEuvtTD7h4bIX
BRLl0TYzC/Q3/2LpSsto55JMgJBF53DyX4Gin0Ix0slTLToqIUk8gNXhjE0PB+U3
QJWuArI4uDTflEj78WregZ7S0pi7oDILO2JV1+fcgl2yGui6+77O63HXBpgvCCag
hFDDIsgxg2PwtXQpziU5GeLbEKDiAMi10ex1aXEprhdcj/VyqXIrcSvqKu4w3S5d
pkNkhKPtWpP+mFh/NuCip8IwjCSsP0IUCXhUXHvtsKdL1hIsrDQ=
=xznI
-END PGP SIGNATURE-
```

*Source*: 


## [Simon Gaiser (aka 
HW42)](https://www.qubes-os.org/team/#simon-gaiser-aka-hw42)'s PGP signature

```
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEE6hjn8EDEHdrv6aoPSsGN4REuFJAFAmS/I5gACgkQSsGN4REu

Re: [qubes-users] Issuing the command 'qvm-run --user=user some-dom kill -9 some-pid' on dom0 returns a message...

[Boryeu Mao]

Thanks for the info.  With --pass-io no error messages were returned
from qvm-run
and kill.  I am now inclined to think that the process (being one from
command firefox-esr running on some-dom) returns a exit code of 9 when kill'ed
with SIGKILL, which is caught by qvm-run, which issues the message some-dom:
command failed with code: 137.  When SIGTERM is used to kill the process,
the code 143 (128+15) is returned instead of 137.

On Sat, Jul 22, 2023 at 6:55 AM Rusty Bird  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Boryeu Mao:
> > of ``some-dom: command failed with code: 137``, which I have been
> ignoring
> > since the job with ``some-pid`` did get killed.  What could be the
> meaning
> > of the code 137 and its significance?
>
> 137 == 128 + (signal) 9
> https://www.gnu.org/software/bash/manual/bash.html#Exit-Status
>
> If you add --pass-io to the failing qvm-run invocation, it will show
> any error messages from the VM.
>
> Rusty
> -BEGIN PGP SIGNATURE-
>
> iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmS73iJfFIAALgAo
> aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
> QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
> Kt9q+g/+NY/PHFREA0xHudV3Ldr7/Qbl3ISrFS75c2hTpZFLGb8TwYx8PF9V2kwV
> p38vtXrFfwfN77auPKchQMjNRxdaz8JI4HZzW9I82ovu7J6tHJHgJsKYe9vVMLD5
> EnecANWtDs/RSqKL0M6IdfpAADOdkw5EyTr/9fu44ckZZ+TYt0ZbMoN9UUk1LfGH
> 6a2l27k24Cmgfq6dSeAMl9fAfbNPA5webFDniSY5GJmD7k25wA+Y0/xWZ/A4w8RP
> et2oh67nRdGXBplvZtX/F+J+WMUZZU3AXlwp2ml6Rm5RS19a8FLsGTxa0o8r1eaJ
> j+d+Ns8DoHwuHdePgHg8eOmbdm8TdUL2wshqPhRt72fNqK1RBEHWfBQJhbfWNor6
> eT18+UhuaoLInuF2A3oRh1SDBi2Y3MAELpcldIBsMsA17E9QNph6pU0XkMsuVqgm
> niDCY1Tr8AkCGuflgKegeN0GmP1VI6XNz0u/SilrSC+HfEgvcAYdsG721r4t5N1k
> osoeRRllOmQJwFtNG3I0NAtSTW8gGsq2uCiDpWcCDnkhHPn+UXI5B0aXNlYia0/+
> Sm4MOXN9lNG0JM3DKHa7QyWt8/AnwMkx2vMhT1z6cHp/5PcV3+40WcNaOhwvZLTb
> G0DAjmeyn6X8UFwsrvlEejSwlRq/799p186wusAoqgXdjgHnwv4=
> =63wE
> -END PGP SIGNATURE-
>
>

-- 
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/CAOBBCnbA9LWGo4G-1uEyiOrkUZ%3D1U1P5ewnRJXkdWF5-V3Y_Qg%40mail.gmail.com.

Re: [qubes-users] Issuing the command 'qvm-run --user=user some-dom kill -9 some-pid' on dom0 returns a message...

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Boryeu Mao:
> of ``some-dom: command failed with code: 137``, which I have been ignoring 
> since the job with ``some-pid`` did get killed.  What could be the meaning 
> of the code 137 and its significance?

137 == 128 + (signal) 9
https://www.gnu.org/software/bash/manual/bash.html#Exit-Status

If you add --pass-io to the failing qvm-run invocation, it will show
any error messages from the VM.

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmS73iJfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt9q+g/+NY/PHFREA0xHudV3Ldr7/Qbl3ISrFS75c2hTpZFLGb8TwYx8PF9V2kwV
p38vtXrFfwfN77auPKchQMjNRxdaz8JI4HZzW9I82ovu7J6tHJHgJsKYe9vVMLD5
EnecANWtDs/RSqKL0M6IdfpAADOdkw5EyTr/9fu44ckZZ+TYt0ZbMoN9UUk1LfGH
6a2l27k24Cmgfq6dSeAMl9fAfbNPA5webFDniSY5GJmD7k25wA+Y0/xWZ/A4w8RP
et2oh67nRdGXBplvZtX/F+J+WMUZZU3AXlwp2ml6Rm5RS19a8FLsGTxa0o8r1eaJ
j+d+Ns8DoHwuHdePgHg8eOmbdm8TdUL2wshqPhRt72fNqK1RBEHWfBQJhbfWNor6
eT18+UhuaoLInuF2A3oRh1SDBi2Y3MAELpcldIBsMsA17E9QNph6pU0XkMsuVqgm
niDCY1Tr8AkCGuflgKegeN0GmP1VI6XNz0u/SilrSC+HfEgvcAYdsG721r4t5N1k
osoeRRllOmQJwFtNG3I0NAtSTW8gGsq2uCiDpWcCDnkhHPn+UXI5B0aXNlYia0/+
Sm4MOXN9lNG0JM3DKHa7QyWt8/AnwMkx2vMhT1z6cHp/5PcV3+40WcNaOhwvZLTb
G0DAjmeyn6X8UFwsrvlEejSwlRq/799p186wusAoqgXdjgHnwv4=
=63wE
-END PGP SIGNATURE-

-- 
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/ZLveIi7zGhl5G5lP%40mutt.

[qubes-users] Issuing the command 'qvm-run --user=user some-dom kill -9 some-pid' on dom0 returns a message...

[Boryeu Mao]

of ``some-dom: command failed with code: 137``, which I have been ignoring 
since the job with ``some-pid`` did get killed.  What could be the meaning 
of the code 137 and its significance?

Thanks in advance.

-- 
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/a1a66510-1740-40b3-a8b6-4c19076e9c8dn%40googlegroups.com.

[qubes-users] How to use lvms from a disk with a valid Qubes installation as qubes in another Qubes pc?

['Qru' via qubes-users]

In my desktop Qubes system the mainboard died. So I bought a new one. 
Unfortunately I didn't make a backup for some days.
After building the new hardware system my Qubes installation from the old ssd 
doesn't start there.
(Somehow the system freezes or at least the keyboard is being switched off just 
before I have to input the disk password.)

So I created a new Qubes installation on an USB stick, which works quite well 
in the new system (both are Qubes 4.1.)
Running this new installation I can still access my old ssd. I see all the lvms 
from my old installation (I have around 100 qubes, so about 250 lvms).
I can rename the vg, activate and mount each lvm and access all data. But I 
cannot use the lvms as qubes. They don't appear with qvm-ls.

How can I make use of these lvms?

I want to have them recognized as qubes. Then I want to make a full Qubes 
backup off all my cubes. And after a new Qubes installation I want to restore 
them.
I could backup the lvms in a non Qubes way. But then again I would have the 
problem to make them known as qubes to my new system.

I read all the documentation, especially "How to back up, restore, and 
migrate", "How to mount a Qubes partition from another OS" and "Secondary 
storage".
But this didn't answer my questions. I can access the data but I cannot use the 
old qubes as qubes in a new system.

How can this be accomplished?

Any help is highly appreciated.
- Qru

-- 
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/L4jvIaUKh4b4L-Jz8fii1D1PAfMri9aqTOBCwTdg5AMscbTZd_k3d-3VeLWVwegpSiD4np5-8IwsyME3E_ceCAX3gUBcBG3bbpbCrYVPScY%3D%40proton.me.

Re: [qubes-users] How to make sys-firewall broadcast a local qube as the system-wide DNS server?

[Leo28C]

Did I use the right command?
`sudo iptables -t nat -A PR-QBS -p tcp --dport 53 -j DNAT --to-destination
10.137.0.50` (repeat for udp)

Apparently DNS requests reach the DNS qube, but the response gets stuck
somewhere midway...

On Thu, Jun 8, 2023 at 8:58 AM unman  wrote:

> On Tue, Jun 06, 2023 at 01:24:18PM -0500, Leo28C wrote:
> > I managed to set up a pi-hole qube and make it my network's DNS
> > filtering/caching server. Ironically, it works flawlessly across my
> network
> > EXCEPT it completely breaks DNS for all other qubes in the same system.
> On
> > Debian-based qubes I figured out I can simply edit /etc/resolv.conf,
> while
> > making sure sys-firewall lets the two qubes talk to each other, as a
> > workaround. However this is a hacky per-qube solution and doesn't persist
> > across qube restarts. It would be nice to simply have sys-firewall relay
> > the information to all of its client qubes automatically. Any idea how to
> > do this?
> >
> > Thanks in advance!
> >
> You dont need to change the settings per qube at all.
> You haven't said *where* the pi-hole qube is located in your qubes
> network, or what the nature of the breakage is.
> I assume from what you say it is attached to sys-firewall.
>
> You can do this by editing the PR-QBS chain in nat table in
> sys-firewall.
> By default, this forwards all DNS traffic to 10.139.1.1 and 10.139.1.2
> using dnat. Flush that chain and replace it with dnat rules to the IP
> address of your Pi-hole qube.
> You could do this in /rw/config/qubes-firewall-user-script or by script
> in /rw/config/qubes-firewall.d
>

-- 
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/CAALhvVaAFaB0umupS40-hGuCP4kzUachFKS0c3fieHo9S6Gfuw%40mail.gmail.com.

Re: [qubes-users] QubesIncoming folder in /tmp ??

[Sven Semmler]

I like the way the ticket is formulated ... only empty directories should be 
removed. 

I'd be extremely careful with binding QubesIncoming to /tmp ... this might lead 
to unintended loss if qvm-move is used or the origin is a disposable and the 
user does not immediately move the file out of QubesIncoming. Also consider the 
Idle-Shutdown script.

Personally I often treat QubesIncoming as an Inbox of sorts for different 
domains. Having files vanish without manual interaction would be a disaster in 
some cases.

-- 
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/c553f8ae-26fa-4d43-8169-d76edc617e25%40app.fastmail.com.

Re: [qubes-users] QubesIncoming folder in /tmp ??

[Andrew David Wong]

On 6/30/23 3:27 AM, haaber wrote:
> Hi I was wondering if it would not me preferable (at least in some VM's)
> to delocalise the QubesIncoming folder in /tmp to have it "cleaned up"
> regularly. It's a pain to do so manually. Is there a problem doing so ? 
> What would be the cleanest way to do it? A symlink ??  thank you, Bernhard
> 

I thought there was already an open issue for this, but I couldn't find one, so 
I just opened this:

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

-- 
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/155da573-87c0-1c9e-6c4b-66f8edcc%40qubes-os.org.

Re: [qubes-users] QubesIncoming folder in /tmp ??

['unman' via qubes-users]

On Fri, Jun 30, 2023 at 12:27:41PM +0200, haaber wrote:
> Hi I was wondering if it would not me preferable (at least in some VM's)
> to delocalise the QubesIncoming folder in /tmp to have it "cleaned up"
> regularly. It's a pain to do so manually. Is there a problem doing so ? 
> What would be the cleanest way to do it? A symlink ??  thank you, Bernhard
> 
I use this in rc.local:
```
mkdir /home/user/QubesIncoming
chown user:user /home/user/QubesIncoming
mkdir /tmp/QubesIncoming
chown user:user /tmp/QubesIncoming
mount --bind /tmp/QubesIncoming /home/user/QubesIncoming
```

I dont think the chown calls are needed, but I put them in , and have
not removed them.
Works as you would expect.

-- 
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/ZJ9%2B%2BrugSSu6AW6W%40thirdeyesecurity.org.

[qubes-users] QubesIncoming folder in /tmp ??

[Ulrich Windl (Google)]

Hi!

I wonder: Couldn't a systemd service do that?

Ulrich

-- 
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/0cd7229b-2f5c-4722-9418-a7c407843490%40gmail.com.

[qubes-users] QubesIncoming folder in /tmp ??

[haaber]

Hi I was wondering if it would not me preferable (at least in some VM's)
to delocalise the QubesIncoming folder in /tmp to have it "cleaned up"
regularly. It's a pain to do so manually. Is there a problem doing so ? 
What would be the cleanest way to do it? A symlink ??  thank you, Bernhard



--
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/113ec415-6225-c6d6-4994-dc38a9d0737f%40web.de.

Re: [qubes-users] The NovaCustom NV41 Series laptop is Qubes-certified!

[Franz]

Many thanks, but for what I know the last Intel  CPUs that allowed to
partially disable Intel ME using Coreboot were Ivy Bridge and Sandy Bridge.

So, what I understood is that the few corebooted computers using these old
CPUs and some AMD Opteron are the safest.

Is there any reason why this new Nova Custom NV41 may reach the same level
of control over Intel ME or perhaps perform even greater security?
Best
Franz

On Tue, Jun 27, 2023 at 6:47 AM Nova Custom (NovaCustom) <
snaaksyst...@gmail.com> wrote:

> Hi!
>
> Thank you for proposing this. It's a very good idea and we are working on
> this!
>
> On Wednesday, May 3, 2023 at 8:07:24 PM UTC+2 Leo28C wrote:
>
>> On Wed, May 3, 2023 at 5:12 AM Andrew David Wong 
>> wrote:
>>
>>> nor can we control whether physical hardware is modified (whether
>>> maliciously or otherwise) *en route* to the user.
>>>
>>
>> Actually you could:
>>
>> 1) Laminate product with `warranty void if removed` stickers of various
>> brands and types
>> 2) Send PGP-signed high-res photo of sticker placement to buyer before
>> shipping
>> 3) Buyer receives product and compares sticker placement to the photo to
>> verify integrity
>>
> --
> 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/b97c5f74-cd2e-484a-a845-30463a2a7982n%40googlegroups.com
> 
> .
>

-- 
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/CAPzH-qArUwzSJ7yjmPxwWmJn7B1VE6UVPsY85NtGFo%3Df7UsC8g%40mail.gmail.com.

Re: [qubes-users] The NovaCustom NV41 Series laptop is Qubes-certified!

[Nova Custom (NovaCustom)]

Hi!

Thank you for proposing this. It's a very good idea and we are working on 
this!

On Wednesday, May 3, 2023 at 8:07:24 PM UTC+2 Leo28C wrote:

> On Wed, May 3, 2023 at 5:12 AM Andrew David Wong  
> wrote:
>
>> nor can we control whether physical hardware is modified (whether 
>> maliciously or otherwise) *en route* to the user.
>>
>
> Actually you could:
>
> 1) Laminate product with `warranty void if removed` stickers of various 
> brands and types
> 2) Send PGP-signed high-res photo of sticker placement to buyer before 
> shipping
> 3) Buyer receives product and compares sticker placement to the photo to 
> verify integrity
>

-- 
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/b97c5f74-cd2e-484a-a845-30463a2a7982n%40googlegroups.com.

[qubes-users] debian-12 (bookwork) audio issue

[haaber]

Has someone solved the audio issue (on R4.1.2) that happens after an
upd=grade ofn debian-11 (bullseye) to 12 (bookworm)? Suddenly sound is
dead. Thank you, Bernhard

--
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/88d0f94c-a149-eb73-8096-782bf3bd%40web.de.

Re: [qubes-users] split firefox & thunderbird credentials?

[Andrew David Wong]

On 6/22/23 7:38 AM, haaber wrote:
> I was wondering if the awesome split-ssh and split-gpg  family could be
> extended by a split-mozilla brother, that outsources passwords to vault
> without exposing them? The lack of such a feature obliges me *not* to
> save them within the two apps, which is a terrible pain, of corse 
> 
> thanks in advance
> 

Rusty wrote this:

https://github.com/rustybird/qubes-app-split-browser

(Disclaimers: It's unofficial. I haven't tried it myself.)

-- 
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/1326f48c-856d-5a66-c838-b8a250fec2e8%40qubes-os.org.

Re: [qubes-users] where may I find logs for USB controller

[haaber]

Hello friends,

I bought a PCIe USB controller card, which is advertised to work with
linux.
It is Sonnettech Allegro Pro 4 USB 3.2 Gen 2 Type-C.

On my fully updated system, lspci shows the other USB controllers, but
nothing about Allegro. So I wrote to Sonnenttech and they asked for
the logs to study them.

Due to the peculiar nature of Qubes that hides USB controllers from
dom0 (lsusb reports no USB device) I am confused about which logs may
be useful.



In the sys-usb "qube settings" go to devices and see if sys-usb is
allowed to "see" your device. Maybe you did that already, maybe not :)
Tell us.

--
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/bfe315e0-9555-d71e-b4a1-bdc661c0dded%40web.de.

[qubes-users] where may I find logs for USB controller

[Franz]

Hello friends,
I bought a PCIe USB controller card, which is advertised to work with linux.
It is Sonnettech Allegro Pro 4 USB 3.2 Gen 2 Type-C.

On my fully updated system, lspci shows the other USB controllers, but
nothing about Allegro. So I wrote to Sonnenttech and they asked for the
logs to study them.

Due to the peculiar nature of Qubes that hides USB controllers from dom0
(lsusb reports no USB device) I am confused about which logs may be useful.

Any idea?
Best
Franz

-- 
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/CAPzH-qA9GYdTQu46Oz%2Bnw1MB2PLjO%2BrYeXZu3XUV4qj8U_nr1Q%40mail.gmail.com.

[qubes-users] split firefox & thunderbird credentials?

[haaber]

I was wondering if the awesome split-ssh and split-gpg  family could be
extended by a split-mozilla brother, that outsources passwords to vault
without exposing them? The lack of such a feature obliges me *not* to
save them within the two apps, which is a terrible pain, of corse 

thanks in advance


--
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/6189b50b-fa81-e0ca-a654-ace6bb229d0d%40web.de.

Re: [qubes-users] Re: ssh-split issue

[haaber]

remaining question: if I want vault to hold several SSH keys, should I best

(a) replace the single ssh-add command by   "ssh-add c /path/to/key1 &&
ssh-add -c /path/to/key2"

or

(b) create a ssh-add-my-keys.sh containing

ssh-add -c /path/to/key1

ssh-add -c /path/to/key2

ssh-add -c /path/to/key3

and modify the autostart line to

Exec=/path/to/ssh-add-my-keys.sh



--
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/adbed0d3-62df-2bd9-d3d1-146122d4a018%40web.de.

Re: [qubes-users] Re: ssh-split issue

[haaber]

Solved. Stupid me!

> I re-checked, my /etc/qubes-rpc/policy/qubes.SSHagent says only

one line, namely

ssh-client vault ask

which I find odd (= I do not understand), since in the nomenclature of
the man-page, ssh-client=work not vault, right?


it is of course either

"@anyvm vault ask" or "work valut ask", right? That does it! Stupid me.



--
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/512aa08f-45d7-6652-67d4-cade30ba567a%40web.de.

Re: [qubes-users] Re: ssh-split issue

[haaber]

Thank you.


>> We observe that the file /run/user/1000/openssh_agent  is different
>> from    /home/user/.SSH_AGENT_sshkeys. That may be a problem.


You seem to be running the "ssh-agent.service" in your work qube. This
is not part of the linked setup guide. There only one agent is running
and that is in the vault qube.


right, that was a remainder from various tests to debug. I killed it.
Actually, to revert everything to clean setup state, I restarted both
VM's, work and vault.


The "clients" (e.g. work qube) only redirect the communication via
socat, qubes RPC and the /home/user/.SSH_AGENT_vault file to the
ssh-agent in the vault qube.


thank you for clarification.


> Running the following command in the work qube should work:
>    SSH_AUTH_SOCK=/home/user/.SSH_AGENT_vault ssh-add -L

error fetching identities: communication with agent failed

That is the answer, with a pop-up message from qubes "denied
qubes.SSHagent  from work to vault". Something is odd ... now dom0  log
says "qrexec: qubes.SSHagent: work -> vault: denied: no matching rule
found".  I re-checked, my /etc/qubes-rpc/policy/qubes.SSHagent says only
one line, namely

ssh-client vault ask

which I find odd (= I do not understand), since in the nomenclature of
the man-page, ssh-client=work not vault, right?

thank you, Bernhard



--
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/630f0a89-2af9-596a-58c7-c126b611fb78%40web.de.

Re: [qubes-users] Re: ssh-split issue

[1b6c8d73d15b.qubeslist via qubes-users]

On 21/06/2023 11:49, haaber wrote:
>> We observe that the file /run/user/1000/openssh_agent  is different
>> from/home/user/.SSH_AGENT_sshkeys. That may be a problem.

Running the following command in the work qube should work:
SSH_AUTH_SOCK=/home/user/.SSH_AGENT_vault ssh-add -L

You seem to be running the "ssh-agent.service" in your work qube. This 
is not part of the linked setup guide. There only one agent is running 
and that is in the vault qube.


The "clients" (e.g. work qube) only redirect the communication via 
socat, qubes RPC and the /home/user/.SSH_AGENT_vault file to the 
ssh-agent in the vault qube.


See: 
https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/split-ssh.md#in-the-appvm-ssh-client


--
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/6ac70fb1-8854-7d38-a9ca-1f13c487736a%40xafy.de.

[qubes-users] Re: ssh-split issue

[haaber]

update: somewhere I wrote "vault", somewhere "sshkeys". Correcting this
does NOT resolve the problem :((

On 6/21/23 11:45, haaber wrote:

I tried to follow carefully the split-ssh instructions on

https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/split-ssh.md


but I experience a stupid error. I did a "plain setup" without
keepass. So when I run

ssh-add -L       in vault it does work, and has 1 test-identity.

ssh-add -L       in work     it does not work "Error connecting to
agent: Connection refused"

even with "-v -v -v" I get no better hint. So I tried to follow the
traces;

1.) This happens when I ("manually") run

user@work:~$   bash -x /etc/qubes-rpc/qubes.SSHagent

++ qubesdb-read /name
+ notify-send '[work] SSH agent access from: dom0'
+ socat - UNIX-CONNECT:/home/user/.SSH_AGENT_sshkeys
2023/06/21 11:24:59 socat[1562] E connect(, AF=1
"/home/user/.SSH_AGENT_sshkeys", 34): Connection refused

you may observe that I wrote SSH with 3 capital letters, but I did so
everywhere (I hope :), inclusive the small script snipplets from
github page.


2.) This happens when I query the ssh agent:

systemctl --user status ssh-agent.service
● ssh-agent.service - OpenSSH Agent
 Loaded: loaded (/usr/lib/systemd/user/ssh-agent.service; static)
 Active: active (running) since Wed 2023-06-21 11:18:46 CEST;
22min ago
   Docs: man:ssh-agent(1)
   Main PID: 1513 (ssh-agent)
  Tasks: 1 (limit: 4618)
 Memory: 872.0K
    CPU: 3ms
 CGroup:
/user.slice/user-1000.slice/user@1000.service/app.slice/ssh-agent.service
 └─1513 ssh-agent -D -a /run/user/1000/openssh_agent

Jun 21 11:18:46 work systemd[654]: Started ssh-agent.service - OpenSSH
Agent.
Jun 21 11:18:46 work agent-launch[1515]:
dbus-update-activation-environment: setting
SSH_AUTH_SOCK=/run/user/1000/openssh_ag>
Jun 21 11:18:46 work agent-launch[1515]:
dbus-update-activation-environment: setting SSH_AGENT_LAUNCHER=openssh
Jun 21 11:18:46 work agent-launch[1513]:
SSH_AUTH_SOCK=/run/user/1000/openssh_agent; export SSH_AUTH_SOCK;
Jun 21 11:18:46 work agent-launch[1513]: echo Agent pid 1513;

We observe that the file /run/user/1000/openssh_agent  is different
from    /home/user/.SSH_AGENT_sshkeys. That may be a problem.

I tried to fix that temporarily with linking one to the other ("ln
-s") . Then ssh-add -L does not fail, but has no identities.



Here I am stuck. Any hints?  Thank you, Bernhard



--
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/ea7b96b0-2d22-3dbc-0f57-a6ff9a738039%40web.de.

[qubes-users] ssh-split issue

[haaber]

I tried to follow carefully the split-ssh instructions on

https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/split-ssh.md

but I experience a stupid error. I did a "plain setup" without keepass.
So when I run

ssh-add -L       in vault it does work, and has 1 test-identity.

ssh-add -L       in work     it does not work "Error connecting to
agent: Connection refused"

even with "-v -v -v" I get no better hint. So I tried to follow the traces;

1.) This happens when I ("manually") run

user@work:~$   bash -x /etc/qubes-rpc/qubes.SSHagent

++ qubesdb-read /name
+ notify-send '[work] SSH agent access from: dom0'
+ socat - UNIX-CONNECT:/home/user/.SSH_AGENT_sshkeys
2023/06/21 11:24:59 socat[1562] E connect(, AF=1
"/home/user/.SSH_AGENT_sshkeys", 34): Connection refused

you may observe that I wrote SSH with 3 capital letters, but I did so
everywhere (I hope :), inclusive the small script snipplets from github
page.


2.) This happens when I query the ssh agent:

systemctl --user status ssh-agent.service
● ssh-agent.service - OpenSSH Agent
 Loaded: loaded (/usr/lib/systemd/user/ssh-agent.service; static)
 Active: active (running) since Wed 2023-06-21 11:18:46 CEST; 22min ago
   Docs: man:ssh-agent(1)
   Main PID: 1513 (ssh-agent)
  Tasks: 1 (limit: 4618)
 Memory: 872.0K
    CPU: 3ms
 CGroup:
/user.slice/user-1000.slice/user@1000.service/app.slice/ssh-agent.service
 └─1513 ssh-agent -D -a /run/user/1000/openssh_agent

Jun 21 11:18:46 work systemd[654]: Started ssh-agent.service - OpenSSH
Agent.
Jun 21 11:18:46 work agent-launch[1515]:
dbus-update-activation-environment: setting
SSH_AUTH_SOCK=/run/user/1000/openssh_ag>
Jun 21 11:18:46 work agent-launch[1515]:
dbus-update-activation-environment: setting SSH_AGENT_LAUNCHER=openssh
Jun 21 11:18:46 work agent-launch[1513]:
SSH_AUTH_SOCK=/run/user/1000/openssh_agent; export SSH_AUTH_SOCK;
Jun 21 11:18:46 work agent-launch[1513]: echo Agent pid 1513;

We observe that the file /run/user/1000/openssh_agent  is different from
   /home/user/.SSH_AGENT_sshkeys. That may be a problem.

I tried to fix that temporarily with linking one to the other ("ln -s")
. Then ssh-add -L does not fail, but has no identities.



Here I am stuck. Any hints?  Thank you, Bernhard

--
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/0bd9348b-4b84-297a-3c6b-53c0f4e9800a%40web.de.

Re: [qubes-users] suspend on Dell Latitude 3520 (i5, GeForce MX350)

[Sylwester Arabas]

Hi, marmarek!

Thank for following up!

On 18/06/2023 14:35, Marek Marczykowski-Górecki wrote:

On Mon, Jun 05, 2023 at 03:24:52PM +0200, Sylwester Arabas wrote:

I'm trying out Qubes OS on a new Dell Latitude 3520 laptop. It has a 4-core
i5 (cpu family: 6, model: 140) and it came with pre-installed Ubuntu. Qubes
installation from a USB drive went smooth using the R4.1.2 image; wifi and
sound worked well out of the box. The first showstopper is a problem with
suspend support.



Tried so far updating the dom0 kernel to 6.3.2 and setting
"mem_sleep_default=deep" within grub.cfg, but neither helped.



The symptom is that, after closing the lid, the system seems to suspend, but
it does not resume. The only way out is to hold the power button long enough
so that a full reboot is made.



What might be relevant:



 [slayoo@dom0 ~]$ sudo dmesg | grep ACPI | grep supports
 [3.798651] ACPI: PM: (supports S0 S5)
 [slayoo@dom0 ~]$ cat /sys/power/mem_sleep
 [s2idle]


That is the problem. Qubes currently doesn't support it yet, only S3 is
supported. Look if you have a BIOS option to enable S3 (sometimes called
"Linux S3" or similar). If not, I'm afraid you are out of luck, you can
see progress of s2idle support at (as you already found):
https://github.com/QubesOS/qubes-issues/issues/6411


In BIOS, I did find a seemingly relevant "Block Sleep" option. It was 
set to ON by default. The description reads: "This option lets you to 
block entering Sleep (S3) mode in the operating system". Changing it to 
OFF has not changed anything, though. This seems consistent with users' 
reports at 
https://www.dell.com/community/Linux-General/Dell-Latitude-5420-5520-S3-Suspend-deep-sleep-not-working-on/td-p/7981601


I have then tried to workaround it by modifying the DSDT table as 
suggested here: 
https://dev.to/epassaro/fix-suspend-issues-on-dell-7405-2-in-1-3l1b, but 
after decompiling the original table with the `iasl` tool, there seem to 
be no code relevant to S3 present in the .dsl file.


As a next step, I've updated BIOS (from v1.19.0 to 1.29.0 released by 
Dell this month). There seem to be no new relevant options in BIOS, and 
waking up from suspended state still does not work (checked again with 
"Block Sleep" OFF).


I'll be watching developments at the #6411 issue, then.
As of now, that's a genuine showstopper :(

Thanks!
Sylwester

--
https://slayoo.github.io/

--
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/7c4736f1-2081-3808-61aa-48b923412c41%40staszic.waw.pl.

Re: [qubes-users] qubes HCL report HP_EliteBook 845 G8

[K.N.]

Hello

Just a quick question - does keyboard backlit work ?

cheers, K.

czwartek, 4 maja 2023 o 10:58:27 UTC+2 haaber napisał(a):

> Dear all,
>
> Update of my HCL report: suspend to memory via xfce button works fine,
> but often sys-net is dead at wake-up. No harm: a simple qvm-start
> sys-net resolves that quickly, in particular, sys-firewall takes it
> easy.  Only lid-closing is more delicate: it hangs/crashes often -- so I
> decided close lid *after*  "suspend to memory" via xfce button only.
>
> best, Bernhard
>
>

-- 
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/771d5509-399b-4a62-9c2f-1bb5d379185en%40googlegroups.com.

Re: [qubes-users] suspend on Dell Latitude 3520 (i5, GeForce MX350)

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Jun 05, 2023 at 03:24:52PM +0200, Sylwester Arabas wrote:
> Hi All,

Hi Slayoo :)

> I'm trying out Qubes OS on a new Dell Latitude 3520 laptop. It has a 4-core
> i5 (cpu family: 6, model: 140) and it came with pre-installed Ubuntu. Qubes
> installation from a USB drive went smooth using the R4.1.2 image; wifi and
> sound worked well out of the box. The first showstopper is a problem with
> suspend support.
> 
> Tried so far updating the dom0 kernel to 6.3.2 and setting
> "mem_sleep_default=deep" within grub.cfg, but neither helped.
> 
> The symptom is that, after closing the lid, the system seems to suspend, but
> it does not resume. The only way out is to hold the power button long enough
> so that a full reboot is made.
> 
> What might be relevant:
> 
> [slayoo@dom0 ~]$ sudo dmesg | grep ACPI | grep supports
> [3.798651] ACPI: PM: (supports S0 S5)
> [slayoo@dom0 ~]$ cat /sys/power/mem_sleep
> [s2idle]

That is the problem. Qubes currently doesn't support it yet, only S3 is
supported. Look if you have a BIOS option to enable S3 (sometimes called
"Linux S3" or similar). If not, I'm afraid you are out of luck, you can
see progress of s2idle support at (as you already found):
https://github.com/QubesOS/qubes-issues/issues/6411

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmSO+fQACgkQ24/THMrX
1ywOagf9FyWF5uz74ZsS8hhNtRpIbKzlof9A0kEGBOMxfc6cvvtwhObGUs3+/5as
nURdKbwGVn9anNTF86eRDf4r6vWRkeMwqtpCSSlid/6Dm9HlZQV6AZLAvjxXSOJR
sroDGhl9XhY1N7xBAW6Nh9almy7/BjYEYTUmdCHqSwGDDYpqLCff5DRuPOuTSd/T
QaefwV/kUIc+/xnb6dAING7Io1IG+Qw6q3DVdFSt/RmYjkrNHlJQ7d4EDhqgLae4
dyW5OcK5U8Ysj87kOqb9sHDMsGtpmJmc3f1KFSAUj1AlEOuGdiYo6N7Ydpodx90b
ACh9KH3WzBJduG8/a6N5eTnS8/w6JA==
=WFZZ
-END PGP SIGNATURE-

-- 
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/ZI759XnfSnVy6H1L%40mail-itl.

[qubes-users] capturing X selection event

[Boryeu Mao]

In an AppVM based on Debian-11 template, I would like a `bash` script 
running in `xfce Terminal` to catch an X selection `paste` event in 
`firefox-esr` - is that possible, and where to look?   Thanks in advance.

-- 
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/650a98b2-342a-47bb-9057-d50f1dd6ff1fn%40googlegroups.com.

[qubes-users] Suche jemand in München - Augsburg - Ulm - Stuttgart oder auch woanders

[caroline....@gmail.com]

Hallo,

ich bin gerade auf Tour von München nach Stuttgart, ich dachte das man sich 
mal Treffen könnte um diese Qubes OS Probleme zu beheben.

Ich suche zu diesen Problem noch eine Lösung: 
- Ich habe ein Update Problem
- Ein Passwort Problem, muss Qubes OS oft neu starten, weil ich ein Problem 
mit dem 2. Passwort habe.
- Wie kann ich meine erstellte Dateien aus der Windowszeit auf mein neuen 
Computer Qubes OS übertragen?
- Wie kann ich die Apps so platzieren, das man diese beim nächsten leichter 
starten kann.
Den ich muss in Works auf Software gehen wie neu installieren, dann kann 
ich erst das Programm öffnen. Geht das Ganze auch einfacher?

Wann gibt es ein Qubes OS Treffen in D, AT, CH, so was gab es mal vor 
Jahren. 
Darum suche ich so was da ich da sehr gerne Teilnehmen möchte.
Mein Wunsch ist, mit den Qubes OS Programmierer mehr Kontakt um das 
Betriebssystem sehr viel besser kennenzulernen.

Gruß
Caroline & Erwin
 

-- 
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/35345def-124f-4f2e-9f6c-7b24b31d15a2n%40googlegroups.com.

Re: [qubes-users] HCL report motherboard MSI MEG x670e ACE

[Sven Semmler]

Now it's online: 
https://www.qubes-os.org/hcl/#msi_meg-x670e-ace-ms-7d69_ryzen-9-7900x_integrated-graphics-amd-rtx-2080ti_rickyjumb_4-2-0-alpha

--
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/92d9d1ae-8051-d2ae-cdc7-f0d51dbab048%40SvenSemmler.org.

Re: [qubes-users] HCL - cirrus7 nimbini v3 (NUC12WSHv5)

[Sven Semmler]

Now it's online: 
https://www.qubes-os.org/hcl/#cirrus7_nimbini-v3-nuc12wshv5_i5-1250p_integrated-graphics-iris-xe_eichennarr_r4-1

--
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/07cd1556-9e5b-361d-4bfa-9be75e84f71e%40SvenSemmler.org.

Re: [qubes-users] HCL report motherboard MSI MEG x670e ACE

[Sven Semmler]

Thank you rickyjumb for your HCL report, which is not visible on the website 
yet but already 
[committed](https://github.com/QubesOS/qubes-hcl/commit/17c120047db50f5ccc535498f6d186654e470fd0)
 to the `qubes-hcl` repository. It'll show soon.

Sorry for the delay.

/Sven

--
https://keys.openpgp.org/vks/v1/by-fingerprint/DA5975C9ABC40C833B2F620B2A632C537D744BC7

--
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/bd10f28a-f2bd-283c-9c14-d70afc57237a%40SvenSemmler.org.

Re: [qubes-users] HCL - cirrus7 nimbini v3 (NUC12WSHv5)

[Sven Semmler]

Thank you Eichennarr for your HCL report. It's not on the website yet due to a 
little technical hick up but I 
[committed](https://github.com/QubesOS/qubes-hcl/commit/3cef301544ea7d3d871a0a481eec4cde597c8ceb)
 it into the `qubes-hcl` repository. So it'll show up very soon. Sorry for the 
delay.

/Sven

--
https://keys.openpgp.org/vks/v1/by-fingerprint/DA5975C9ABC40C833B2F620B2A632C537D744BC7

--
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/5c53e70e-08e3-43d5-f16e-85869bbc63c5%40SvenSemmler.org.

Re: [qubes-users] How to make sys-firewall broadcast a local qube as the system-wide DNS server?

['unman' via qubes-users]

On Tue, Jun 06, 2023 at 01:24:18PM -0500, Leo28C wrote:
> I managed to set up a pi-hole qube and make it my network's DNS
> filtering/caching server. Ironically, it works flawlessly across my network
> EXCEPT it completely breaks DNS for all other qubes in the same system. On
> Debian-based qubes I figured out I can simply edit /etc/resolv.conf, while
> making sure sys-firewall lets the two qubes talk to each other, as a
> workaround. However this is a hacky per-qube solution and doesn't persist
> across qube restarts. It would be nice to simply have sys-firewall relay
> the information to all of its client qubes automatically. Any idea how to
> do this?
> 
> Thanks in advance!
> 
You dont need to change the settings per qube at all.
You haven't said *where* the pi-hole qube is located in your qubes
network, or what the nature of the breakage is.
I assume from what you say it is attached to sys-firewall.

You can do this by editing the PR-QBS chain in nat table in
sys-firewall.
By default, this forwards all DNS traffic to 10.139.1.1 and 10.139.1.2
using dnat. Flush that chain and replace it with dnat rules to the IP
address of your Pi-hole qube.
You could do this in /rw/config/qubes-firewall-user-script or by script
in /rw/config/qubes-firewall.d

-- 
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/ZIHekYeyI0BY5uUa%40thirdeyesecurity.org.

Re: [qubes-users] suspend on Dell Latitude 3520 (i5, GeForce MX350)

[Sylwester Arabas]

On 07/06/2023 08:44, haaber wrote:

 > I'm trying out Qubes OS on a new Dell Latitude 3520 laptop. It has a
4-core i5 (cpu family: 6, model: 140) and it came with pre-installed
Ubuntu. Qubes installation from a USB drive went smooth using the R4.1.2
image; wifi and sound worked well out of the box. The first showstopper
is a problem with suspend support.

Try if a "software-suspend" via xfce button works better. That is my
personal workaround.


Trying `xfce4-session-logout --suspend` or clicking xfce menu -> suspend 
results in exactly the same behaviour - the system instantly suspends, 
but no luck in waking it up.


BTW, reporting on Qubes GitHub issue tracker, I've been pointed to 
https://github.com/QubesOS/qubes-issues/issues/6411 where a likely 
relevant discussion takes place.


Thanks for your reply,
Sylwester

--
https://slayoo.github.io/

--
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/ad61e482-b3b7-e20b-01f6-ad66d50b178d%40staszic.waw.pl.

Re: [qubes-users] suspend on Dell Latitude 3520 (i5, GeForce MX350)

[Sylwester Arabas]

On 07/06/2023 08:01, Ulrich Windl (Google) wrote:

Do you recognize any hardware activity when trying to resume?


Pressing any keyboard key causes the keyboard backlight to turn on for a 
few seconds (which does not happen after pressing the power-on button).



What about journal messages in Dom0

This seems to be the relevant part of `journalctl` output:

Jun 08 11:24:55 dom0 systemd[1]: Starting Qubes suspend hooks...
Jun 08 11:24:57 dom0 52qubes-pause-vms[4634]: 0
Jun 08 11:24:57 dom0 systemd[1]: Finished Qubes suspend hooks.
Jun 08 11:24:57 dom0 audit[1]: SERVICE_START pid=1 uid=0 
auid=4294967295 ses=4294967295 msg='unit=qubes-suspend comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? re>
Jun 08 11:24:57 dom0 kernel: audit: type=1130 audit(1686216297.032:303): 
pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-suspend 
comm="systemd" exe="/usr/lib/systemd/systemd" hos>

Jun 08 11:24:57 dom0 systemd[1]: Reached target Sleep.
Jun 08 11:24:57 dom0 systemd[1]: Starting Suspend...
Jun 08 11:24:57 dom0 systemd-sleep[4642]: Suspending system...
Jun 08 11:24:57 dom0 kernel: PM: suspend entry (s2idle)
-- Reboot --
Jun 08 11:28:06 dom0 kernel: Linux version 
6.3.2-1.qubes.fc32.x86_64 ...


BTW, reporting on Qubes GitHub issue tracker, I've been pointed to 
https://github.com/QubesOS/qubes-issues/issues/6411 where a likely 
relevant discussion takes place.


Thanks for your reply,
Sylwester

--
https://slayoo.github.io/

--
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/db8ce9b9-417f-076f-96af-443acafe8cc2%40staszic.waw.pl.

[qubes-users] How to make sys-firewall broadcast a local qube as the system-wide DNS server?

[Leo28C]

I managed to set up a pi-hole qube and make it my network's DNS
filtering/caching server. Ironically, it works flawlessly across my network
EXCEPT it completely breaks DNS for all other qubes in the same system. On
Debian-based qubes I figured out I can simply edit /etc/resolv.conf, while
making sure sys-firewall lets the two qubes talk to each other, as a
workaround. However this is a hacky per-qube solution and doesn't persist
across qube restarts. It would be nice to simply have sys-firewall relay
the information to all of its client qubes automatically. Any idea how to
do this?

Thanks in advance!

-- 
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/CAALhvVbRa9kNyRgOUN_0OnaiX-f0ZfpOMwkqR5YX4%3D9%3DyBYndA%40mail.gmail.com.

Re: [qubes-users] suspend on Dell Latitude 3520 (i5, GeForce MX350)

[haaber]

> I'm trying out Qubes OS on a new Dell Latitude 3520 laptop. It has a
4-core i5 (cpu family: 6, model: 140) and it came with pre-installed
Ubuntu. Qubes installation from a USB drive went smooth using the R4.1.2
image; wifi and sound worked well out of the box. The first showstopper
is a problem with suspend support.

Try if a "software-suspend" via xfce button works better. That is my
personal workaround.



--
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/6083c8c6-2f54-cb35-ac62-0d5cbf6f66af%40web.de.

[qubes-users] suspend on Dell Latitude 3520 (i5, GeForce MX350)

[Ulrich Windl (Google)]

Do you recognize any hardware activity when trying to resume?
What about journal messages in Dom0?

Regards,
Ulrich

-- 
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/e439b5af-acd4-4ae8-a687-fb7497f1113e%40gmail.com.

Re: [qubes-users] Re: HCL - cirrus7 nimbini v3 (NUC12WSHv5)

[Sven Semmler]

On 6/6/23 04:20, 'sonnenfinsternis' via qubes-users wrote:

Do I still have to submit something to be included in the HCl or do I just need 
some more patience


It's not you, it's me. Super busy. Will take care soon.

/Sven


--
https://keys.openpgp.org/vks/v1/by-fingerprint/DA5975C9ABC40C833B2F620B2A632C537D744BC7

--
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/3698d4ec-0ba0-f2a0-1029-0238dfc5553a%40SvenSemmler.org.

Re: [qubes-users] Q4.1 xfce - "clicks in the void"

[Andrew David Wong]

On 6/5/23 3:39 AM, haaber wrote:
> I often experience clicks that get lost "in the void" meaning that the
> actual xfce windows does not seem to receive them.
> 
> Typical example: I use firefox, and a noscript pop-up ("load
> anonymously") with a button to click on: but I can't. What helps then,
> is changing the virtual screen (go away) and coming back: after this, 
> the click arrives again at the destination window. Very annoying!
> 
> Am I alone with this problem???  Best, Bernhard
> 

There's a longstanding bug where certain types of windows sometimes can't be 
clicked until focus is removed from that window, then given back again. I 
usually alt+tab to another window, then back to the original window to fix 
this. I'm not sure if you're experiencing the same thing, but it sounds 
similar. Also, I'm not sure if this is the right issue for what I'm describing, 
but it seems to fit:

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

-- 
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/5e20a937-deef-665a-f9dc-56b519d840df%40qubes-os.org.

[qubes-users] Re: HCL - cirrus7 nimbini v3 (NUC12WSHv5)

['sonnenfinsternis' via qubes-users]

After more than a week of intensive use, I haven't noticed any problems so far. 
The "cirrus7 nimbini v3" (or presumably all NUC12WSHv5) seemed to be suitable 
hardware for anyone who wants to use QubesOS as a desktop system. 
Do I still have to submit something to be included in the HCl or do I just need 
some more patience ;-) 
Kind regards from an enthusiastic QubesOS fan :)

--- Original Message ---
On Wednesday, May 24th, 2023 at 11:51 PM, sonnenfinsternis 
 wrote:


> Here's my review of the cirrus7 nimbini v3, which is largely based on the 
> Intel NUC 12 (NUC12WSHv5). QubesOS with the "kernel latest" option runs 
> great. Most importantly, it is a dream to work on a fanless computer that 
> still runs completely silent under heavy load despite various Qubes running 
> in parallel including several standalone machines.
> 
> Best regards :-)
> Eichennarr
> 
> ---
> layout:
> 'hcl'
> type:
> 'mini pc'
> hvm:
> 'yes'
> iommu:
> 'yes'
> slat:
> 'yes'
> tpm:
> 'unknown'
> remap:
> 'yes'
> brand: |
> cirrus7
> model: |
> nimbini v3 (NUC12WSHv5)
> bios: |
> WSADLV57.0087.2023.0306.1817
> cpu: |
> 12th Gen Intel(R) Core(TM) i5-1250P
> cpu-short: |
> i5-1250P
> chipset: |
> Intel Corporation Device [8086:4621] (rev 02)
> chipset-short: |
> FIXME
> gpu: |
> Intel Iris Xe 80U
> gpu-short: |
> FIXME
> network: |
> Intel Wi-Fi 6E AX211
> memory: |
> 65092
> scsi: |
> 
> usb: |
> 4
> versions:
> 
> - works:
> yes
> qubes: |
> R4.1
> xen: |
> 4.14.5
> kernel: |
> 6.1.12-1
> remark: |
> works with kernel latest
> credit: |
> Eichennarr
> link: |
> FIXLINK
> 
> ---

-- 
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/jdzlEY6whbd2mfjTslSTwrq9NFcuQe5iweTJ11-aXUIhbawrYTef9-HKmubZfhh9V235fPH_gfc4u1zBHeCuTOTL1W1ZfVs1-sNuD_qRdZs%3D%40protonmail.ch.

[qubes-users] suspend on Dell Latitude 3520 (i5, GeForce MX350)

[Sylwester Arabas]

Hi All,

I'm trying out Qubes OS on a new Dell Latitude 3520 laptop. It has a 
4-core i5 (cpu family: 6, model: 140) and it came with pre-installed 
Ubuntu. Qubes installation from a USB drive went smooth using the R4.1.2 
image; wifi and sound worked well out of the box. The first showstopper 
is a problem with suspend support.


Tried so far updating the dom0 kernel to 6.3.2 and setting 
"mem_sleep_default=deep" within grub.cfg, but neither helped.


The symptom is that, after closing the lid, the system seems to suspend, 
but it does not resume. The only way out is to hold the power button 
long enough so that a full reboot is made.


What might be relevant:

[slayoo@dom0 ~]$ sudo dmesg | grep ACPI | grep supports
[3.798651] ACPI: PM: (supports S0 S5)
[slayoo@dom0 ~]$ cat /sys/power/mem_sleep
[s2idle]
[slayoo@dom0 ~]$ uname -a
Linux dom0 6.3.2-1.qubes.fc32.x86_64 #1 SMP PREEMPT_DYNAMIC Fri May 
12 00:18:49 CEST 2023 x86_64 x86_64 x86_64 GNU/Linux


Interestingly, after booting an Ubuntu from USB on the same machine, 
suspend does work, and analogous commands as above show that ACPI 
supports "S0 S4 S5" (S4 not featured on Qubes), while 
/sys/power/mem_sleep contains the same single entry.


HCL report:

[slayoo@dom0 ~]$ qubes-hcl-report dom0
Qubes release 4.1.2 (R4.1)

Brand:  Dell Inc.
Model:  Latitude 3520
BIOS:   1.19.0

Xen:4.14.5
Kernel: 6.3.2-1

RAM:32510 Mb

CPU:
  11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
Chipset:
  Intel Corporation 11th Gen Core Processor Host Bridge/DRAM 
Registers [8086:9a14] (rev 01)

VGA:
  Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] 
(rev 01) (prog-if 00 [VGA controller])


Net:
  Intel Corporation Wi-Fi 6 AX201 (rev 20)
  Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express 
Gigabit Ethernet Controller (rev 15)


SCSI:


HVM:Active
I/O MMU:Active
HAP/SLAT:   Yes
TPM:Device not found
Remapping:  yes

Any hints very welcome, thanks,
Sylwester

--
https://slayoo.github.io/

--
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/d7746913-887f-317f-f78e-87bbe89962ba%40staszic.waw.pl.

Re: [qubes-users] Q4.1 xfce - "clicks in the void"

[Dan Krol]

I noticed something like this but I think it's usually triggered by
something in dom0. Most notably I have a finicky power button and I get the
reset/logout/shutdown dialog. When I hit escape to make it go away, I have
to change virtual screens back and forth as you described.

On Mon, Jun 5, 2023 at 6:40 AM haaber  wrote:

> I often experience clicks that get lost "in the void" meaning that the
> actual xfce windows does not seem to receive them.
>
> Typical example: I use firefox, and a noscript pop-up ("load
> anonymously") with a button to click on: but I can't. What helps then,
> is changing the virtual screen (go away) and coming back: after this,
> the click arrives again at the destination window. Very annoying!
>
> Am I alone with this problem???  Best, Bernhard
>
> --
> 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/2afe0f52-d38d-e50a-297d-b1680d8a48a8%40web.de
> .
>

-- 
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/CAAWRcS-a6Z0a5KchOdnKRbm8sc%2BZKJZcqOWawUjut4-T4B2g3A%40mail.gmail.com.

[qubes-users] Q4.1 xfce - "clicks in the void"

[haaber]

I often experience clicks that get lost "in the void" meaning that the
actual xfce windows does not seem to receive them.

Typical example: I use firefox, and a noscript pop-up ("load
anonymously") with a button to click on: but I can't. What helps then,
is changing the virtual screen (go away) and coming back: after this, 
the click arrives again at the destination window. Very annoying!

Am I alone with this problem???  Best, Bernhard

--
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/2afe0f52-d38d-e50a-297d-b1680d8a48a8%40web.de.

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

[Andrew David Wong]

Dear Qubes Community,

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

## What's new in Qubes 4.2.0?

- Dom0 upgraded to Fedora 37
- Xen updated to version 4.17
- SELinux support in Fedora templates
- Several GUI applications rewritten, including:
  - Applications Menu
  - Qubes Global Settings
  - Create New Qube
  - Qubes Update
- Unified `grub.cfg` location for both UEFI and legacy boot
- PipeWire support
- fwupd integration for firmware updates
- Optional automatic clipboard clearing
- Official packages built using Qubes Builder v2

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

## Reminder: new signing key for Qubes OS 4.2

As a reminder, we published the following special announcement in [Qubes Canary 
032](https://www.qubes-os.org/news/2022/09/14/canary-032/) on 2022-09-14:

> We plan to create a new Release Signing Key (RSK) for Qubes OS 4.2. Normally, 
> we have only one RSK for each major release. However, for the 4.2 release, we 
> will be using Qubes Builder version 2, which is a complete rewrite of the 
> Qubes Builder. Out of an abundance of caution, we would like to isolate the 
> build processes of the current stable 4.1 release and the upcoming 4.2 
> release from each other at the cryptographic level in order to minimize the 
> risk of a vulnerability in one affecting the other. We are including this 
> notice as a canary special announcement since introducing a new RSK for a 
> minor release is an exception to our usual RSK management policy.

As always, we encourage you to 
[authenticate](https://www.qubes-os.org/security/pack/#how-to-obtain-and-authenticate)
 this canary by [verifying its PGP 
signatures](https://www.qubes-os.org/security/verifying-signatures/). Specific 
instructions are also included in the [canary 
announcement](https://www.qubes-os.org/news/2022/09/14/canary-032/).

As with all Qubes signing keys, we also encourage you to 
[authenticate](https://www.qubes-os.org/security/verifying-signatures/#how-to-import-and-authenticate-release-signing-keys)
 the new Qubes OS Release 4.2 Signing Key, which is available in the [Qubes 
Security Pack (qubes-secpack)](https://www.qubes-os.org/security/pack/) as well 
as on the [downloads](https://www.qubes-os.org/downloads/) page under the Qubes 
OS 4.2.0-rc1 ISO.

## Testing Qubes 4.2.0-rc1

If you're willing to [test](https://www.qubes-os.org/doc/testing/) this release 
candidate, you can help us improve the eventual stable release by [reporting 
any bugs you encounter](https://www.qubes-os.org/doc/issue-tracking/). We 
encourage experienced users to join the [testing 
team](https://forum.qubes-os.org/t/joining-the-testing-team/5190).

A full list of known bugs in Qubes 4.2.0 is available 
[here](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+4.2%22+label%3A%22T%3A+bug%22).
 We strongly recommend [updating Qubes 
OS](https://www.qubes-os.org/doc/how-to-update/) immediately after installation 
in order to apply all available bug fixes.

## Upgrading to Qubes 4.2.0-rc1

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

## When is the stable release?

That depends on the number of bugs discovered in this release candidate and 
their severity. As explained in our [release 
schedule](https://www.qubes-os.org/doc/version-scheme/#release-schedule) 
documentation, our usual process after issuing a new release candidate is to 
collect bug reports, triage the bugs, and fix them. This usually takes around 
five weeks, depending on the bugs discovered. If warranted, we then issue a new 
release candidate that includes the fixes and repeat the whole process again. 
We continue this iterative procedure until we're left with a release candidate 
that's good enough to be declared the stable release. No one can predict, at 
the outset, how many iterations will be required (and hence how many release 
candidates will be needed before a stable release), but we tend to get a 
clearer picture of this with each successive release candidate, which we'll 
share in this section in future release candidate announcements.

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

[qubes-users] HCL report motherboard MSI MEG x670e ACE

['R D T' via qubes-users]

Here is my HCL report for the motherboard MSI MEG x670e ACE.

Booting even the installer works only with the x2apic=false flag set in
both xen and linux lines in grub. Automatic creation of networking related
qubes (sys-firewall and sys-net) during first configuration after install
crashes the pc.
Displayport is working, video seems to be working at least from an initial
test. Usb devices work and attach successfully to qubes.
Creation of new qubes works.
Will have to attempt to manually create networking qubes and report back.
I should also note that the motherboard is running a beta bios version due
to a problem with vsoc voltage being set too high and not properly capped
leading sometimes to frying 7000 series cpus with expo profiles enabled.
Best regards,
rickyjumb

-- 
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/168569294942.7.16578028694072641953.136828018%40simplelogin.com.


Qubes-HCL-Micro_Star_International_Co___Ltd_-MS_7D69-20230602-065754.yml
Description: application/yaml

Re: [qubes-users] Trying my luck

[Qubes]

Ulrich Windl (Google) wrote:
Just wondering: Is the remote end Windows, and could some virus scanner block 
the rename request? You know Windows has kind of strange locking rules.


No the SMB server is running on OmniOS which is Illumos kernel.

--
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/c50703f7-a6ae-b659-a618-cbb5ccdf905e%40ak47.co.za.

Re: [qubes-users] Trying my luck

[Ulrich Windl (Google)]

Just wondering: Is the remote end Windows, and could some virus scanner block 
the rename request? You know Windows has kind of strange locking rules.

-- 
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/d2959f54-3bc9-4ee1-babf-d3217719530f%40gmail.com.

Re: [qubes-users] Trying my luck

[Qubes]

Qubes wrote:

Qubes wrote:
I am just trying my luck here with an issue that i have been unable to 
resolve on my Qubes system for a long time now. I have been looking 
into this problem quite a bit but i cannot seem to find a solution 
anywhere. Perhaps someone on this list has experienced the same and 
has found a solution.


When i open a text file that is located on a network share with gedit, 
gedit is unable to save the file. When I click the save button, or 
`Ctrl + s`, i can see gedit creates a temporary file named 
".goutputstream-AO9U51" on the network share and in gedit i get a 
message "Could not create a backup file while saving 
"/home/user/data/test/file-name.txt"". If i launch gedit from cli i 
see a message on cli when saving the file "Hit unhandled case 27 
(Error renaming temporary file: Resource temporarily unavailable) in 
parse_error."


I definitely have permissions on the network share as i can copy files 
to it, delete, create directories, etc. I can also open a LibreOffice 
document and save it. The problem appears to be specific to gedit. 
Also, it happens with both a Fedora and Debian based VM.


In addition that i forgot to mention is, i can open edit and save the 
same txt files with vi and it works.


I have read reports [1][2][3][4][6] dating as far back as 12 years with 
the sshfs protocol (an abandoned project) being implicated as well.


On issue 438 [3] that was reported on Gitlab it is reported that "As far 
as I can tell, the problem is in the way glib saves a file by writing to 
a temporary file and renaming to the final name." and "I'll take a more 
serious look later but I'd start with gio/glocalfileoutputstream.c and 
particularly the function _g_local_file_output_stream_really_close which 
contains the error string "Error renaming temporary file".".


A duplicate issue 565 [5] to issue 438 [3] was opened and there a patch 
is provided that is said to fix this issue although i have not tried it 
because i don't know how to.


**Question:** Would anybody perhaps know how and where to do the patch, 
attached for reference, on Fedora/Debian. As far as I can tell the patch 
needs to be done on the client since the problem originates from the client.


[1]: 
https://askubuntu.com/questions/13843/gedit-sshfs-wont-save-vi-saves-fine
[2]: 
https://unix.stackexchange.com/questions/52951/gedit-wont-save-a-file-on-a-virtualbox-share-text-file-busy

[3]: https://gitlab.gnome.org/GNOME/glib/-/issues/438
[4]: https://github.com/rclone/rclone/issues/2130
[5]: https://gitlab.gnome.org/GNOME/glib/-/issues/565
[6]: 
https://illumos.topicbox.com/groups/omnios-discuss/Tc4c6b72d6386f9fb/resource-temporarily-unavailable-when-saving-to-cifs-share-on-r151038


--
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/41c6de8b-c200-0178-9cd9-c06809f94bfa%40ak47.co.za.
From 179812d0847af191e709539041a57d5779d847ed Mon Sep 17 00:00:00 2001
From: TW 
Date: Wed, 27 Jun 2012 19:35:33 +0200
Subject: [PATCH] gio: workaround for renaming files on filesystems not
 supporting it

This is a workaround for samba and "Virtual Box shared" filesystem which does not support renaming opened files and react on such attempt with ETXTBSY. It is also a solution proposal for:

Bug 678994 - Unable to overwrite files on vbox shared mounted filesystems
---
 gio/glocalfileoutputstream.c | 90 +++-
 1 file changed, 63 insertions(+), 27 deletions(-)

diff --git a/gio/glocalfileoutputstream.c b/gio/glocalfileoutputstream.c
index a310fcd..60e5f43 100644
--- a/gio/glocalfileoutputstream.c
+++ b/gio/glocalfileoutputstream.c
@@ -223,6 +223,7 @@ _g_local_file_output_stream_really_close (GLocalFileOutputStream *file,
 {
   GLocalFileStat final_stat;
   int res;
+  int smb_cifs_rename_workaround = 0;
 
 #ifdef HAVE_FSYNC
   if (file->priv->sync_on_close &&
@@ -318,17 +319,44 @@ _g_local_file_output_stream_really_close (GLocalFileOutputStream *file,
   if (g_cancellable_set_error_if_cancelled (cancellable, error))
 	goto err_out;
 
-  /* tmp -> original */
-  if (g_rename (file->priv->tmp_filename, file->priv->original_filename) != 0)
-	{
-  int errsv = errno;
 
-	  g_set_error (error, G_IO_ERROR,
-		   g_io_error_from_errno (errsv),
-		   _("Error renaming temporary file: %s"),
-		   g_strerror (errsv));
-	  goto err_out;
-	}
+  res = g_rename (file->priv->tmp_filename, file->priv->original_filename);
+
+  /* tmp -> original */
+  if (res != 0 && errno == ETXTBSY)
+  {
+	  // try to close the fd first and retry renaming
+	  if (fstat (file->priv->fd, _stat) == 0)
+		  file->priv->etag = _g_local_file_info_create_etag (_stat);
+
+	  while (1)
+	  {
+		  res = close 

Re: [qubes-users] Trying my luck

[Qubes]

Qubes wrote:
I am just trying my luck here with an issue that i have been unable to 
resolve on my Qubes system for a long time now. I have been looking into 
this problem quite a bit but i cannot seem to find a solution anywhere. 
Perhaps someone on this list has experienced the same and has found a 
solution.


When i open a text file that is located on a network share with gedit, 
gedit is unable to save the file. When I click the save button, or `Ctrl 
+ s`, i can see gedit creates a temporary file named 
".goutputstream-AO9U51" on the network share and in gedit i get a 
message "Could not create a backup file while saving 
"/home/user/data/test/file-name.txt"". If i launch gedit from cli i see 
a message on cli when saving the file "Hit unhandled case 27 (Error 
renaming temporary file: Resource temporarily unavailable) in parse_error."


I definitely have permissions on the network share as i can copy files 
to it, delete, create directories, etc. I can also open a LibreOffice 
document and save it. The problem appears to be specific to gedit. Also, 
it happens with both a Fedora and Debian based VM.


In addition that i forgot to mention is, i can open edit and save the 
same txt files with vi and it works.


--
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/55f71abc-061c-b3a5-c94a-f909aeaa3416%40ak47.co.za.

[qubes-users] Trying my luck

[Qubes]

I am just trying my luck here with an issue that i have been unable to 
resolve on my Qubes system for a long time now. I have been looking into 
this problem quite a bit but i cannot seem to find a solution anywhere. 
Perhaps someone on this list has experienced the same and has found a 
solution.


When i open a text file that is located on a network share with gedit, 
gedit is unable to save the file. When I click the save button, or `Ctrl 
+ s`, i can see gedit creates a temporary file named 
".goutputstream-AO9U51" on the network share and in gedit i get a 
message "Could not create a backup file while saving 
"/home/user/data/test/file-name.txt"". If i launch gedit from cli i see 
a message on cli when saving the file "Hit unhandled case 27 (Error 
renaming temporary file: Resource temporarily unavailable) in parse_error."


I definitely have permissions on the network share as i can copy files 
to it, delete, create directories, etc. I can also open a LibreOffice 
document and save it. The problem appears to be specific to gedit. Also, 
it happens with both a Fedora and Debian based VM.


--
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/768240c6-a0f9-387c-3d4d-67847e4dec4e%40ak47.co.za.

Re: [qubes-users] Re: Beginner questions

['sonnenfinsternis' via qubes-users]

--- Original Message ---
On Friday, May 26th, 2023 at 4:24 AM, 'Stuart Perkins' via qubes-users 
 wrote:


> Bottom post is the standard on this list. See my response at the bottom... :)
> 
> On Thu, 25 May 2023 19:02:23 +
> "'sonnenfinsternis' via qubes-users" qubes-users@googlegroups.com wrote:
> 
> > Sounds helpful, I'll try it when I get a chance, thanks :) After reading 
> > this [1], I can now even use my USB mouse directly after booting, without 
> > having to assign it to dom0 first. So slowly but surely I'm warming up to 
> > QubesOS. A wonderful system :) Now if I can just find a way to see how much 
> > processor load and memory is currently being used globally, I'll have all 
> > the pressing open construction sites taken care of for the time being. Over 
> > the weekend I will switch to a QubesOS installation as my new device for 
> > daily use. I am excited and glad that this project exists with this great 
> > community :)
> > 
> > 1: https://www.qubes-os.org/doc/usb-qubes/#usb-mice
> > 
> > --- Original Message ---
> > On Thursday, May 25th, 2023 at 8:39 AM, haaber haa...@web.de wrote:
> > 
> > > Hi
> > > 
> > > > 5) The question about autocomplete in the terminal has been resolved. 
> > > > This was indeed not due to QubesOS but to the fact that
> > > 
> > > the bash-completion package is not pre-installed by default in Debian.
> > > But this can be easily fixed:
> > > https://unix.stackexchange.com/questions/312456/debian-apt-not-apt-get-autocompletion-not-working
> > > 
> > > I have a nice working auto-complete for dom0. It allows usual
> > > qvm-commands (qvm-start, qvm-stop, etc) in dom0 terminal and
> > > distinguishes between running and non-running VM's according to what the
> > > command expects. Like: qvm-shutdown [TAB] proposes only running VM's to
> > > be shut down. etc.
> > > 
> > > Works like charm since qubes 3.2. You find the code attached.
> > > 
> > > Bernhard
> > > 
> > > --
> > > 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/023ce574-96ab-7f94-21d6-4726c1801ce1%40web.de.
> 
> 
> Welcome to Qubes OS. Personally, I love it. Even with the occasional awkward 
> way of doing something which is "point and click" on other OS's. The added 
> security of separation of programs and data plus template based VM's is 
> great. I've been a Qubes OS fan since 3.2. Add in a coreboot'd platform and 
> it is about the most secure PC available on the planet. A friend of mine who 
> built me such a laptop...2 actually (Lenovo T520 and a T420) was asked by the 
> country of Spain to build them 40. He has since dropped off the radar for 
> some reason. My current platform is marginally Qubes compatible...a Lenovo 
> W540...with no SSD it is very slow to come up, but works well once running. I 
> don't believe it can be coreboot'd though, so I will be creating another T420 
> for daily use. I am limited to pre "blob" architectures if I want coreboot 
> with no "blobs"...encrypted microcode "black box" portions of the BIOS, but 
> that is really separate from Qubes OS. I actually wore out the T520 and 
> previous T420 I had...but mine is "on" 16 hours a day or more...sometimes I 
> just leave it on when I go to bed...that is not really a surprise.
> 
> I found myself synthesizing the basic concept of template VM's manually with 
> VirtualBox before I discovered Qubes.
> 
> In a Dom0 terminal, the command "xentop" will list running qubes and the 
> resources they are consuming. It is a faster refresh than the GUI Qube 
> Manager.
> 
> Stuart
> 42 years in IT.
> 
> --
> 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/20230525222440.694ef12c%40yahoo.com.

Oh, I overlooked that. I will from now on also always answer below 0:-)

I did not know "xentop" yet, thanks. I had given up looking in the dom0 
terminal, since "top" does not display globally, but only from the view of 
dom0. Very good that xentop can look beyond the edge of the plate! But am I 
wrong, or does xentop (analogous to the Qube overview on the top right behind 
the blue cube) show the theoretical maximum RAM and ignores the memory 
balancing? 

-- 
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] Re: Beginner questions

['Stuart Perkins' via qubes-users]

Bottom post is the standard on this list.  See my response at the bottom...  :)

On Thu, 25 May 2023 19:02:23 +
"'sonnenfinsternis' via qubes-users"  wrote:

>Sounds helpful, I'll try it when I get a chance, thanks :) After reading this 
>[1], I can now even use my USB mouse directly after booting, without having to 
>assign it to dom0 first. So slowly but surely I'm warming up to QubesOS. A 
>wonderful system :) Now if I can just find a way to see how much processor 
>load and memory is currently being used globally, I'll have all the pressing 
>open construction sites taken care of for the time being. Over the weekend I 
>will switch to a QubesOS installation as my new device for daily use. I am 
>excited and glad that this project exists with this great community :)
>
>1: https://www.qubes-os.org/doc/usb-qubes/#usb-mice
>
>--- Original Message ---
>On Thursday, May 25th, 2023 at 8:39 AM, haaber  wrote:
>
>
>> Hi
>>   
>> > 5) The question about autocomplete in the terminal has been resolved. This 
>> > was indeed not due to QubesOS but to the fact that  
>> 
>> the bash-completion package is not pre-installed by default in Debian.
>> But this can be easily fixed:
>> https://unix.stackexchange.com/questions/312456/debian-apt-not-apt-get-autocompletion-not-working
>> 
>> I have a nice working auto-complete for dom0. It allows usual
>> qvm-commands (qvm-start, qvm-stop, etc) in dom0 terminal and
>> distinguishes between running and non-running VM's according to what the
>> command expects. Like: qvm-shutdown [TAB] proposes only running VM's to
>> be shut down. etc.
>> 
>> Works like charm since qubes 3.2. You find the code attached.
>> 
>> Bernhard
>> 
>> --
>> 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/023ce574-96ab-7f94-21d6-4726c1801ce1%40web.de.
>>   
>

Welcome to Qubes OS.  Personally, I love it.  Even with the occasional awkward 
way of doing something which is "point and click" on other OS's.  The added 
security of separation of programs and data plus template based VM's is great.  
I've been a Qubes OS fan since 3.2.  Add in a coreboot'd platform and it is 
about the most secure PC available on the planet.  A friend of mine who built 
me such a laptop...2 actually (Lenovo T520 and a T420) was asked by the country 
of Spain to build them 40.  He has since dropped off the radar for some reason. 
 My current platform is marginally Qubes compatible...a Lenovo W540...with no 
SSD it is very slow to come up, but works well once running.  I don't believe 
it can be coreboot'd though, so I will be creating another T420 for daily use.  
I am limited to pre "blob" architectures if I want coreboot with no 
"blobs"...encrypted microcode "black box" portions of the BIOS, but that is 
really separate from Qubes OS.  I actually wore out the T520 and previous T420 
I had...but mine is "on" 16 hours a day or more...sometimes I just leave it on 
when I go to bed...that is not really a surprise.

I found myself synthesizing the basic concept of template VM's manually with 
VirtualBox before I discovered Qubes.

In a Dom0 terminal, the command "xentop" will list running qubes and the 
resources they are consuming.  It is a faster refresh than the GUI Qube Manager.

Stuart
42 years in IT.  

-- 
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/20230525222440.694ef12c%40yahoo.com.

Re: [qubes-users] Re: Beginner questions

['sonnenfinsternis' via qubes-users]

Sounds helpful, I'll try it when I get a chance, thanks :) After reading this 
[1], I can now even use my USB mouse directly after booting, without having to 
assign it to dom0 first. So slowly but surely I'm warming up to QubesOS. A 
wonderful system :) Now if I can just find a way to see how much processor load 
and memory is currently being used globally, I'll have all the pressing open 
construction sites taken care of for the time being. Over the weekend I will 
switch to a QubesOS installation as my new device for daily use. I am excited 
and glad that this project exists with this great community :)

1: https://www.qubes-os.org/doc/usb-qubes/#usb-mice

--- Original Message ---
On Thursday, May 25th, 2023 at 8:39 AM, haaber  wrote:


> Hi
> 
> > 5) The question about autocomplete in the terminal has been resolved. This 
> > was indeed not due to QubesOS but to the fact that
> 
> the bash-completion package is not pre-installed by default in Debian.
> But this can be easily fixed:
> https://unix.stackexchange.com/questions/312456/debian-apt-not-apt-get-autocompletion-not-working
> 
> I have a nice working auto-complete for dom0. It allows usual
> qvm-commands (qvm-start, qvm-stop, etc) in dom0 terminal and
> distinguishes between running and non-running VM's according to what the
> command expects. Like: qvm-shutdown [TAB] proposes only running VM's to
> be shut down. etc.
> 
> Works like charm since qubes 3.2. You find the code attached.
> 
> Bernhard
> 
> --
> 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/023ce574-96ab-7f94-21d6-4726c1801ce1%40web.de.

-- 
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/ghDIY56OTqypK0u10MIiEMqaI9sDzcAVb7In4BOJ2wboKq5kLQ0P8ityQD6dRGulKYEpDWCIM_75cIoF5GHhPdqeWCrSJd5mcE1rbYcGuzc%3D%40protonmail.ch.

Re: [qubes-users] Re: Beginner questions

[haaber]

Hi


5) The question about autocomplete in the terminal has  been resolved. This was 
indeed not due to QubesOS but to the fact that

the bash-completion package is not pre-installed by default in Debian.
But this can be easily fixed:
https://unix.stackexchange.com/questions/312456/debian-apt-not-apt-get-autocompletion-not-working

I have a nice working auto-complete for dom0. It allows usual
qvm-commands (qvm-start, qvm-stop, etc) in dom0 terminal and
distinguishes between running and non-running VM's according to what the
command expects. Like:  qvm-shutdown [TAB] proposes only running VM's to
be shut down. etc.

Works like charm since qubes 3.2. You find the code attached.

Bernhard

--
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/023ce574-96ab-7f94-21d6-4726c1801ce1%40web.de.


qvm-autocomplete.sh
Description: Bourne shell script

[qubes-users] Re: HCL - cirrus7 nimbini v3 (NUC12WSHv5)

['sonnenfinsternis' via qubes-users]

I forgot to attach the yml file. Sorry!

--- Original Message ---
On Wednesday, May 24th, 2023 at 11:51 PM, sonnenfinsternis 
 wrote:


> Here's my review of the cirrus7 nimbini v3, which is largely based on the 
> Intel NUC 12 (NUC12WSHv5). QubesOS with the "kernel latest" option runs 
> great. Most importantly, it is a dream to work on a fanless computer that 
> still runs completely silent under heavy load despite various Qubes running 
> in parallel including several standalone machines.
> 
> Best regards :-)
> Eichennarr
> 
> ---
> layout:
> 'hcl'
> type:
> 'mini pc'
> hvm:
> 'yes'
> iommu:
> 'yes'
> slat:
> 'yes'
> tpm:
> 'unknown'
> remap:
> 'yes'
> brand: |
> cirrus7
> model: |
> nimbini v3 (NUC12WSHv5)
> bios: |
> WSADLV57.0087.2023.0306.1817
> cpu: |
> 12th Gen Intel(R) Core(TM) i5-1250P
> cpu-short: |
> i5-1250P
> chipset: |
> Intel Corporation Device [8086:4621] (rev 02)
> chipset-short: |
> FIXME
> gpu: |
> Intel Iris Xe 80U
> gpu-short: |
> FIXME
> network: |
> Intel Wi-Fi 6E AX211
> memory: |
> 65092
> scsi: |
> 
> usb: |
> 4
> versions:
> 
> - works:
> yes
> qubes: |
> R4.1
> xen: |
> 4.14.5
> kernel: |
> 6.1.12-1
> remark: |
> works with kernel latest
> credit: |
> Eichennarr
> link: |
> FIXLINK
> 
> ---

-- 
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/oGEvIb__nU8T7im80hRH0HyuAK5o-E7gxP6Ex0LnkhL0NaK2u16YAxlts8SdTbDGpKSXFkH3l8BFpybf3hCT6g7N29iLgFZX81pK33-qnBc%3D%40protonmail.ch.


Qubes-HCL-Intel_R__Client_Systems-NUC12WSHv5-20230524-223156.yml
Description: application/yaml

[qubes-users] HCL - cirrus7 nimbini v3 (NUC12WSHv5)

['sonnenfinsternis' via qubes-users]

Here's my review of the cirrus7 nimbini v3, which is largely based on the Intel 
NUC 12 (NUC12WSHv5). QubesOS with the "kernel latest" option runs great. Most 
importantly, it is a dream to work on a fanless computer that still runs 
completely silent under heavy load despite various Qubes running in parallel 
including several standalone machines.

Best regards :-)
Eichennarr

---
layout:
  'hcl'
type:
  'mini pc'
hvm:
  'yes'
iommu:
  'yes'
slat:
  'yes'
tpm:
  'unknown'
remap:
  'yes'
brand: |
  cirrus7
model: |
  nimbini v3 (NUC12WSHv5)
bios: |
  WSADLV57.0087.2023.0306.1817
cpu: |
  12th Gen Intel(R) Core(TM) i5-1250P
cpu-short: |
  i5-1250P
chipset: |
  Intel Corporation Device [8086:4621] (rev 02)
chipset-short: |
  FIXME
gpu: |
  Intel Iris Xe 80U
gpu-short: |
  FIXME
network: |
  Intel Wi-Fi 6E AX211
memory: |
  65092
scsi: |

usb: |
  4
versions:

- works:
yes
  qubes: |
R4.1
  xen: |
4.14.5
  kernel: |
6.1.12-1
  remark: |
works with kernel latest
  credit: |
Eichennarr
  link: |
FIXLINK

---

-- 
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/Q_i_As0bHmEZamFHxeUPHXSib7W3-W1TNAmwfB98J79p1NznD73wi27Q9bFxOhLI_6ougZkvC3YkNJgA5O2A0NaJrV7aaEr48JLN_1Gu8g4%3D%40protonmail.ch.

Re: [qubes-users] HCL - TUXEDO InfinityBook S 15 Gen7

['sonnenfinsternis' via qubes-users]

Thanks for quickly adding my data to the list :-)

--- Original Message ---
On Thursday, May 11th, 2023 at 2:32 AM, Sven Semmler  
wrote:


> Thank you Eichennarr for your HCL report, which is online now!
> 
> /Sven
> 
> --
> https://keys.openpgp.org/vks/v1/by-fingerprint/DA5975C9ABC40C833B2F620B2A632C537D744BC7
> 
> --
> 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/c9d56257-3daf-7656-2e0c-325c94f9ff26%40SvenSemmler.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/8UJOjuL2wsgemPxZnojoDE-C0eNb9XGXXLPRC3EugUV0uJ78PppNs9QAhUPnNvbnXE__l20Wwj5h8Dkd_JRGLQGIFccfAxdEwn_ST-BCbAo%3D%40protonmail.ch.

Re: [qubes-users] Re: Beginner questions

['sonnenfinsternis' via qubes-users]

First of all, thank you Kamil Aronowski for the long answer. There was a lot in 
it that helped me. :)

It might be clearest if I sort my answer by the numbering of my original 
questions:

1) I am still looking for a way to display the real global processor load and 
the real total global RAM usage in Qubes. Unfortunately I haven't found 
anything yet -_-.

2) I'll just stick with the existing ready-made templates for Linux then. If 
there is a clickable solution at some point, I would still be very interested 
in it though!

3) Too bad, but could have been. Then we just stick to opening qvm-template-gui 
via the terminal in dom0. It's not witchcraft, I just thought that maybe I 
missed the link in the GUI.

4) Interesting, thanks!

5) The question about autocomplete in the terminal has been resolved. This was 
indeed not due to QubesOS but to the fact that the bash-completion package is 
not pre-installed by default in Debian. But this can be easily fixed: 
https://unix.stackexchange.com/questions/312456/debian-apt-not-apt-get-autocompletion-not-working
Best regards :)
--- Original Message ---
On Tuesday, May 9th, 2023 at 7:57 PM, 'Kamil Aronowski' via qubes-users 
 wrote:

> Thanks for being part of our community!
>
> I don't know everything but can provide some hints.
>
>> 2) I have a Windows Qube as a standalone VM. The integration works fine 
>> thanks to qubes-windows-tools. But is there something similar for standalone 
>> Linux VMs? Assuming there is a LinuxMint in a standalone qube: What is the 
>> best way to exchange files or pass the clipboard to other "normal" Qubes? 
>> Via a USB stick? Surely there is a software solution :slight_smile:
>
> I haven't seen an ISO file or such a friendly distribution of the tools Qubes 
> uses for integration for Linux qubes. The tools do run in AppVMs (run `sudo 
> ps aux | grep qubes` to see for yourself) and if they were to be ported to 
> the target distro, I assume we'll be home then.
>
> There's the [qubes-builder](https://github.com/QubesOS/qubes-builder) 
> framework the developers wrote that can do this but this assumes building the 
> tools for the supported distros. I can't provide further assistance because 
> while the project is great and I was able to compile the officially supported 
> templates along with everything they require, I failed when trying to add an 
> unsupported system - some old Fedora and Debian releases.
>
>> 3) How do I know that there is a new template, e.g. Fedora 38? Do I have to 
>> check this myself regularly under qvm-template-gui? And while we are at it: 
>> Do I reach qvm-template-gui also somehow with the mouse over the gui?
>
> Currently it looks like it needs to be ran from commandline but I can help 
> writing a `.desktop` shortcut/launcher for this.
>
>> 4) I got to thinking when I saw that there is his fedora-37-xfce template. 
>> Is it possible to start the desktop in an app VM based on it? Does this 
>> actually work in general in a qube that is not a standalone installation? Or 
>> can I always start only individual programs?
>
> Yes and no.
>
> Keep in mind that Qubes has these tools and a custom X11 config provided for 
> this integration. They would have to be rewritten for a proper support, I 
> guess.
>
> Maybe it's a good idea to connect to a qube remotely via VNC or something and 
> instantiate an xfce4-session there. But in a regular case this will cause 
> visual mess. I'll attach a screenshot for this.
>
>> 5) And why does the tab completion in the terminal often not work in the 
>> Debian templates? Especially when installing software with "sudo apt install 
>> xyz" I have problems, because I have to know exactly what the packages are 
>> called.
>
> Seems like this is Debian-related and outside of the scope of Qubes 
> community. Maybe its `bash-completion` doesn't work as intended? I'd contact 
> the Debian team directly for that, since I suppose the same would be 
> happening even if installing Debian on a bare-matal environment.
>
>> I hope that I have not outed myself as a complete idiot with these 
>> questions. But I honestly haven't been able to figure them out for myself so 
>> far, so I wanted to put them up for debate here. Maybe there are other 
>> newbies like me with similar questions.
>
> No, you haven't. We're humans and have limited resources, especially when 
> coming to a new project. And just because something is intuitive for one 
> person, doesn't mean it will be intuitive for another one.
> We're here to assist each other and have a great time.
>
> On Tuesday, May 9, 2023 at 11:34:19 AM UTC+2 sonnenfinsternis wrote:
>
>> Hi there :)
>>
>> I've only been using QubesOS for two weeks and so far I'm totally thrilled! 
>> Thanks to all who contribute to this wonderful project :-)
>> But there are a few questions that I have not been able to clarify online or 
>> with friends, so I would like to try here:
>>
>> 1) Is there somewhere in the GUI an overview of the real 

[qubes-users] Qubes Canary 035

[Andrew David Wong]

Dear Qubes Community,

We have published [Qubes Canary 
035](https://github.com/QubesOS/qubes-secpack/blob/main/canaries/canary-035-2023.txt).
 The text of this canary and its accompanying cryptographic signatures are 
reproduced below. For an explanation of this announcement and instructions for 
authenticating this canary, please see the end of this announcement.

## Qubes Canary 035

```

---===[ Qubes Canary 035 ]===---


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 May 22, 2023.

2. There have been 89 Qubes security bulletins published so far.

3. The Qubes Master Signing Key fingerprint is:

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

4. No warrants have ever been served to us with regard to the Qubes OS
   Project (e.g. to hand out the private signing keys or to introduce
   backdoors).

5. We plan to publish the next of these canary statements in the first
   fourteen days of September 2023. Special note should be taken if no new
   canary is published by that time or if the list of statements changes
   without plausible explanation.


Special announcements
--

None.


Disclaimers and notes
--

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

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

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

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


Proof of freshness
---

Mon, 22 May 2023 08:16:45 +

Source: DER SPIEGEL - International 
(https://www.spiegel.de/international/index.rss)
Interview with NATO Secretary General Stoltenberg: "Two Percent Is the Minimum 
of What We Need"
Interview with Jordanian Foreign Minister Safadi: "Russia in Syria Is a 
Stabilizing Factor Compared To the Alternative"
Yevgeny Prigozhin's Meat Grinder: A Moment of Truth for Russia's Wagner Group 
in Bakhmut
The Three Worlds of Xinjiang: A Trip Through China's Uyghur Region
Operation Counterstrike: What Might the Approaching Ukrainian Offensive Achieve?

Source: NYT > World News 
(https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Greece Elections: New Democracy on Track to Win Most Votes
As Russia Claims Victory in Bakhmut, Ukraine Sees Opportunity Amid Ruins
Biden Announces More Aid for Ukraine as G7 Powers Meet in Japan
Sudan’s Warring Sides Agree to Weeklong Ceasefire
Inside the Barbecue City That Is China’s Hottest Tourist Destination

Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Ukraine war: Bakhmut 'not occupied' by Russia, says defiant Zelensky
Greek election: Centre-right Mitsotakis hails big win but wants majority
Thousands mass for pro-EU rally in Moldovan capital, amid tensions with Russia
US debt ceiling: Joe Biden urges Republicans to compromise as talks resume
Watch: Green flash as meteor blazes across sky in Australia

Source: Blockchain.info
0002fb9f59b4c425b487ade7bad8dd6862159ec3030f650f


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/

```

Source: 


## [Marek 
Marczykowski-Górecki](https://www.qubes-os.org/team/#marek-marczykowski-górecki)'s
 PGP signature

```
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEELRdx/k12ftx2sIn61lWk8hgw4GoFAmRrV3YACgkQ1lWk8hgw
4GrB5Q/9GchNzTj7MoQqAHsYWkZTy2qB4YOXmo6HedUqr//vz6zHx+BDne4sBiuy
V8knNY+7Wm3qvMaLvU56G7J35zJN/FeLKTbXcGBRk1sOxO67l4giuuwiq7ELTFvd
WPXblm63LpwzTIoTP4lkqb3VVEaqA5Lrr4U+fe/oqiFRX7KE3ZUEwMw078b2qqTo

Re: [qubes-users] Time and date of appVM

[Qubes]

Qubes wrote:

Qubes wrote:

Qubes wrote:

Qubes wrote:

Qubes wrote:
I have noticed than when my computer wakes up from sleep the dom0 
date and time updates as soon as my computer gets net connectivity, 
but my appVMs can take a loong time before their date and time 
also update. Is there any explanation for this and maybe a way to 
fix it?


Ok I can sync it manually in the appVM using `sudo qvm-sync-clock`. 
So the question is how can I set it to run more frequently in the 
appVM?


Update: When my computer wakes from sleep the appVMs never update 
their time. The only way is to manually run `sudo-qvm-sync-clock` or 
reboot the VM. Why do I see this behavior? I am sure date and time 
should sync everywhere automatically. Without the need, which looks 
to be the only solution currently, to create a small script that is 
executed at VM startup and it goes into a loop and runs 
`sudo-qvm-sync-clock` every 30 seconds.


  This is a serious problem, VMs don't sync their time on 4.2. Can 
anybody provide meaningful input?



Is there nothing I can do here?

Is it just me and my system or are you also seeing this?

I have resolved the issue of my VMs not syncing their time. It is 
actually quite interesting, because although VMs are set to 
automatically sync their time every 6 hours as is explained [here][1] a 
certain set of conditions caused the clocks on my VMs to 'never' sync. 
Other users can quite easily experience the same situation without 
realizing it.


I have filed [bug report 
8217](https://github.com/QubesOS/qubes-issues/issues/8217) for this.


To fix my issue I defined a custom clock sync definition in

`sudo vim /etc/systemd/system/qubes-sync-time.timer`

and added

```
[Timer]
OnUnitActiveSec=10s
```


[1]: 
https://github.com/Qubes-Community/Contents/blob/master/docs/system/clock-time.md#tweaking-time-synchronization-defaults


--
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/0c5a1c40-0534-90cc-ca5f-55ba9da2a50c%40ak47.co.za.

[qubes-users] Updating the fedora template (36->38)

[Ulrich Windl]

Hi!


Following the instructions to update the fedore-36 template to 
fedora-38, I saw these errors:


...

  Running scriptlet: pulseaudio-16.1-4.fc38.x86_64    
2866/2866
  Running scriptlet: kernel-modules-core-6.2.15-300.fc38.x86_64   
2866/2866
  Running scriptlet: kernel-core-6.2.15-300.fc38.x86_64   
2866/2866
/etc/default/grub: line 1: /etc/default/grub.qubes: No such file or 
directory
/etc/default/grub: line 1: /etc/default/grub.qubes: No such file or 
directory
warning: %posttrans(kernel-core-6.2.15-300.fc38.x86_64) scriptlet 
failed, exit status 1


Error in POSTTRANS scriptlet in rpm package kernel-core
  Running scriptlet: kernel-modules-6.2.15-300.fc38.x86_64    
2866/2866
  Running scriptlet: thunderbird-102.10.0-1.fc38.x86_64   
2866/2866
  Running scriptlet: xen-runtime-4.17.1-1.fc38.x86_64 
2866/2866
  Running scriptlet: libgcc-12.2.1-4.fc36.x86_64  
2866/2866
  Verifying    : 
abseil-cpp-20220623.1-4.fc38.x86_64 1/2866
  Verifying    : 
braille-printer-app-1:2.0~b0^386eea385f-3.fc38  2/2866

...


Unsure how serious that is, and whether it needs manual intervention.

Kind regards,

Ulrich


--
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/188493c6-1e9d-80c4-3f5a-b7d31b768136%40gmail.com.

Re: [qubes-users] dom0 backup/restore

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Qubes:
> However, when I use the Qubes backup tool it shows the size of the dom0
> backup is going to be 7.1 GB, but other than about 20 MB of screenshots in
> `/home/Pictures/` I don't have anything in `/home/`.

It's a bug in the GUI backup tool's size calculation for dom0:

https://github.com/QubesOS/qubes-issues/issues/5699#issuecomment-593500155

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmRkvh9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt/pkw//TWCjS5AQplGo2SbiNHjv1xb9vbN0+ffxZ8QDjKuiiVGB990r3oWr6n2b
uIPkDlmMGHOqrcQOm9tnDk2rkZ6avgCAJMo0KR7A9o+HFoPfkIBghwff6s91uV5A
d/hfVAF7Tk6iIB+43A2yWz4BK50loJ0CCWyjTkd7HYKou1KSnuqPISDSQ/RZ0Xo2
7dT0RZ2Ed8NsdGlqvGDAEmCR0ClX/nPs1vmOX5adSFOIRSPcmHybzZAE6FTzH1Pl
JhzugkHEGq77Beepup8we/idwRYr0AEUMCy/6IFo6rPKcG+mlnhS7rAj/nIyPZfk
fB/LJw5NzU4ATWXJa2TbE3R9fq05lsuiq0x0H18fdVNNhbk/dltrnh4iJ89TuxQ0
HV5TKrfhOxzJ0u0v5oJ/pDgyGGpYb5mQCRIZGnJZQcwgQvYFdhhohzC8MSfWPNWb
++zqIiUjdmmVxiNdHAJ6wSG0gL1NgRu4Hs45cQ4YGihspL0g+6x+c15kw0cigk0X
tG+IwGFLxR+A58NkOFXrVPH72bVYsUYkuBvjDazJZ/e5ISVgZMHwnLbUHvUpImLx
hvm74f3I+H4RBF9cng0wc9asO+mNvqAb9eV7DLUrWZDfbxs+W66bMucLbthY6+H0
6+f1bqwtTFNa5jWSrJdi3gnF7gdtIr9ISajf87zFAhCaVX1qwyY=
=77/E
-END PGP SIGNATURE-

-- 
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/ZGS9vplNIR1bBpW7%40mutt.

[qubes-users] dom0 backup/restore

[Qubes]

The documentation on [how to backup, restore and 
migrate](https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/) 
says,


"When backing up dom0 using the Qubes backup tool (explained below), 
only the home directory is backed up. Therefore, if there are files 
outside of the home directory you wish to save, you should copy them 
into the home directory prior to creating a backup."


However, when I use the Qubes backup tool it shows the size of the dom0 
backup is going to be 7.1 GB, but other than about 20 MB of screenshots 
in `/home/Pictures/` I don't have anything in `/home/`.


Why then does the Qubes backup tool report the dom0 backup is going to 
be 7.1 GB. What is it then backing up?


--
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/d75d54d9-cc15-4597-d77e-cd84c0223840%40ak47.co.za.

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

[Andrew David Wong]

Dear Qubes Community,

The [Xen Project](https://xenproject.org/) has released one or more [Xen 
security advisories (XSAs)](https://xenbits.xen.org/xsa/).
The security of Qubes OS *is not affected*.
Therefore, *no user action is required*.

## XSAs that DO affect the security of Qubes OS

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

- (none)

## XSAs that DO NOT affect the security of Qubes OS

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

- [XSA-431](https://xenbits.xen.org/xsa/advisory-431.html)
  - Qubes OS 4.1 uses an unaffected version of Xen (4.14).

## About this announcement

Qubes OS uses the [Xen 
hypervisor](https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as 
part of its [architecture](https://www.qubes-os.org/doc/architecture/). When 
the [Xen Project](https://xenproject.org/) publicly discloses a vulnerability 
in the Xen hypervisor, they issue a notice called a [Xen security advisory 
(XSA)](https://xenproject.org/developers/security-policy/). Vulnerabilities in 
the Xen hypervisor sometimes have security implications for Qubes OS. When they 
do, we issue a notice called a [Qubes security bulletin 
(QSB)](https://www.qubes-os.org/security/qsb/). (QSBs are also issued for 
non-Xen vulnerabilities.) However, QSBs can provide only *positive* 
confirmation that certain XSAs *do* affect the security of Qubes OS. QSBs 
cannot provide *negative* confirmation that other XSAs do *not* affect the 
security of Qubes OS. Therefore, we also maintain an [XSA 
tracker](https://www.qubes-os.org/security/xsa/), which is a comprehensive list 
of all XSAs publicly disclosed to date, including whether each one affects the 
security of Qubes OS. When new XSAs are published, we add them to the XSA 
tracker and publish a notice like this one in order to inform Qubes users that 
a new batch of XSAs has been released and whether each one affects the security 
of Qubes OS.


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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-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/034437ff-1944-fa19-76c9-fd4f673b509a%40qubes-os.org.

Re: [qubes-users] HCL- Purism-Librem_14

[Sven Semmler]

Thank you Antoine for your HCL report, which is 
[online](https://www.qubes-os.org/hcl/#purism_librem-14-v1_i7-10710u_integrated-graphics-uhd-620_antoine-luciani_r4-1)
 now!

/Sven

--
https://keys.openpgp.org/vks/v1/by-fingerprint/DA5975C9ABC40C833B2F620B2A632C537D744BC7

--
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/5d9d7bc7-8d6d-889e-d262-59f0d07b2012%40SvenSemmler.org.

[qubes-users] HCL- Purism-Librem_14

[Antoine Luciani]

Installation instructions :
Please note that I'm using HEADS and not a normal BIOS
1. Use ISO Qubes
2. In the Heads menu, go to USB boot
3. When booting to install, select “Install Qubes OS"
4. Finish installation and boot into OS

Remarks
The only issue I've encountered is the WiFi killswitch :
If you deactivate the wifi/bluetooth before booting, sys-net will have 
an issue and won't boot. It seems that it's because of Dom0 recheking 
each time the PCI device. If you re-enable the wifi and reboot the 
laptop the wifi will work again without problems


The important things work:

-Wifi
-Sound (Even though, you have to manually change from Speaker/headphone 
librem EC's fault, not QubesOS)

-HDMI
-USB
-Fedora 37
-Debian 11
-Whonix
-Gentoo Archlinux BlackArchlinux parrot kali Openbsd debian 12

Not tested:

-Bluetooth
-Microphone/Camera

--
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/8089615f-7ce9-b77e-c1f6-132096ea4fe0%40gmail.com.


Qubes-HCL-Purism-librem_14-20230514-182829.yml
Description: application/yaml

Re: [qubes-users] KDE on 4.1

[Qubes]

'unman' via qubes-users wrote:
On Tue, Jul 19, 2022 at 01:26:13PM +0200, Qubes wrote:

Qubes wrote:

'unman' via qubes-users wrote:

On Tue, Jul 19, 2022 at 08:41:40AM +0200, Qubes wrote:

The procedure to install KDE in 4.1 doesn't seem to work, is
that expected
behavior?


Yes, the group isn't present.
qubes-dom0-update kde-settings-qubes



Is this the way of installing KDE now which means the documentation must
be updated or is this just a workaround?



Also, would the correct procedure to remove KDE still be as per the
documentation,

"sudo dnf remove kdelibs plasma-workspace"

dnf remove kde-settings-qubes

The [documentation](https://www.qubes-os.org/doc/kde/) still shows the 
procedure for removing KDE as `sudo dnf remove kdelibs 
plasma-workspace`. Shouldn't this be updated to `sudo dnf remove 
kde-settings-qubes`?


--
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/6af6926f-6672-d77d-c2d8-9d9d85874810%40ak47.co.za.

Re: [qubes-users] Best practice VPN in Qubes

[Andrew David Wong]

On 5/13/23 7:33 AM, taran1s wrote:
> 
> 
> Demi Marie Obenour:
>> On Sat, May 13, 2023 at 10:57:00AM +, Qubes OS Users Mailing List wrote:
>>> Andrew David Wong:
 On 5/12/23 4:31 AM, 'taran1s' via qubes-users wrote:
> If anon-whonix AppVM is set to use mullvad-VPN that is connected to 
> sys-whonix it doesn't connect to internet. If one uses Debian or Fedora 
> based AppVM and runs vanilla Firefox, it works like a breeze.
>
> Any ideas how to solve this?
>

 I think that's by design. Whonix does that to protect you from 
 accidentally compromising your own privacy.
>>
> 
> The answer below was meant to you David. I misidentified Patrick as the 
> author of the answer.
> 

You can call me "Andrew." "David" is my middle name. :)

>>
>>> Thank you for the answer Patrick. It is possible. The question is how does
>>> one use VPN over Tor in this case with Torbrowser that doesn't compromise
>>> the privacy (see the use case below please).
>>> The use case is to connect to a service like Twitter that is not Tor
>>> friendly from a static non-tor IP address (VPN), but at the same time hide
>>> my real IP address from the VPN provider by using Tor before I connect to
>>> the VPN.
>>
>>> Some services, like Twitter even if they have onion site keep forcing me to
>>> reset password periodically, reminding me that there is a suspicious
>>> behavior (just by connecting from Tor, not even posting anything) in an
>>> endless loop.
>>
>>> I would like to use the anon-whonix-twitter AppVM Torbrowser specifically
>>> for connection to that particular account only and nothing else, no other
>>> apps or even websites ever used in that anon-whonix-twitter AppVM.
>>
>>> Do you have any advice how to enable Torbrowser in the anon-whonix-twitter
>>> to work in the VPN over Tor scenario?
>>
>> I would use the onion service and deal with the Twitter-side brokenness.
> 

You should read this, then decide whether you still think this setup would be a 
good idea for you:

https://www.whonix.org/wiki/Tunnels/Introduction

-- 
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/1780d3b7-c915-9a75-0a0a-fa01cf8a9aae%40qubes-os.org.

Re: [qubes-users] Best practice VPN in Qubes

['taran1s' via qubes-users]

Demi Marie Obenour:

On Sat, May 13, 2023 at 10:57:00AM +, Qubes OS Users Mailing List wrote:

Andrew David Wong:

On 5/12/23 4:31 AM, 'taran1s' via qubes-users wrote:

If anon-whonix AppVM is set to use mullvad-VPN that is connected to sys-whonix 
it doesn't connect to internet. If one uses Debian or Fedora based AppVM and 
runs vanilla Firefox, it works like a breeze.

Any ideas how to solve this?



I think that's by design. Whonix does that to protect you from accidentally 
compromising your own privacy.




The answer below was meant to you David. I misidentified Patrick as the 
author of the answer.





Thank you for the answer Patrick. It is possible. The question is how does
one use VPN over Tor in this case with Torbrowser that doesn't compromise
the privacy (see the use case below please).
The use case is to connect to a service like Twitter that is not Tor
friendly from a static non-tor IP address (VPN), but at the same time hide
my real IP address from the VPN provider by using Tor before I connect to
the VPN.



Some services, like Twitter even if they have onion site keep forcing me to
reset password periodically, reminding me that there is a suspicious
behavior (just by connecting from Tor, not even posting anything) in an
endless loop.



I would like to use the anon-whonix-twitter AppVM Torbrowser specifically
for connection to that particular account only and nothing else, no other
apps or even websites ever used in that anon-whonix-twitter AppVM.



Do you have any advice how to enable Torbrowser in the anon-whonix-twitter
to work in the VPN over Tor scenario?


I would use the onion service and deal with the Twitter-side brokenness.



So you would propose to drop the VPN entirely from the equation, use 
twitter's onion service and just use normal sys-whonix networking in the 
anon-whonix-twitter AppVM.


The issue I face is not much of a laziness to deal with the annoyance 
but with the requests for additional, looped identity checks like sms (I 
can deal with that from time to time, but not always), continuous 
password changes and similar craziness. They want to "protect me", omg. 
I have set the 2FA but still the same.


Funny part is that one even doesn't need to have any activity on the 
account that could be suspicious, because there is no activity at all. 
The issue is purely the fact of connection through their own onion 
service. Which would be funny if it wasn't sad.


Are there any significant drawbacks to use Torbrowser in the VPN over 
Tor scenario? Just in case they lock me out or something., for my 
protection of course.


--
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/e18aa56b-8ffe-b14d-e3df-9efec275d6f3%40mailbox.org.

[qubes-users] sys-gui

[Qubes]

When i installed `sys-gui` on my system the `SaltStack` formula 
downloaded and installed fedora-36-xfce. Do i need to do anything more 
than download the `fedora-37-xfce` template and switching the template 
for `sys-gui` to the new template?


--
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/58dbf781-0be6-aae5-75ca-6b9acd26a941%40ak47.co.za.

Re: [qubes-users] Best practice VPN in Qubes

[Demi Marie Obenour]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, May 13, 2023 at 10:57:00AM +, Qubes OS Users Mailing List wrote:
> Andrew David Wong:
> > On 5/12/23 4:31 AM, 'taran1s' via qubes-users wrote:
> > > If anon-whonix AppVM is set to use mullvad-VPN that is connected to 
> > > sys-whonix it doesn't connect to internet. If one uses Debian or Fedora 
> > > based AppVM and runs vanilla Firefox, it works like a breeze.
> > > 
> > > Any ideas how to solve this?
> > > 
> > 
> > I think that's by design. Whonix does that to protect you from accidentally 
> > compromising your own privacy.
> 
> 
> Thank you for the answer Patrick. It is possible. The question is how does
> one use VPN over Tor in this case with Torbrowser that doesn't compromise
> the privacy (see the use case below please).
> 
> The use case is to connect to a service like Twitter that is not Tor
> friendly from a static non-tor IP address (VPN), but at the same time hide
> my real IP address from the VPN provider by using Tor before I connect to
> the VPN.
> 
> Some services, like Twitter even if they have onion site keep forcing me to
> reset password periodically, reminding me that there is a suspicious
> behavior (just by connecting from Tor, not even posting anything) in an
> endless loop.
> 
> I would like to use the anon-whonix-twitter AppVM Torbrowser specifically
> for connection to that particular account only and nothing else, no other
> apps or even websites ever used in that anon-whonix-twitter AppVM.
> 
> Do you have any advice how to enable Torbrowser in the anon-whonix-twitter
> to work in the VPN over Tor scenario?

I would use the onion service and deal with the Twitter-side brokenness.
- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmRflBQACgkQsoi1X/+c
IsG/ohAAs0r584ZGCNUOAeJ6+ViAjTiN/PllOsErT5SRIrMqBbJH3anB6DKQMGE5
aW+Y4H4xzmQh449LYhz8yVfHlMb0551m6ROTGainEKSneVFafKkMCR5E2Yl+jde+
CRCLGFZVQ9MZlrhMuehPWJ0jZXxI0DGuamm0o65Cgi/qiGGSuZqs3B+ZWLHQA2ZN
vIYwSyiw2eG4bY5/dpofXFZeDuNY+qkkXEWzLa1Fm//J/iC+Q2AJLi4ap5w2dyOn
THNhSW+ouPowjXSuzASwD8P3P3s0h2/9Yma1PgkV8xwtn6ACS8oTtdoZp8iycd7a
yNOTNNEo0wGapSrLrUrZJCYttNTAEqwdyeyrUHv4/C1BQxOJQHzEXh6w/VDtepmD
lbZd6roSNBZ+wK8grcmq5nRUEFxTEu+/LkF0fSDTOEvbIwbaPYY572S/GQjJwK9N
7sJbFJgHDWGqEwalXKibPacRQ6WwO9I/E+xq6R+jktgBsEadnLkFNocFhxx6fqoz
oXe5RoJxHw/li/7KVBmliu01SHho2Zhosdhx/cDKT6l8TLphPZPOK9TbQ2nUzFwa
m6RaDpHpQecRqvJlRUz4FSEp9FjFjBEcW35n2DJKBaV2aWudB4C2ROPbfHbk2HiV
d6pgo30pyr3vx+QpAjXdmYP2XBLnnLoIIX726dK6vH3n5+JKCIU=
=X7Te
-END PGP SIGNATURE-

-- 
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/ZF%2BUEjd6huPK7Fu1%40itl-email.

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

[Demi Marie Obenour]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, May 11, 2023 at 11:00:41PM -0700, Vít Šesták wrote:
> If the process is not reused, just an update without restarting anything is 
> enough, isn't it? (This wouldn't be the case if the process was forking 
> from a zygote.)

The process forks for each request, so one will need to kill all
currently-running qrexec-daemon processes to be protected from this
vulnerability.  The simplest way to do this is to reboot all domUs.
- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmRffrwACgkQsoi1X/+c
IsE+aBAAyAIS9c03+E6KQJAuKBwoa02szKGHbqUHHUtUCX1t961jXCq8Li/MC14e
qEUBrZdniIgvcszPLJ4SDH1nIVCovimUu4a1Z+gN/ofvTrxcAH+kSzxth30aIIuE
foh4LGFEZLZVng72X002917lDquw0hs0BaMBKzP/JhKAAlpkDIivEbCn7vOvztET
hSCRK4mBhfur1gSogkPF69vJnOfoq4FFz2GIsBaWfDF6j0hfmddUbk+mU2f5ooH/
mg7AUFCfltR7GO7swHksFX+S7p+tI/L6VfoxARFjarHZ4f4PYEEXrV/LQXusL60x
/oPDOap8AlmPksjC/OITLRCV11jACjeQCIUX2r9pE8KioXmElrNsKKKMAKjf6FSr
fy3ylxX3o1cdX1DhHDpbVtv8GM/6nXPfSDg2sbF3AmMTHh1kfOx5GWp32F+BBL3a
pI3AuJbXMirrXRVNIDRsdxQ8v+TwEK0jRaI5Z/IbL2kClMODgwBHuZZ8l1xFTFXG
xVfWbrbLvhJC9qupoWTKJKIyjmlisF9Q8vQZm2KURgQ0/qO5oesGf8X+XdkynCqO
VTjZvxN/UpvAmxvbQB9YxCwO6hAhvdPLNz70uE8C8PDiMWS3VM2iAAoRLSb7CqTz
kmkAXkC4M7Y9wKthgY20I4ZFOc2dvvdoV5uXPMG75La0lOQoG0A=
=dX/W
-END PGP SIGNATURE-

-- 
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/ZF9%2BugKzSKnf6Ah%2B%40itl-email.

Re: [qubes-users] Best practice VPN in Qubes

['taran1s' via qubes-users]

Andrew David Wong:

On 5/12/23 4:31 AM, 'taran1s' via qubes-users wrote:

If anon-whonix AppVM is set to use mullvad-VPN that is connected to sys-whonix 
it doesn't connect to internet. If one uses Debian or Fedora based AppVM and 
runs vanilla Firefox, it works like a breeze.

Any ideas how to solve this?



I think that's by design. Whonix does that to protect you from accidentally 
compromising your own privacy.



Thank you for the answer Patrick. It is possible. The question is how 
does one use VPN over Tor in this case with Torbrowser that doesn't 
compromise the privacy (see the use case below please).


The use case is to connect to a service like Twitter that is not Tor 
friendly from a static non-tor IP address (VPN), but at the same time 
hide my real IP address from the VPN provider by using Tor before I 
connect to the VPN.


Some services, like Twitter even if they have onion site keep forcing me 
to reset password periodically, reminding me that there is a suspicious 
behavior (just by connecting from Tor, not even posting anything) in an 
endless loop.


I would like to use the anon-whonix-twitter AppVM Torbrowser 
specifically for connection to that particular account only and nothing 
else, no other apps or even websites ever used in that 
anon-whonix-twitter AppVM.


Do you have any advice how to enable Torbrowser in the 
anon-whonix-twitter to work in the VPN over Tor scenario?



--
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/5dfa9007-6f21-3032-a1e1-395f719d0457%40mailbox.org.

Re: [qubes-users] Global value for the paramater "revisions_to_keep"

[roger paranoia]

Hello

Thanks Thomas! That was of big help :D
I haven't checked if that works retroactively... anyway though, to rapidly
free some memory up and recover the system I just deleted all revisions
with "lvremove /dev/qubes/dom0/*-back" (responding myself to the second
question on my previous mail).


El vie, 12 may 2023 a las 22:34, Thomas Clarke ()
escribió:

> Hi,
>
> You can list your pools with `qvm-pool`. And list options for a pool with
> (where my pool is pool00) `qvm-pool info pool00`. Then you can set
> `revisions_to_keep` for a pool like `qvm-pool set -o revisions_to_keep=0
> pool00`.
>
> I'm not sure if this will work retroactively on already created volumes,
> but should be applied to all new ones going forward.
>
> On 12/05/2023 18:28, roger paranoia wrote:
> > Hello
> >
> > I had a hard time cause I didn't notice the pool memory was running out
> of space because of the accumulation of snapshot revisions.
> >
> > I actually don't need 2 snapshots for most of my qubes and I've been
> wondering if it's possible to set a global value so those qubes don't fill
> up my disk with "garbage" but I haven't found anything neither at the
> corresponding wiki ( https://www.qubes-os.org/doc/volume-backup-revert/ <
> https://www.qubes-os.org/doc/volume-backup-revert/>) nor any other
> relevant result on google.
> >
> > It also would be useful to know if there is a fast way to just delete
> all revisions all at once without affecting the main qube.
> >
> >
> > Thanks in advance for any help
> >
> > --
> > 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  qubes-users+unsubscr...@googlegroups.com>.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/CANyf1MJnZK5Qtwj5UOCRN8jaPLEHd-ft2_igxrx5dAq99cw0-A%40mail.gmail.com
> <
> https://groups.google.com/d/msgid/qubes-users/CANyf1MJnZK5Qtwj5UOCRN8jaPLEHd-ft2_igxrx5dAq99cw0-A%40mail.gmail.com?utm_medium=email_source=footer
> >.
>
> --
> 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/a47a277a-3779-337a-fdf3-adf3c2172616%40riseup.net
> .
>

-- 
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/CANyf1M%2BnMPN8nmSQcVq3emJo28%3D9V10XkcL3-fYDNWs1TRY7nQ%40mail.gmail.com.

Re: [qubes-users] Best practice VPN in Qubes

[Andrew David Wong]

On 5/12/23 4:31 AM, 'taran1s' via qubes-users wrote:
> If anon-whonix AppVM is set to use mullvad-VPN that is connected to 
> sys-whonix it doesn't connect to internet. If one uses Debian or Fedora based 
> AppVM and runs vanilla Firefox, it works like a breeze.
> 
> Any ideas how to solve this?
> 

I think that's by design. Whonix does that to protect you from accidentally 
compromising your own privacy.

-- 
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/1855e2e4-f9f2-7c37-735b-f6a36e112533%40qubes-os.org.