[qubes-users] whonix update issues (The certificate is NOT trusted. The received OCSP status response is invalid.)

[Ulrich Windl]

Hi!

When trying to update whonix-gateway-17 and whonix-workstation-17, both 
fail with a message like this:


Updating whonix-gateway-17
Refreshing package info
Refreshing packages.
Fail to refresh InRelease: tor+https://deb.whonix.org bookworm InRelease 
from tor+https://deb.whonix.org/dists/bookworm/InRelease
Fail to refresh InRelease: tor+https://deb.whonix.org bookworm InRelease 
from tor+https://deb.whonix.org/dists/bookworm/InRelease
Fail to refresh InRelease: tor+https://deb.whonix.org bookworm InRelease 
from tor+https://deb.whonix.org/dists/bookworm/InRelease
Fail to refresh InRelease: tor+https://deb.whonix.org bookworm InRelease 
from tor+https://deb.whonix.org/dists/bookworm/InRelease

Refreshed.
E:Failed to fetch tor+https://deb.whonix.org/dists/bookworm/InRelease  
Certificate verification failed: The certificate is NOT trusted. The 
received OCSP status response is invalid.  Could not handshake: Error in 
the certificate verification. [IP: 127.0.0.1 8082], E:Some index files 
failed to download. They have been ignored, or old ones used instead.



What's wrong? Did some site stupidly turn off OCSP?

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/679f5ea6-f30c-4af5-a3bf-97b905855c10%40gmail.com.

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

[Andrew David Wong]

Dear Qubes Community,

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

## XSAs that DO affect the security of Qubes OS

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

- (none)

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

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

- [XSA-457](https://xenbits.xen.org/xsa/advisory-457.html)
  - Denial of service (DoS) only

## About this announcement

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-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/4c0c9522-7f24-489d-88cc-2aa807a01699%40qubes-os.org.

Re: [qubes-users] Microphone disabled in firmware is showing in Qubes

[alesser]

qubist:

The question probably comes down to: Does disabling the microphone make
it invisible or just dysfunctional? Have you researched that?



Disabled devices (like data transfer port) are normally invisible, but 
perhaps for microphone it is different. I will research.


--
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/104d906f-c502-4191-b414-fa66ba47470c%40magenta.de.

Re: [qubes-users] Where to run undervolt script?

[alesser]

qubist:

PVM domUs have no direct access to hardware, so perhaps you won't be
able to undervolt your CPU in a domU. Running it in dom0 seems the only
option, however that is also the most dangerous one.


Ok, so dom0 is only way. I will think about risk of installing here.


Downloading arbitrary software from the web and running it in dom0 is
highly NOT recommended


It is available from pip install command so is not so arbitrary. And is 
only a short python script which you can read, is not very hard to 
examine. But again I will consider risk before putting into dom0.


> The software itself comes with a warning. So...

you have been warned.


The warning is only for protecting the hardware, not for warning against 
malicious software. i have been used the software before on same machine 
with Ubuntu for many months so it is safe with this hardware, this I am 
sure.


Thank you for giving me an answer, I can make progress on this now.

--
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/9daabd01-c084-4b82-be85-5e8b1d80bb53%40magenta.de.

Re: [qubes-users] xdg-open works in dvm, but qvm-open-in-dvm from other qube does not

['justanotherquber' via qubes-users]

On Thu, May 02, 2024 at 02:44:09PM -, qubist wrote:
> That's secondary, but in case you are interested, mpv gives better playback:
> 
> https://forum.qubes-os.org/t/improving-video-playback-speed/21906/8
It does not seem to play back better to me, as well at most, especially not 
with the aggressive frame-dropping that is turned on by default.
It's even more aggressive than setting framedropping to hard on mplayer.
I decided to use --framedrop=no to have it get more out of sync instead. 
Thank you for the suggestion though, I might decide to switch to mpv. 

-- 
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/20240502163707.GC1058%40mail2-dvm.

Re: [qubes-users] xdg-open works in dvm, but qvm-open-in-dvm from other qube does not

[qubist]

That's secondary, but in case you are interested, mpv gives better playback:

https://forum.qubes-os.org/t/improving-video-playback-speed/21906/8

-- 
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/20240502144409.3933f3b6%40localhost.

Re: [qubes-users] xdg-open works in dvm, but qvm-open-in-dvm from other qube does not

['justanotherquber' via qubes-users]

I also tried an untouched version of debian 12 minimal with updates and only 
mplayer added from apt.
There was no mimeapps.list file in /usr/share/applications, /etc/xdg/, 
$HOME/.config or $HOME/.local/share/applications.
I tried xdg-mime default mplayer.desktop video/x-matroska as the non-root user.
Still didn't work. Maybe because there wasn't a mplayer.desktop file in 
/usr/share/applications like in fedora.
I copy over mplayer.desktop without a MimeType field from the original debian 
12 miminal media qube and move it to $HOME/.local/share/applications.
This gives the same error as the original media qube.
I add MimeType=video/x-matroska to the desktop file and re-run the xdg-mime 
command.
I still get the same error.

-- 
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/20240502144133.GB1058%40mail2-dvm.

Re: [qubes-users] xdg-open works in dvm, but qvm-open-in-dvm from other qube does not

['justanotherquber' via qubes-users]

> Trying to copy the file first and then 'xdg-open TEST.pdf' in the
> target VM, I get the same series of errors:
> 
> $ xdg-open TEST.pdf 
> xdg-mime: mimetype argument missing
> Try 'xdg-mime --help' for more information.
> /usr/bin/xdg-open: 882: x-www-browser: not found
> /usr/bin/xdg-open: 882: firefox: not found
> /usr/bin/xdg-open: 882: iceweasel: not found
> /usr/bin/xdg-open: 882: seamonkey: not found
> /usr/bin/xdg-open: 882: mozilla: not found
> /usr/bin/xdg-open: 882: epiphany: not found
> /usr/bin/xdg-open: 882: konqueror: not found
> /usr/bin/xdg-open: 882: chromium: not found
> /usr/bin/xdg-open: 882: chromium-browser: not found
> /usr/bin/xdg-open: 882: google-chrome: not found
> /usr/bin/xdg-open: 882: www-browser: not found
> /usr/bin/xdg-open: 882: links2: not found
> /usr/bin/xdg-open: 882: elinks: not found
> /usr/bin/xdg-open: 882: links: not found
> /usr/bin/xdg-open: 882: lynx: not found
> /usr/bin/xdg-open: 882: w3m: not found
> xdg-open: no method available for opening 'TEST.pdf'
> 
> Then I tried this:
> 
> https://unix.stackexchange.com/a/59088
> 
> but it changed nothing. Tested with an mp4 file - same result.
> 
I did get xdg-open itself to work. Although all the different files and tools 
confused me a lot.
I added the lines to mimeapps.list directly, although I think xdg-mime default 
alone worked for me too.
I added a [Added Associations] line with the same entries as [Default 
Applications].
Not really sure what this does though.
The mimeapps.list file I use is in /etc/xdg/ (global), so I set it from the 
template. 
Sometimes I've had to add a MimeType field (something like 
MimeType=video/mp4;video/x-matroska;video/webm) to the .desktop file being 
used, before running xdg-mime, to get it to work.
> And there it is: xdg-open wrongly detects gnome3 which is not
> installed. Then I checked:
> 
> $ printenv | grep XDG_CURRENT_DESKTOP
> XDG_CURRENT_DESKTOP=X-QUBES ## NOT XFCE, which is the correct value
XDG_CURRENT_DESKTOP isn't even set for me, I use i3 though
> 
> After:
> 
> $ export XDG_CURRENT_DESKTOP=XFCE
I added export XDG_CURRENT_DESKTOP=XFCE to my template, shut it down and ran 
qvm-open-in-dvm to open a file in it.
> 
> xdg-open works as expected in the current session.
> 
It started and shut down. I get the same error in journalctl on qvm-open-in-dvm.
> To have "Open in VM" work as well, obviously the above must be set
> persistently.
> 
> Speculation 1 (needs checking and confirmation):
> 
> Since I see in a fedora-xfce-template-based qubes the
> XDG_CURRENT_DESKTOP=XFCE, I suppose it is somehow set when XFCE itself
> is installed (and not just thunar), so perhaps the fact of the Debian
> template being "-minimal" (and not "-xfce") is related to this issue
> and one needs to set this thing manually to make it work properly.
> 
> Speculation 2 (if the above is wrong):
> 
> It might be Debian specific.
I downloaded Fedora 39 minimal, it didn't have mplayer, so I tried updating and 
installing only kmplayer.
It seems to install a lot of plasma, Qt stuff, about 200MB in total.
After installing kmplayer it qvm-open-in-dvm didn't work.
With journalctl in the fedora based vm it shows the same failed to connect to 
bus error as debian started with.
After that it seems to just give an mime error, like the one you showed earlier.
cat /usr/share/applications/mimeapps.list shows org.gnome.Totem as the default 
application.
XDG_CURRENT_DESKTOP was set to X-QUBES, as with you.
I copied mimeapps.list to /etc/xdg/ in the template and replaced

-- 
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/20240502143625.GA1058%40mail2-dvm.

Re: [qubes-users] xdg-open works in dvm, but qvm-open-in-dvm from other qube does not

[qubist]

On Wed, 1 May 2024 11:15:42 +0200 'justanotherquber' via qubes-users wrote:

> Hi, I've been trying to get a dvm to open media files in mplayer in a
> disposable qube. Starting the disposable media qube from dom0 with
> qvm-run --dispvm media-dvm --service -- qubes.StartApp+st works.
> Copying files(same as the ones used to test
> qvm-open-in-vm/qvm-open-in-dvm) to the vm with qvm-copy works.
> Opening the copied files with xdg-open or qubes-open works in the
> dvm. Opening media files in mplayer in the disposable qube with
> qvm-open-in-dvm used to work.

Same here.

> It stopped working after I switched the media qube's template from
> debian-11-minimal to debian-12-minimal.

I am not sure if that per se is the reason. It used to work for me in
debian-12-minimal too.

Here is what I get when I "Open in VM" a text file (VM is based on
debian-12-minimal with thunar, xpdf and mpv installed).

[  277.623816] systemctl[1176]: Failed to connect to bus: No medium found
[  277.649127] qubes.OpenInVM+-storage[1187]: xdg-mime: mimetype argument 
missing
[  277.649430] qubes.OpenInVM+-storage[1187]: Try 'xdg-mime --help' for more 
information.
[  277.678605] qubes.OpenInVM+-storage[1187]: /usr/bin/xdg-open: 882: 
x-www-browser: not found
[  277.679554] qubes.OpenInVM+-storage[1187]: /usr/bin/xdg-open: 882: firefox: 
not found
[  277.680597] qubes.OpenInVM+-storage[1187]: /usr/bin/xdg-open: 882: 
iceweasel: not found
[  277.681603] qubes.OpenInVM+-storage[1187]: /usr/bin/xdg-open: 882: 
seamonkey: not found
[  277.682573] qubes.OpenInVM+-storage[1187]: /usr/bin/xdg-open: 882: mozilla: 
not found
[  277.683527] qubes.OpenInVM+-storage[1187]: /usr/bin/xdg-open: 882: epiphany: 
not found
[  277.684437] qubes.OpenInVM+-storage[1187]: /usr/bin/xdg-open: 882: 
konqueror: not found
[  277.685364] qubes.OpenInVM+-storage[1187]: /usr/bin/xdg-open: 882: chromium: 
not found
[  277.686320] qubes.OpenInVM+-storage[1187]: /usr/bin/xdg-open: 882: 
chromium-browser: not found
[  277.687446] qubes.OpenInVM+-storage[1187]: /usr/bin/xdg-open: 882: 
google-chrome: not found
[  277.688471] qubes.OpenInVM+-storage[1187]: /usr/bin/xdg-open: 882: 
www-browser: not found
[  277.689353] qubes.OpenInVM+-storage[1187]: /usr/bin/xdg-open: 882: links2: 
not found
[  277.690593] qubes.OpenInVM+-storage[1187]: /usr/bin/xdg-open: 882: elinks: 
not found
[  277.691631] qubes.OpenInVM+-storage[1187]: /usr/bin/xdg-open: 882: links: 
not found
[  277.692557] qubes.OpenInVM+-storage[1187]: /usr/bin/xdg-open: 882: lynx: not 
found
[  277.693781] qubes.OpenInVM+-storage[1187]: /usr/bin/xdg-open: 882: w3m: not 
found
[  277.693832] qubes.OpenInVM+-storage[1187]: xdg-open: no method available for 
opening '/tmp/storage-LVDbTK/TEST.pdf'

Trying to copy the file first and then 'xdg-open TEST.pdf' in the
target VM, I get the same series of errors:

$ xdg-open TEST.pdf 
xdg-mime: mimetype argument missing
Try 'xdg-mime --help' for more information.
/usr/bin/xdg-open: 882: x-www-browser: not found
/usr/bin/xdg-open: 882: firefox: not found
/usr/bin/xdg-open: 882: iceweasel: not found
/usr/bin/xdg-open: 882: seamonkey: not found
/usr/bin/xdg-open: 882: mozilla: not found
/usr/bin/xdg-open: 882: epiphany: not found
/usr/bin/xdg-open: 882: konqueror: not found
/usr/bin/xdg-open: 882: chromium: not found
/usr/bin/xdg-open: 882: chromium-browser: not found
/usr/bin/xdg-open: 882: google-chrome: not found
/usr/bin/xdg-open: 882: www-browser: not found
/usr/bin/xdg-open: 882: links2: not found
/usr/bin/xdg-open: 882: elinks: not found
/usr/bin/xdg-open: 882: links: not found
/usr/bin/xdg-open: 882: lynx: not found
/usr/bin/xdg-open: 882: w3m: not found
xdg-open: no method available for opening 'TEST.pdf'

Then I tried this:

https://unix.stackexchange.com/a/59088

but it changed nothing. Tested with an mp4 file - same result.

I can open the files through thunar, where I can set default app for
the type too. However, thunar does not use xdg-open but exo-open.

Next, I looked at the code of xdg-open (it is a shell script) and I saw
it used some form of desktop environment (DE) detection and acted based
on that.

So, to see what exactly happens:

$ bash -x xdg-open TEST.pdf
...
+ DEBUG 2 'Selected DE gnome3'
...
+ open_gnome3 TEST.pdf
+ gio help open
+ gvfs-open --help
+ open_generic TEST.pdf
...

And there it is: xdg-open wrongly detects gnome3 which is not
installed. Then I checked:

$ printenv | grep XDG_CURRENT_DESKTOP
XDG_CURRENT_DESKTOP=X-QUBES ## NOT XFCE, which is the correct value

After:

$ export XDG_CURRENT_DESKTOP=XFCE

xdg-open works as expected in the current session.

To have "Open in VM" work as well, obviously the above must be set
persistently.

Speculation 1 (needs checking and confirmation):

Since I see in a fedora-xfce-template-based qubes the
XDG_CURRENT_DESKTOP=XFCE, I suppose it is somehow set when XFCE itself
is installed (and not just thunar), so perhaps the fact of the Debian
template being "-minimal" (and not "-xfce") is related to this 

[qubes-users] xdg-open works in dvm, but qvm-open-in-dvm from other qube does not

['justanotherquber' via qubes-users]

Hi, I've been trying to get a dvm to open media files in mplayer in a 
disposable qube.
Starting the disposable media qube from dom0 with qvm-run --dispvm media-dvm 
--service -- qubes.StartApp+st works.
Copying files(same as the ones used to test qvm-open-in-vm/qvm-open-in-dvm) to 
the vm with qvm-copy works.
Opening the copied files with xdg-open or qubes-open works in the dvm.
Opening media files in mplayer in the disposable qube with qvm-open-in-dvm used 
to work. 
It stopped working after I switched the media qube's template from 
debian-11-minimal to debian-12-minimal.
I used qubesctl with state.highstate to get the new template to be in the same 
state as the previous template.
I checked journalctl -f in the media dvm while running qvm-open-in-vm from the 
vm that usually calls qvm-open-in-dvm.
The media dvm consistently gives the same errors:
May 01 10:04:54 disp7040 systemctl[914]: Failed to connect to bus: No medium 
found
May 01 10:04:56 disp7040 qubes.OpenInVM+-browse-disp[925]: cat: write error: 
Bad file descriptor
May 01 10:04:56 disp7040 qubes.OpenInVM+-browse-disp[925]: 
May 01 10:04:56 disp7040 qubes.OpenInVM+-browse-disp[925]: 
May 01 10:04:56 disp7040 qubes.OpenInVM+-browse-disp[925]: MPlayer interrupted 
by signal 13 in module: unknown
This is was using a mplayer binary I built myself.
If I use remove that and let it use a version from apt I get a sligthly 
different set of errors:
May 01 10:26:46 disp7040 systemctl[1234]: Failed to connect to bus: No medium 
found
May 01 10:26:48 disp7040 qubes.OpenInVM+-browse-disp[1246]: cat: write error: 
Bad file descriptor
May 01 10:26:48 disp7040 qubes.OpenInVM+-browse-disp[1246]: do_connect: could 
not connect to socket
May 01 10:26:48 disp7040 qubes.OpenInVM+-browse-disp[1246]: connect: No such 
file or directory
May 01 10:26:48 disp7040 qubes.OpenInVM+-browse-disp[1246]: Failed to open LIRC 
support. You will not be able to use your remote control.
May 01 10:26:48 disp7040 qubes.OpenInVM+-browse-disp[1246]: 
May 01 10:26:48 disp7040 qubes.OpenInVM+-browse-disp[1246]: 
May 01 10:26:48 disp7040 qubes.OpenInVM+-browse-disp[1246]: MPlayer interrupted 
by signal 13 in module: unknown
The vm that calls qvm-open-in-dvm can successfully open media files in other 
vms.
Thanks in advance for any ideas you might have.

-- 
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/20240501090352.GA930%40mail2-dvm.

Re: [qubes-users] Some bugs I found?

[Andrew David Wong]

On 4/27/24 7:39 AM, ales...@magenta.de wrote:
> one bug: man page for qube-dom0-update refers to yum instead of dnf.
> 
> another bug: system went to sleep / suspend when it was in the middle of 
> downloading updates with Qubes Update command. Not good. I have to myself 
> disable suspend in settings until it is finished.
> 
> last bug: many of my qubes are staying on 60% CPU use when they are idle. 
> This seems to be happening when they are not running any application, so 
> after they are launched at login and after I close the last application. I 
> can fix it if I restart the qube or run an app from it. But this kills my 
> battery.
> 
> First one must be for all but perhaps last two are just for me?
> 

Please see this page, which explains how to report bugs:

https://www.qubes-os.org/doc/issue-tracking/

-- 
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/d503fda7-e065-4aee-ae81-0a6818625748%40qubes-os.org.

Re: [qubes-users] Microphone disabled in firmware is showing in Qubes

[qubist]

The question probably comes down to: Does disabling the microphone make
it invisible or just dysfunctional? Have you researched that?

-- 
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/20240427163230.279efbe5%40localhost.

Re: [qubes-users] Where to run undervolt script?

[qubist]

On Sat, 27 Apr 2024 14:30:00 + ales...@magenta.de wrote:

> I still need to know what is best way for undervolt.py to run.

There is no best way to run potentially dangerous software.

> For best way I mean for security and without making more performance
> hit like maybe running a new qube.
> 
> Can someone give advice?

PVM domUs have no direct access to hardware, so perhaps you won't be
able to undervolt your CPU in a domU. Running it in dom0 seems the only
option, however that is also the most dangerous one.

Downloading arbitrary software from the web and running it in dom0 is
highly NOT recommended. The software itself comes with a warning. So...
you have been warned.

-- 
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/20240427163002.18ccb48f%40localhost.

[qubes-users] Some bugs I found?

[alesser]

one bug: man page for qube-dom0-update refers to yum instead of dnf.

another bug: system went to sleep / suspend when it was in the middle of 
downloading updates with Qubes Update command. Not good. I have to 
myself disable suspend in settings until it is finished.


last bug: many of my qubes are staying on 60% CPU use when they are 
idle. This seems to be happening when they are not running any 
application, so after they are launched at login and after I close the 
last application. I can fix it if I restart the qube or run an app from 
it. But this kills my battery.


First one must be for all but perhaps last two are just for 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/7e3a3675-ee97-46a3-bee5-8940b289e926%40magenta.de.

Re: [qubes-users] Where to run undervolt script?

[alesser]

ales...@magenta.de:

What is the safest way to use undervolt script in Qubes?

https://github.com/georgewhewell/undervolt.git

This is running on Python. Is it better to use new service qube for this 
or can I run it in dom0/sys-net/sys-firewall?


I still need to know what is best way for undervolt.py to run. For best 
way I mean for security and without making more performance hit like 
maybe running a new qube.


Can someone give advice?

--
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/bd0e5de4-933b-4363-b2c9-3d07f053b44e%40magenta.de.

[qubes-users] Microphone disabled in firmware is showing in Qubes

[alesser]

I have just seen that there is a microphone device listed in the devices 
menu.


I have already disabled built in microphone with firmware setting and 
this doesn't shown in Ubuntu but is shown in Qubes. This laptop doesn't 
have another microphone device.


How can Qubes see this device?

--
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/1c88cf1a-e5c5-4611-8792-3ac254a9298c%40magenta.de.

Re: [qubes-users] Ethernet socket device not available in Network Connections

[alesser]

'unman' via qubes-users:

Have you assigned the device to sys-net in the "devices" tab of sys-net
settings.


I didn't know I had to do this. Now is fixed, thank you.

--
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/46cde13e-cd0f-4e0b-a350-a7e93397d6f0%40magenta.de.

[qubes-users] NFC and other creative communications with your qubes-os

['haaber' via qubes-users]

I have a simple question, around "things that you have" (like sec.
tokens, etc).

Many "fido tokens" (yubi, nitro, google) allow NFC communication, most 
computers as well, but i do not find anything in my qubes (maybe the
chips acts as USB client and my USB is down by default?)

=> Is there a solution to that? I am pretty sure I am not the first one
to meditate that question ...


Another, more creative idea could be to use the build-in fingerprint
scanner but feed it artificial "precalculated random fingerprints". 
They could work  as a second password that you have printed put on a
plastic card (using standard, "fingerprint forgery" ideas, i.e. via a
laser printer in a positive way) and carry it with you; They might even
use as one-time-tokens, if you precalulate a bunch of them :)

=> did someone ever hear of such ideas?


thanks, 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/044ed16e-67cc-4b1c-a4bc-9ab2b4641082%40web.de.

Re: [qubes-users] 'locking' a vm possible? (to prevent accidental shutdown)

[Boryeu Mao]

Thank you very much for the help.  Time for a crash course on
qubes-core-admin.

On Mon, Apr 15, 2024 at 9:30 AM Rusty Bird  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Rusty Bird:
> > Boryeu Mao:
> > > An attempt to shutdown `sys-firewall` in `Qube Manager` receive a
> warning
> > > about running processes in the qube; similarly on command line
> > > `qvm-shutdown sys-firewall` fails with an error.  Is it possible to
> > > designate an appVM to behave similarly so it won't get shutdown
> > > accidentally?
> >
> > Not as a user-facing feature AFAIK. But you could use the qubes.ext
> > Python entry point
> >
> >
> https://github.com/QubesOS/qubes-core-admin/blob/v4.2.21/qubes/ext/__init__.py#L57-L59
> >
> > to add another "domain-pre-shutdown" event handler like this one
> > (yours could e.g. check if the VM has a certain tag):
> >
> >
> https://github.com/QubesOS/qubes-core-admin/blob/v4.2.21/qubes/ext/audio.py#L65-L75
>
> Sorry, that second link should have been:
>
>
> https://github.com/QubesOS/qubes-core-admin/blob/v4.2.21/qubes/ext/audio.py#L31-L38
>
> Rusty
> -BEGIN PGP SIGNATURE-
>
> iQKTBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmYdQPRfFIAALgAo
> aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
> QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
> Kt9fGw/+JHmmCw+Ly/YXJ5uYJknlH/Z8hpViEwPnIGuuz7dkiHYa53BeKg+ub035
> EOt0Z2ir8NuhHGXdN77A4j1PA6gXypEBme3sxDoP0uHv1Tc3GSAgbR4NzF0qucxy
> EQisGL7LAw05raT5vFv8eWsHwfR1OHAupXZKJzHfjX3CBUce51K2N/eyPiuoX4es
> m/1lpLmLWJgXAk2MgvwNop4coRiexLuXGWYpeG+64SrDmB0oJhFZ+8rhUig5UZ41
> ImpkZl+cbFIxVL+j0tcWLlaDt8yTIJzR2lw0afOvHZcqNHlNo2OPSm4HiMfrThVP
> 9oAAU5fvTLQtnVJ0Qw49/wm6nr2IFuR3J3Zkz4PA0jVzxuXL6OGzjLuJuFlj01Sj
> qxK3oU9dsN2cXCkp0k8gq39UAyHZwaeViFnAxKNm/U/ykRlFhLiloTF3ZvJYl7Vv
> 1N54BKKY5RjjtVsBgbDfKVcfSR4UwNt6v2PECfp+l7SpJb4XFiCNb9AoU2UoPQjj
> icOPXw8r7AAMZdm+ANuMhTivGIi+7HR4MQ4xKRmD1bJ1qhQPGyuq+6loYJQQX+r4
> 1evr5+hCbQjapWN5IA7mRSgzaUEPC0Yrc5Ttirw81dbuCIPyv+B2c8LwQDvcorIR
> A5EhArjwq1nY1N1ArMUKVf5+ONcIu7K56fjnMxyZXer3zExcYyA=
> =mP8j
> -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/CAOBBCnbBeizsTM9GfvMTc7S7TBUSzpE2KMs4zcvv_wCQ%2BqX8qA%40mail.gmail.com.

Re: [qubes-users] Re: Qubes 4.2 installation problems due to Salt alone - what to do?

[Michael Singer]

Thank you! The hardware clock had the wrong date. Therefore the error with salt.


Hmm,  You might find it more useful to join the Qubes Forum,

https://forum.qubes-os.org/

I wanted to reply, so you felt someone will help.

Perhaps Clarify some things.

Seems from your discussion of SALT, you know something of Linux.

If the standard install did not finish correctly.  I am not thinking
whatever is going on with SALT is the problem.  But SALT commands might
reveal to some what is happening?
So, for me in your situation, I would go through the detail of what I
assumed was true, but might not be.

Can you clarify.
Why are you sure the computer in question is compaitble with Qubes?  Have
you used Qubes on it before?
Did you install UEFI or Legacy?   I use Legacy, UEFI is a different set of
problems.
Does your computer have one or two drives?  (I have one computer, with two
drives, that will only let me install Qubes to one drive, and the other
drive must not have anything on it.  Other computers don't care.  and I did
not say it made sense)
Are you trying to accomplish a dual boot?  (Qubes wants to be alone on the
drive.   Some folks have gotten dual boot to work.  I have not tried)

Did you try to install Qubes on a drive that already had -something?
(I have discovered that sometimes Qubes does not like to installed over
something else.  Sometimes does not care.)

Can  you devote this computer to using Qubes right now?   Or is it a
computer you use daily with another OS?
(helps to limit suggestions to something that is more reasonable for you to
try)

I think someone more knowledgeable than myself will come by and recognize
your symptoms, and you don't have to worry about answering this.  But it
can't hurt.

In a coupla days, If you have not gotten it going, I will come back and add
more suggetions.   More confusion.

but someone might recognize symptoms and make an easier fix.

Cheers.


On Sunday, April 14, 2024 at 12:58:26 PM UTC-4 Michael Singer wrote:


Dear Qubes Community,

I am trying to install Qubes 4.2. in vain, not because the hardware is
incompatible, but because of Salt problems. I verified the downloaded ISO
according to the instructions, burned the ISO with various programs on a
USB stick, among others with the DD command:


dd if="./Qubes-R4.2.1-x86_64.iso" of="/dev/sda" status="progress"

conv="fsync"

I have checked the result and it shows that the hash sum of the USB stick
under /dev/sda is the same as the downloaded file:


sudo dd if=/dev/sda bs=1M count=$(stat -c %s

/home/user/QubesIncoming/XXX/Qubes-R4.2.1-x86_64.iso) iflag=count_bytes |
sha256sum

a942911a3a4975831324a064f70b34c6965c4e9f6c95afbc531f04d55f947376


When I start the computer with the USB stick and test the medium, the
following appears first:


Fragment sums: 2695f8d1(...)
supported iso: no


Then, when the test has run 100 percent, the following appears:


[FAILED]


If I install anyway, I have to cancel the automatic creation of sys-net,
sys-usb and personal AppVMs, because otherwise I get an installation error
because the installer does not set the PCI devices to disable strict reset.
At the end of the setup it still says:


"initial config failed", see /var/log/salt/minion


The log there says:


Specified ext_pillar interface qvm_prefs unavailable


And when I try to update dom0, it fails. The reason is noted in the same
log file:


Unable to detect release version
Cannot prepare internal mirror list: SSL peer certificate or SSH remote

key was not OK for https://mirrors.fedora(...)

Everything otherwise works according to the HCL report, including Suspend,
Ethernet, USB, Speaker. Strange thing was that no default-mgmt-dvm seemed
to be present and was not started during update attempts.

I have already tried the installation with 4.2.0 and 4.2.1, with standard
kernel and with the latest kernel.

How could I solve the problem?

Thank you,
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/04644821-831b-4657-990d-84ab2c56309f%40posteo.de.

[qubes-users] HCL : NitroPC 2 - MSI Z790-P Intel i9 14900K

[code9n]

HCL report  NitroPC 2  -  MSI Z790-P  Intel i9 14900K

This is Qubes certified, of course, but here's an HCL report anyway.
---
layout:
  'hcl'
type:
  'Desktop'
hvm:
  'yes'
iommu:
  'yes'
slat:
  'yes'
tpm:
  'unknown'
remap:
  'yes'
brand: |
  Micro-Star International Co., Ltd.
model: |
  MS-7E06
bios: |
  Dasharo (coreboot+UEFI) v0.9.1
cpu: |
  Intel(R) Core(TM) i9-14900K
cpu-short: |
  FIXME
chipset: |
  Intel Corporation Device [8086:a700] (rev 01)
chipset-short: |
  FIXME
gpu: |
  Intel Corporation Raptor Lake-S GT1 [UHD Graphics 770] [8086:a780] (rev 
04) (prog-if 00 [VGA controller])
 
gpu-short: |
  FIXME
network: |
  Intel Corporation Ethernet Controller I225-V [8086:15f3] (rev 03)
memory: |
  65376
scsi: |

usb: |
  1
certified:
  'no'
versions:
  - works:
  'yes'
qubes: |
  R4.2.1
xen: |
  4.17.3
kernel: |
  6.6.21-1
remark: |
  No problems noticed.  Qubes certified.  Very Fast.
credit: |
  code9n
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/54d6b847-4390-45c1-ac7a-b35347d76713n%40googlegroups.com.

Re: [qubes-users] 'locking' a vm possible? (to prevent accidental shutdown)

['Rusty Bird' via qubes-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rusty Bird:
> Boryeu Mao:
> > An attempt to shutdown `sys-firewall` in `Qube Manager` receive a warning 
> > about running processes in the qube; similarly on command line 
> > `qvm-shutdown sys-firewall` fails with an error.  Is it possible to 
> > designate an appVM to behave similarly so it won't get shutdown 
> > accidentally?
> 
> Not as a user-facing feature AFAIK. But you could use the qubes.ext
> Python entry point
> 
> https://github.com/QubesOS/qubes-core-admin/blob/v4.2.21/qubes/ext/__init__.py#L57-L59
> 
> to add another "domain-pre-shutdown" event handler like this one
> (yours could e.g. check if the VM has a certain tag):
> 
> https://github.com/QubesOS/qubes-core-admin/blob/v4.2.21/qubes/ext/audio.py#L65-L75

Sorry, that second link should have been:

https://github.com/QubesOS/qubes-core-admin/blob/v4.2.21/qubes/ext/audio.py#L31-L38

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmYdQPRfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt9fGw/+JHmmCw+Ly/YXJ5uYJknlH/Z8hpViEwPnIGuuz7dkiHYa53BeKg+ub035
EOt0Z2ir8NuhHGXdN77A4j1PA6gXypEBme3sxDoP0uHv1Tc3GSAgbR4NzF0qucxy
EQisGL7LAw05raT5vFv8eWsHwfR1OHAupXZKJzHfjX3CBUce51K2N/eyPiuoX4es
m/1lpLmLWJgXAk2MgvwNop4coRiexLuXGWYpeG+64SrDmB0oJhFZ+8rhUig5UZ41
ImpkZl+cbFIxVL+j0tcWLlaDt8yTIJzR2lw0afOvHZcqNHlNo2OPSm4HiMfrThVP
9oAAU5fvTLQtnVJ0Qw49/wm6nr2IFuR3J3Zkz4PA0jVzxuXL6OGzjLuJuFlj01Sj
qxK3oU9dsN2cXCkp0k8gq39UAyHZwaeViFnAxKNm/U/ykRlFhLiloTF3ZvJYl7Vv
1N54BKKY5RjjtVsBgbDfKVcfSR4UwNt6v2PECfp+l7SpJb4XFiCNb9AoU2UoPQjj
icOPXw8r7AAMZdm+ANuMhTivGIi+7HR4MQ4xKRmD1bJ1qhQPGyuq+6loYJQQX+r4
1evr5+hCbQjapWN5IA7mRSgzaUEPC0Yrc5Ttirw81dbuCIPyv+B2c8LwQDvcorIR
A5EhArjwq1nY1N1ArMUKVf5+ONcIu7K56fjnMxyZXer3zExcYyA=
=mP8j
-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/Zh1A9DYFnKTnQt_z%40mutt.

Re: [qubes-users] 'locking' a vm possible? (to prevent accidental shutdown)

['Rusty Bird' via qubes-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Boryeu Mao:
> An attempt to shutdown `sys-firewall` in `Qube Manager` receive a warning 
> about running processes in the qube; similarly on command line 
> `qvm-shutdown sys-firewall` fails with an error.  Is it possible to 
> designate an appVM to behave similarly so it won't get shutdown 
> accidentally?

Not as a user-facing feature AFAIK. But you could use the qubes.ext
Python entry point

https://github.com/QubesOS/qubes-core-admin/blob/v4.2.21/qubes/ext/__init__.py#L57-L59

to add another "domain-pre-shutdown" event handler like this one
(yours could e.g. check if the VM has a certain tag):

https://github.com/QubesOS/qubes-core-admin/blob/v4.2.21/qubes/ext/audio.py#L65-L75

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmYdP79fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt/s0A//d0ks6I+il3Y/rnG5IINmEUMC8yKdTQM9E/xQQZlqSZOUHh4OSkdZB6ON
N/Iv1skUvVRuUxF8kFJ9M88FYH8X+fZsWr9ZQ18xPk+oQuQBarWTgT+TeprGj8CX
WSG1dfzyFs/m5DuE4M0xvzV9efIyfA80hRl/5VwLYLscMas2Dkvfcc8yWcdDkoY7
zKcI9jZzkUPfA5gAp92NWH10kYBdWlMYiqRLW22OT+Xe/dkohs/a80B1smKRZf7D
K9sF4CXauJxqxV8m+wMO8yma1jBEBoijkPZxf3m/z4SNl+cfcvLRvy+zV41dsTca
nkfvP2LflDWCpJFsdK77GQPGvx7ojX09ExAXu56kZJiQAn+rWFcX8edI+E+RQ0Z/
UMZ9a8Juj3s/myNEGr+MrhrdQ5qvUEafCOVBpLJG65xAw0B7eAAqG/vbboucaaVy
pQMFcYCyPxMzlMZQz82JHpzGiVscislC8naMYFneM9jsSL2K9D+P99tlHIziKt9w
dwUwvbuUOJtaZm94YMIbJkUaSK9BDInx49LAlzA5pAtRX4CMHY2YzYkLEUis2oAe
Ynj620eSnEwmPPa4sS97T+dnuO94S32UZrDLzYu7FZn4Rm5Gp6vq5pgbxXqkp8id
BdRn5dzQI6l4fijl+6FgfMTSZzVBNr7svjuGY8D0v3OfbywnT9Y=
=3CXB
-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/Zh0_v3dVrNYbjzcT%40mutt.

[qubes-users] Re: Qubes 4.2 installation problems due to Salt alone - what to do?

[Catacombs]

Hmm,  You might find it more useful to join the Qubes Forum, 

https://forum.qubes-os.org/

I wanted to reply, so you felt someone will help.

Perhaps Clarify some things.

Seems from your discussion of SALT, you know something of Linux.  

If the standard install did not finish correctly.  I am not thinking 
whatever is going on with SALT is the problem.  But SALT commands might 
reveal to some what is happening?
So, for me in your situation, I would go through the detail of what I 
assumed was true, but might not be.

Can you clarify.
Why are you sure the computer in question is compaitble with Qubes?  Have 
you used Qubes on it before?
Did you install UEFI or Legacy?   I use Legacy, UEFI is a different set of 
problems.
Does your computer have one or two drives?  (I have one computer, with two 
drives, that will only let me install Qubes to one drive, and the other 
drive must not have anything on it.  Other computers don't care.  and I did 
not say it made sense)
Are you trying to accomplish a dual boot?  (Qubes wants to be alone on the 
drive.   Some folks have gotten dual boot to work.  I have not tried)

Did you try to install Qubes on a drive that already had -something?  
(I have discovered that sometimes Qubes does not like to installed over 
something else.  Sometimes does not care.)

Can  you devote this computer to using Qubes right now?   Or is it a 
computer you use daily with another OS?
(helps to limit suggestions to something that is more reasonable for you to 
try)

I think someone more knowledgeable than myself will come by and recognize 
your symptoms, and you don't have to worry about answering this.  But it 
can't hurt.  

In a coupla days, If you have not gotten it going, I will come back and add 
more suggetions.   More confusion.  

but someone might recognize symptoms and make an easier fix.  

Cheers.


On Sunday, April 14, 2024 at 12:58:26 PM UTC-4 Michael Singer wrote:

> Dear Qubes Community,
>
> I am trying to install Qubes 4.2. in vain, not because the hardware is 
> incompatible, but because of Salt problems. I verified the downloaded ISO 
> according to the instructions, burned the ISO with various programs on a 
> USB stick, among others with the DD command:
>
> > dd if="./Qubes-R4.2.1-x86_64.iso" of="/dev/sda" status="progress" 
> conv="fsync"
>
> I have checked the result and it shows that the hash sum of the USB stick 
> under /dev/sda is the same as the downloaded file:
>
> > sudo dd if=/dev/sda bs=1M count=$(stat -c %s 
> /home/user/QubesIncoming/XXX/Qubes-R4.2.1-x86_64.iso) iflag=count_bytes | 
> sha256sum
> > a942911a3a4975831324a064f70b34c6965c4e9f6c95afbc531f04d55f947376
>
> When I start the computer with the USB stick and test the medium, the 
> following appears first:
>
> > Fragment sums: 2695f8d1(...)
> > supported iso: no
>
> Then, when the test has run 100 percent, the following appears:
>
> > [FAILED]
>
> If I install anyway, I have to cancel the automatic creation of sys-net, 
> sys-usb and personal AppVMs, because otherwise I get an installation error 
> because the installer does not set the PCI devices to disable strict reset. 
> At the end of the setup it still says:
>
> > "initial config failed", see /var/log/salt/minion
>
> The log there says:
>
> > Specified ext_pillar interface qvm_prefs unavailable
>
> And when I try to update dom0, it fails. The reason is noted in the same 
> log file:
>
> > Unable to detect release version
> > Cannot prepare internal mirror list: SSL peer certificate or SSH remote 
> key was not OK for https://mirrors.fedora(...)
>
> Everything otherwise works according to the HCL report, including Suspend, 
> Ethernet, USB, Speaker. Strange thing was that no default-mgmt-dvm seemed 
> to be present and was not started during update attempts.
>
> I have already tried the installation with 4.2.0 and 4.2.1, with standard 
> kernel and with the latest kernel.
>
> How could I solve the problem?
>
> Thank you,
> 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/df925c81-1683-4cff-b183-aaeb36ea49ben%40googlegroups.com.

[qubes-users] Installing a managed windows VPS on qubes.

[Oliver]

I bought a managed windows VPS that I want to add to
QubesOS/whonix(Debian-12).
How do I proceed?

-- 
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/CAF4vDVCsxbStJgjabRsvRVqnyj4vNx%3DyaDBaOUxzZSGUZjAmFQ%40mail.gmail.com.

[qubes-users] 'locking' a vm possible? (to prevent accidental shutdown)

[Boryeu Mao]

An attempt to shutdown `sys-firewall` in `Qube Manager` receive a warning 
about running processes in the qube; similarly on command line 
`qvm-shutdown sys-firewall` fails with an error.  Is it possible to 
designate an appVM to behave similarly so it won't get shutdown 
accidentally?

-- 
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/0d4820fc-c6d9-4d2d-97d1-268c8abd5876n%40googlegroups.com.

[qubes-users] Qubes 4.2 installation problems due to Salt alone - what to do?

[Michael Singer]

Dear Qubes Community,

I am trying to install Qubes 4.2. in vain, not because the hardware is 
incompatible, but because of Salt problems. I verified the downloaded ISO 
according to the instructions, burned the ISO with various programs on a USB 
stick, among others with the DD command:


dd if="./Qubes-R4.2.1-x86_64.iso" of="/dev/sda" status="progress" conv="fsync"


I have checked the result and it shows that the hash sum of the  USB stick 
under /dev/sda is the same as the downloaded file:


sudo dd if=/dev/sda bs=1M count=$(stat -c %s 
/home/user/QubesIncoming/XXX/Qubes-R4.2.1-x86_64.iso) iflag=count_bytes | 
sha256sum
a942911a3a4975831324a064f70b34c6965c4e9f6c95afbc531f04d55f947376


When I start the computer with the USB stick and test the medium, the following 
appears first:


Fragment sums: 2695f8d1(...)
supported iso: no


Then, when the test has run 100 percent, the following appears:


[FAILED]


If I install anyway, I have to cancel the automatic creation of sys-net, 
sys-usb and personal AppVMs, because otherwise I get an installation error 
because the installer does not set the PCI devices to disable strict reset. At 
the end of the setup it still says:


"initial config failed", see /var/log/salt/minion


The log there says:


Specified ext_pillar interface qvm_prefs unavailable


And when I try to update dom0, it fails. The reason is noted in the same log 
file:


Unable to detect release version
Cannot prepare internal mirror list: SSL peer certificate or SSH remote key was 
not OK for https://mirrors.fedora(...)


Everything otherwise works according to the HCL report, including Suspend, 
Ethernet, USB, Speaker. Strange thing was that no default-mgmt-dvm seemed to be 
present and was not started during update attempts.

I have already tried the installation with 4.2.0 and 4.2.1, with standard 
kernel and with the latest kernel.

How could I solve the problem?

Thank you,
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/ba7c6888-12ce-4ccc-87d5-38b8b80e9569%40posteo.de.

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

[Andrew David Wong]

Dear Qubes Community,

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

## XSAs that DO affect the security of Qubes OS

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

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

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

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

- [XSA-454](https://xenbits.xen.org/xsa/advisory-454.html)
  - Denial of service (DoS) only

## About this announcement

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-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/23faf24b-9c58-48ca-a496-3635efa667ac%40qubes-os.org.

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

[Andrew David Wong]

Dear Qubes Community,

We have published [Qubes Security Bulletin (QSB) 102: Multiple 
speculative-execution vulnerabilities: Spectre-BHB, BTC/SRSO (XSA-455, 
XSA-456)](https://github.com/QubesOS/qubes-secpack/blob/b1891ece2e914f644a9141b1d6f8e8ae07091dab/QSBs/qsb-102-2024.txt).
 The text of this QSB and its accompanying cryptographic signatures are 
reproduced below, followed by a general explanation of this announcement and 
authentication instructions.

## Qubes Security Bulletin 102

```

 ---===[ Qubes Security Bulletin 102 ]===---

 2024-04-09

   Multiple speculative-execution vulnerabilities:
  Spectre-BHB, BTC/SRSO (XSA-455, XSA-456)

User action


Continue to update normally [1] in order to receive the security updates
described in the "Patching" section below. No other user action is
required in response to this QSB.

Summary


The Xen Project published the following security advisories on
2024-04-09:

XSA-455 [3] "x86: Incorrect logic for BTC/SRSO mitigations":

| Because of a logical error in XSA-407 (Branch Type Confusion), the
| mitigation is not applied properly when it is intended to be used.
| XSA-434 (Speculative Return Stack Overflow) uses the same
| infrastructure, so is equally impacted.
| 
| For more details, see:
|   https://xenbits.xen.org/xsa/advisory-422.html
|   https://xenbits.xen.org/xsa/advisory-434.html

XSA-456 [4] "x86: Native Branch History Injection":

| In August 2022, researchers at VU Amsterdam disclosed Spectre-BHB.
| 
| Spectre-BHB was discussed in XSA-398.  At the time, the susceptibility
| of Xen to Spectre-BHB was uncertain so no specific action was taken in
| XSA-398.  However, various changes were made thereafter in upstream
| Xen as a consequence; more on these later.
| 
| VU Amsterdam have subsequently adjusted the attack to be pulled off
| entirely from userspace, without the aid of a managed runtime in the
| victim context.
| 
| For more details, see:
|   https://vusec.net/projects/native-bhi
|   https://vusec.net/projects/bhi-spectre-bhb
|   
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html
|   https://xenbits.xen.org/xsa/advisory-398.html

Impact
---

On affected systems, an attacker who manages to compromise a qube may be
able to use it to infer the contents of arbitrary system memory,
including memory assigned to other qubes. For more information, see:

 - QSB-077 [5] for XSA-389
 - QSB-083 [6] for XSA-407
 - QSB-093 [7] for XSA-434

Affected systems
-

For XSA-455, the affected systems are the same as in QSB-083 [6] and
QSB-093 [7].

For XSA-456, only Intel CPUs with the eIBRS feature (available since
2019) are affected. You can check for the presence of the eIBRS feature
by looking for "eibrs" in the "Dynamic Sets" section of the `xen-cpuid
-v` command output. For example, you can execute the following command
in dom0:

xen-cpuid -v | sed -n '/^Dynamic/,$ { /eibrs/p }'

Empty output means that XSA-456 does not affect the CPU, while non-empty
output means that XSA-456 does affect the CPU.

Patching
-

The following packages contain security updates that address the
vulnerabilities described in this bulletin:

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

  For Qubes 4.2, in dom0:
  - Xen packages, version 4.17.3-5

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

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.

Credits


See the original Xen Security Advisory.

References
---

[1] https://www.qubes-os.org/doc/how-to-update/
[2] https://www.qubes-os.org/doc/testing/
[3] https://xenbits.xen.org/xsa/advisory-455.html
[4] https://xenbits.xen.org/xsa/advisory-456.html
[5] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-077-2022.txt
[6] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-083-2022.txt
[7] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-093-2023.txt

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

```

*Source*: 
[qsb-102-2024.txt](https://github.com/QubesOS/qubes-secpack/blob/b1891ece2e914f644a9141b1d6f8e8ae07091dab/QSBs/qsb-102-2024.txt)

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

```
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEELRdx/k12ftx2sIn61lWk8hgw4GoFAmYVmWcACgkQ1lWk8hgw
4GpfvxAAjh4kz+3Nvypg3HcU7evlizSeFNDqbX67TVeMIX+mKp4sdf2tZ5XwFpqe

[qubes-users] Let's close this thread ...

[Viktor Ransmayr]

On Thu, 4 Apr 2024, 19:45 Viktor Ransmayr, 
wrote:

> Hello  'Haaber' & Qubes OS community,
>
> Am Di., 20. Feb. 2024 um 20:12 Uhr schrieb Viktor Ransmayr <
> viktor.ransm...@gmail.com>:
>
>> ...
>> Am Di., 20. Feb. 2024 um 11:10 Uhr schrieb 'haaber' via qubes-users <
>> qubes-users@googlegroups.com>:
>>
>>> ...
>>>
>>> all updates go via tor network (sys-whonix) by default. You could click
>>> on the blue qube widget -> sys-wonix -> run terminal and see if sys-whonix
>>> has network. But I
>>>
>> It took much longer due to private reasons - but - I can report that I
> was able to fully recover from the backups !
>
> What I did different than suggested was that I started with a clean
> re-install of Qubes OS 4.1 ...
>

Let's close this thread !

-- 
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/CAAeSrGKe6ErPWJmi%2BbrC_hrvPBTiR-7m%3DjD0AUo6FnSKagPM7A%40mail.gmail.com.

Re: [qubes-users] Need help after a failed in-place upgrade attempt

[Viktor Ransmayr]

Hello  'Haaber' & Qubes OS community,

Am Di., 20. Feb. 2024 um 20:12 Uhr schrieb Viktor Ransmayr <
viktor.ransm...@gmail.com>:

> ...
> Am Di., 20. Feb. 2024 um 11:10 Uhr schrieb 'haaber' via qubes-users <
> qubes-users@googlegroups.com>:
>
>> ...
>>
>> all updates go via tor network (sys-whonix) by default. You could click
>> on the blue qube widget -> sys-wonix -> run terminal and see if sys-whonix
>> has network. But I guess not. Here is why:
>>
>> https://www.qubes-os.org/doc/firewall/
>>
>> I wild-guess that you are in a "half-state" where one part of the system
>> expects iptables, another one nftables ...
>>
>> Did you download / start to download new (debian/fedora) Templates or are
>> they the "old" ones?
>>
>> I did not see any other user jump to your help, and I am not good enough
>> to fix that alone for you. So honestly, at your place I would
>>
>> (1) backup data (again)
>>
>> (2) extract the list of manually installed packages in each of your
>> templates and stock them on your backup drive
>>
>> ("apt-mark showmanual > manual.packages.list" in a terminal is your
>> friend, no root priv needed)
>>
>> (3) re-install a clean 4.2
>>
>> (4) replay your manual installs of packages in your templates:
>>
>> "cat  manual.packages.list | apt-get install  " or something of this
>> type should work (run as root)
>>
>> (5) restore your data.
>>
>> It's a pain and takes half a day, but I fear that it is, at the end of
>> the day,  faster than any other solution...
>>
>> good luck!
>>
>
> Thanks a lot !
>
> This is exactly the  feedback I was hoping for.
>
> I'll investigate further on my side & will provide an update from my side
> before the end of the week ...
>

It took much longer due to private reasons - but - I can report that I was
able to fully recover from the backups !

What I did different than suggested was that I started with a clean
re-install of Qubes OS 4.1 ...

Now I've started a second attempt of an in-place upgrade - and - are
already running into issues again at STAGE 1:

Here is the dom0 - log:

###

[vr@dom0 ~]$
[vr@dom0 ~]$ sudo qubes-dist-upgrade --update
WARNING: /!\ MAKE SURE YOU HAVE MADE A BACKUP OF ALL YOUR VMs AND dom0
DATA /!\
-> Launch upgrade process? [y/N] y
---> Allow shutdown of unnecessary VM (use --keep-running to exclude
some): fedora-feedly-vm fedora-qubes-study-vm? [y/N] y
---> (STAGE 1) Do you want to make a dom0 snapshot? [y/N] y
  WARNING: Sum of all thin volume sizes (<2.83 TiB) exceeds the size of
thin pools and the size of whole volume group (<475.34 GiB).
  Logical volume "Qubes41UpgradeBackup" created.
--> If upgrade to 4.2 fails, you can restore your dom0 snapshot with
sudo lvconvert --merge qubes_dom0/Qubes41UpgradeBackup. Reboot after
restoration.
---> (STAGE 1) Updating dom0...
Using sys-firewall as UpdateVM to download updates for Dom0; this may
take some time...
Qubes OS Repository for Dom02.9 MB/s | 3.0 kB
00:00
Qubes OS Repository for Dom06.7 MB/s | 192 kB
00:00

kernel-latest.x86_64  1000:6.7.7-1.qubes.fc32
 qubes-dom0-cached
kernel-latest-devel.x86_641000:6.7.7-1.qubes.fc32
 qubes-dom0-cached
kernel-latest-modules.x86_64  1000:6.7.7-1.qubes.fc32
 qubes-dom0-cached
kernel-latest-qubes-vm.x86_64 1000:6.7.7-1.qubes.fc32
 qubes-dom0-cached
qubes-usb-proxy-dom0.noarch   1.2.0-1.fc32
qubes-dom0-cached
Qubes OS Repository for Dom02.9 MB/s | 3.0 kB
00:00
Dependencies resolved.


 PackageArch   Version  Repository
Size


Installing:
 kernel-latest  x86_64 1000:6.7.7-1.qubes.fc32
 qubes-dom0-cached  12 M
 kernel-latest-develx86_64 1000:6.7.7-1.qubes.fc32
 qubes-dom0-cached  15 M
 kernel-latest-modules  x86_64 1000:6.7.7-1.qubes.fc32
 qubes-dom0-cached  76 M
 kernel-latest-qubes-vm x86_64 1000:6.7.7-1.qubes.fc32
 qubes-dom0-cached  18 M
Upgrading:
 qubes-usb-proxy-dom0   noarch 1.2.0-1.fc32
qubes-dom0-cached  25 k

Transaction Summary


Install  4 Packages
Upgrade  1 Package

Total size: 121 M
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing:
 1/1
  Installing   :
kernel-latest-modules-1000:6.7.7-1.qubes.fc32.x86_64   1/6
  Running scriptlet:
kernel-latest-modules-1000:6.7.7-1.qubes.fc32.x86_64   1/6
  Installing   : kernel-latest-devel-1000:6.7.7-1.qubes.fc32.x86_64
2/6
  Running scriptlet: kernel-latest-devel-1000:6.7.7-1.qubes.fc32.x86_64

[qubes-users] S0ix (s2idle sleep) on 13th gen intel draining battery

[Peter Palensky]

Dear all,

My 13th gen intel raptor lake Dell laptop only supports one sleep mode: 
s2idle a.k.a. S0ix, which drains the battery 7%/h -> empty over night. 

I am not the only one with that problem
https://discussion.fedoraproject.org/t/please-improve-the-s0ix-experience-under-linux/79113/2

Installed TLP on dom0, no difference.

https://www.phoronix.com/news/Intel-S0ix-Linux-Failure-Hot 
reports that
https://lore.kernel.org/linux-acpi/20220505015814.3727692-1-rui.zh...@intel.com/T/
can help. Any hope that this makes it into the qubes kernel?

Maybe some other HW needs to be explicitly configured. Any idea?

Peter.

-- 
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/954ab4c7-8a57-409c-9b79-3a90db7c0151n%40googlegroups.com.

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

[Andrew David Wong]

On 4/2/24 1:20 AM, qubist wrote:
> On Mon, 1 Apr 2024 16:33:13 -0700 Andrew David Wong wrote:
> 
>> [...] to the average user [...]
> 
> Targeting abstract entities is confusing.
> 

Feel free to replace that part with "to the vast majority of users," then.

-- 
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/fe28f939-9cf8-4b2d-ae90-016738d29725%40qubes-os.org.

[qubes-users] Per computer model wiki

[Sébastien Chaumat]

Hello,

 Is there any official, user editable documentation, where we can submit 
configuration tips for specific computer models ?

 Once the initial HCL report is out, it would be great to link from there 
to specific instructions for a given model to fix remaining issues when 
possible.

 For example the HCL for the  *Framework Laptop 13 *
Ryzen 7 7840U AMD still states that the touchpad is not working while a fix 
is available.
 
Thanks.

Sébastien
 

 

-- 
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/43e0a3ea-d782-4304-9d32-0805c35f2652n%40googlegroups.com.

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

[qubist]

On Mon, 1 Apr 2024 16:33:13 -0700 Andrew David Wong wrote:

> [...] to the average user [...]

Targeting abstract entities is confusing.

-- 
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/20240402082029.3a4c2a7e%40localhost.

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

[Andrew David Wong]

On 4/1/24 2:38 PM, Demi Marie Obenour wrote:
> On Sun, Mar 31, 2024 at 03:45:29PM -0700, Andrew David Wong wrote:
>> On 3/27/24 2:57 AM, qubist wrote:
>>> On Tue, 26 Mar 2024 14:46:12 -0700 Andrew David Wong wrote:
>>>
 ## What's new in Qubes OS 4.2.1?

 [...]

 For more information about the changes included [...]
>>>
>>> It would be much better to have a more detailed (yet concise)
>>> changelog. It is highly unlikely that the user will read pages upon
>>> pages of issues on a bug tracker, just to find out what is new.
>>>
>>> My $0.02. :)
>>>
> 
>> The concise changelog is already present, in the part you elided. Unlike 
>> major and minor releases, the primary purpose of patch releases is not to 
>> deliver new features or enhancements worth showcasing. Rather, the primary 
>> purpose is to provide a secure and convenient way for users to install (or 
>> reinstall) the latest stable Qubes release with an up-to-date ISO.
> 
>> Imagine if we had a major or minor release, then we didn't have any further 
>> releases for a year. Users who wanted to (re)install Qubes would have to use 
>> a year-old ISO, then immediately catch up on a year's worth of updates, 
>> which could take quite a long time. Moreover, any bugs that affected the 
>> installation or initial update processes themselves might be complete 
>> blockers for some users. A security vulnerability in the update mechanism 
>> could make that initial update risky.
> 
>> The purpose of these patch releases is mainly just to move up the "starting 
>> point" so that fresh installations don't have as far to "catch up" before 
>> they're on par with existing, regularly-updated installations. That's why 
>> the main summary of changes is just "all the routine updates you would've 
>> gotten if you had installed 4.2.0 and kept it up to date." Some of these 
>> routine updates will be of interest to some users while being of no interest 
>> at all to most other users. There should rarely be any that are of interest 
>> to *all* users. (Those should usually go in major or minor releases instead.)
> 
> With the obvious exception of security patches.

It occurred to me after I sent this that someone would probably point this out. 
Yes, but we already make a separate announcement for each and every QSB, so it 
would be somewhat redundant to repeat that in every patch release announcement. 
I'm not sure why listing the exact QSB patches included in a given patch 
release would be more useful to the average user than just saying "includes all 
security patches to date" (which is entailed by "includes all updates to date").

-- 
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/01ec459d-876c-46e3-88de-3ef2640a00c4%40qubes-os.org.

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

[Demi Marie Obenour]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sun, Mar 31, 2024 at 03:45:29PM -0700, Andrew David Wong wrote:
> On 3/27/24 2:57 AM, qubist wrote:
> > On Tue, 26 Mar 2024 14:46:12 -0700 Andrew David Wong wrote:
> > 
> >> ## What's new in Qubes OS 4.2.1?
> >>
> >> [...]
> >>
> >> For more information about the changes included [...]
> > 
> > It would be much better to have a more detailed (yet concise)
> > changelog. It is highly unlikely that the user will read pages upon
> > pages of issues on a bug tracker, just to find out what is new.
> > 
> > My $0.02. :)
> > 
> 
> The concise changelog is already present, in the part you elided. Unlike 
> major and minor releases, the primary purpose of patch releases is not to 
> deliver new features or enhancements worth showcasing. Rather, the primary 
> purpose is to provide a secure and convenient way for users to install (or 
> reinstall) the latest stable Qubes release with an up-to-date ISO.
> 
> Imagine if we had a major or minor release, then we didn't have any further 
> releases for a year. Users who wanted to (re)install Qubes would have to use 
> a year-old ISO, then immediately catch up on a year's worth of updates, which 
> could take quite a long time. Moreover, any bugs that affected the 
> installation or initial update processes themselves might be complete 
> blockers for some users. A security vulnerability in the update mechanism 
> could make that initial update risky.
> 
> The purpose of these patch releases is mainly just to move up the "starting 
> point" so that fresh installations don't have as far to "catch up" before 
> they're on par with existing, regularly-updated installations. That's why the 
> main summary of changes is just "all the routine updates you would've gotten 
> if you had installed 4.2.0 and kept it up to date." Some of these routine 
> updates will be of interest to some users while being of no interest at all 
> to most other users. There should rarely be any that are of interest to *all* 
> users. (Those should usually go in major or minor releases instead.)

With the obvious exception of security patches.
- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmYLKVsACgkQsoi1X/+c
IsF/+A//UsDrsR/wwgeSJgGgIVkElvB+W4TWMCOsx7NSTjZ4yWXw7e63hOTvVGTo
6tegSUDcfYMUty27KJKSsjc9difhQUuDco/CEvK2DOLDpEKO8IJtHU18+3zrk+0N
xweBTXuPD1T/FNbJAH3dKSdSsvXXmcqHW3FW6+q7AsnY3icg6zmdAsnqKVh7dylq
b3NwWLva/JOn1sxa214kxJmRkfG53o01jv9QTDviYqmGb0FBJ7P6tXFIp9sEMNlX
AqEGHF6Tj0fxQdvml3HlBZT0XZ265e6Th4xVhuA6titwML7HlIZDYu3AZP72u02E
NPOOZ29rgrUwTQsNPgDzJe3eAgxEiynOnAiabLSwF4HW8A0yJVgR02Lm46Vr+Npg
/LLxrmh4jRurhlpElvwA44nIenKpjprG5wFz48JHhrK+vyktxteyWTdvhE343nZh
tQYUEj9hsNscPuiwuNmbxqAhsuNMndhRHAcL/H/r6Sw88NmYj0YiWH7+NtrilVAs
Lp9S3oBeSjX+5QaD2abH8KnbjH7VdbynRFK1o3wXwUG/05KkT35RYw7eIojtDbCy
QWJpykgJfy50xn97s5Mtm5TvkN5TnE9TQx1UIOia/36IZBwatdPtO/lPZGCpSaDZ
9IF64BucZGcZts2xJnwV0s9VPfPpG9XN4IiB1EZzg6ko0XLrsVA=
=HFwF
-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/ZgspXMfjRaMrx_Zo%40itl-email.

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

[qubist]

Thanks for explaining.

-- 
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/20240401172142.2b375807%40localhost.

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

[Andrew David Wong]

On 3/27/24 2:57 AM, qubist wrote:
> On Tue, 26 Mar 2024 14:46:12 -0700 Andrew David Wong wrote:
> 
>> ## What's new in Qubes OS 4.2.1?
>>
>> [...]
>>
>> For more information about the changes included [...]
> 
> It would be much better to have a more detailed (yet concise)
> changelog. It is highly unlikely that the user will read pages upon
> pages of issues on a bug tracker, just to find out what is new.
> 
> My $0.02. :)
> 

The concise changelog is already present, in the part you elided. Unlike major 
and minor releases, the primary purpose of patch releases is not to deliver new 
features or enhancements worth showcasing. Rather, the primary purpose is to 
provide a secure and convenient way for users to install (or reinstall) the 
latest stable Qubes release with an up-to-date ISO.

Imagine if we had a major or minor release, then we didn't have any further 
releases for a year. Users who wanted to (re)install Qubes would have to use a 
year-old ISO, then immediately catch up on a year's worth of updates, which 
could take quite a long time. Moreover, any bugs that affected the installation 
or initial update processes themselves might be complete blockers for some 
users. A security vulnerability in the update mechanism could make that initial 
update risky.

The purpose of these patch releases is mainly just to move up the "starting 
point" so that fresh installations don't have as far to "catch up" before 
they're on par with existing, regularly-updated installations. That's why the 
main summary of changes is just "all the routine updates you would've gotten if 
you had installed 4.2.0 and kept it up to date." Some of these routine updates 
will be of interest to some users while being of no interest at all to most 
other users. There should rarely be any that are of interest to *all* users. 
(Those should usually go in major or minor releases instead.)

-- 
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/1aa33712-c69f-47e6-ba8b-63552559d326%40qubes-os.org.

Re: [qubes-users] sshuttle?

[Peter Palensky]

Thanks Tim! In my case (Qubes 4.2) it was 

nft add rule ip qubes custom-input iifname "vif*" accept

On Saturday, March 30, 2024 at 3:00:59 PM UTC+1 Tim Faber wrote:

> Hi Peter,
>
> that does the trick for me (in /rw/config/rc.local on Qubes 4.1):
> iptables -I INPUT 2 -i vif+ -j ACCEPT
> ip route add local default dev lo table 100
> ip rule add fwmark 1 lookup 100
>
> sshuttle --dns -D --method tproxy --exclude REMOTE_SERVER --exclude 
> 10.0.0.0/8 --disable-ipv6 --listen 0.0.0.0:0 -r REMOTE_SERVER 0/0
>
>
> All the best
>
>
> On 3/30/24 12:52, Peter Palensky wrote:
> > I need a sys-sshuttle qube to encapsulate traffic via sshuttle. Locally 
> > (from sys-sshuttle) it works, but connected qubes get the previously 
> > mentioned "no connection to host" message.
> > 
> > Played around with various nft ideas, but no success.
> > 
> > tcpdump on the vif shows requests (e.g. DNS, http, etc.) but they are 
> > not answered.
> > 
> > How do i redirect incoming traffic from vif to the sshuttle process 
> > listening on port 12300 as it is happening with local traffic?
> > On Wednesday, February 18, 2015 at 9:05:10 PM UTC+1 HW42 wrote:
> > 
> > D. J. Bernstein:
> > > Has anyone tried setting up sshuttle under Qubes?
> > 
> > Haven't used it before but I did a quick test.
> > 
> > > After setting up root@netvm to be able to ssh to another machine
> > ("ssh
> > > speed"), I ran
> > >
> > > sshuttle -v -r speed 0/0 -x 10/8
> > >
> > > and expected that outgoing TCP connections would be transparently
> > > proxied via the ssh connection. The sshuttle program reported
> > that it
> > > was doing
> > >
> > > iptables -t nat -N sshuttle-12300
> > > iptables -t nat -F sshuttle-12300
> > > iptables -t nat -I OUTPUT 1 -j sshuttle-12300
> > > iptables -t nat -I PREROUTING 1 -j sshuttle-12300
> > > iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.0/8
> >  -p tcp
> > > iptables -t nat -A sshuttle-12300 -j RETURN --dest 10.0.0.0/8
> >  -p tcp
> > > iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 0.0.0.0/0
> >  -p tcp --to-ports 12300 -m ttl ! --ttl 42
> > >
> > > as I expected, and outgoing TCP connections _from netvm_ were
> > proxied as
> > > I expected, but outgoing TCP connections from other VMs failed
> > with "no
> > > route to host".
> > >
> > > I haven't explored how the Qubes intra-host networking setup works,
> > > haven't started debugging with tcpdump, etc.; I'm just hoping that
> > > someone else has already looked at this.
> > 
> > sshuttle needs to accept connection from external ips (only
> > localhost by
> > default) and listen on fixed port:
> > sshuttle -v -l 0.0.0.0:123000 -r speed 0/0 -x 10/8
> > 
> > Allow the redirected packets:
> > iptables -I INPUT 1 -i vif+ -p tcp --dport 12300 -j ACCEPT
> > 
> > WARNING: This makes FORWARD firewall rules ineffective.
> > 
> > 
> > HW42
> > 
> > 
> > -- 
> > 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...@googlegroups.com 
> > .
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/qubes-users/6cc6eba0-a1ac-48de-9146-1b3e3db8948dn%40googlegroups.com
>  
> <
> https://groups.google.com/d/msgid/qubes-users/6cc6eba0-a1ac-48de-9146-1b3e3db8948dn%40googlegroups.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/7ee4407b-c3c9-4653-b16d-b79213fa7428n%40googlegroups.com.

Re: [qubes-users] sshuttle?

[Tim Faber]

Hi Peter,

that does the trick for me (in /rw/config/rc.local on Qubes 4.1):
iptables -I INPUT 2 -i vif+ -j ACCEPT
ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100

sshuttle --dns -D --method tproxy --exclude REMOTE_SERVER --exclude 
10.0.0.0/8 --disable-ipv6 --listen 0.0.0.0:0 -r REMOTE_SERVER 0/0



All the best


On 3/30/24 12:52, Peter Palensky wrote:
I need a sys-sshuttle qube to encapsulate traffic via sshuttle. Locally 
(from sys-sshuttle) it works, but connected qubes get the previously 
mentioned "no connection to host" message.


Played around with various nft ideas, but no success.

tcpdump on the vif shows requests (e.g. DNS, http, etc.) but they are 
not answered.


How do i redirect incoming traffic from vif to the sshuttle process 
listening on port 12300 as it is happening with local traffic?

On Wednesday, February 18, 2015 at 9:05:10 PM UTC+1 HW42 wrote:

D. J. Bernstein:
 > Has anyone tried setting up sshuttle under Qubes?

Haven't used it before but I did a quick test.

 > After setting up root@netvm to be able to ssh to another machine
("ssh
 > speed"), I ran
 >
 > sshuttle -v -r speed 0/0 -x 10/8
 >
 > and expected that outgoing TCP connections would be transparently
 > proxied via the ssh connection. The sshuttle program reported
that it
 > was doing
 >
 > iptables -t nat -N sshuttle-12300
 > iptables -t nat -F sshuttle-12300
 > iptables -t nat -I OUTPUT 1 -j sshuttle-12300
 > iptables -t nat -I PREROUTING 1 -j sshuttle-12300
 > iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.0/8
 -p tcp
 > iptables -t nat -A sshuttle-12300 -j RETURN --dest 10.0.0.0/8
 -p tcp
 > iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 0.0.0.0/0
 -p tcp --to-ports 12300 -m ttl ! --ttl 42
 >
 > as I expected, and outgoing TCP connections _from netvm_ were
proxied as
 > I expected, but outgoing TCP connections from other VMs failed
with "no
 > route to host".
 >
 > I haven't explored how the Qubes intra-host networking setup works,
 > haven't started debugging with tcpdump, etc.; I'm just hoping that
 > someone else has already looked at this.

sshuttle needs to accept connection from external ips (only
localhost by
default) and listen on fixed port:
sshuttle -v -l 0.0.0.0:123000 -r speed 0/0 -x 10/8

Allow the redirected packets:
iptables -I INPUT 1 -i vif+ -p tcp --dport 12300 -j ACCEPT

WARNING: This makes FORWARD firewall rules ineffective.


HW42


--
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/6cc6eba0-a1ac-48de-9146-1b3e3db8948dn%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/2f43b952-f4ff-4973-84bb-baa981913b32%40posteo.net.

Re: [qubes-users] sshuttle?

[Peter Palensky]

I need a sys-sshuttle qube to encapsulate traffic via sshuttle. Locally 
(from sys-sshuttle) it works, but connected qubes get the previously 
mentioned "no connection to host" message.

Played around with various nft ideas, but no success. 

tcpdump on the vif shows requests (e.g. DNS, http, etc.) but they are not 
answered. 

How do i redirect incoming traffic from vif to the sshuttle process 
listening on port 12300 as it is happening with local traffic?
On Wednesday, February 18, 2015 at 9:05:10 PM UTC+1 HW42 wrote:

> D. J. Bernstein:
> > Has anyone tried setting up sshuttle under Qubes?
>
> Haven't used it before but I did a quick test.
>
> > After setting up root@netvm to be able to ssh to another machine ("ssh
> > speed"), I ran
> > 
> > sshuttle -v -r speed 0/0 -x 10/8
> > 
> > and expected that outgoing TCP connections would be transparently
> > proxied via the ssh connection. The sshuttle program reported that it
> > was doing
> > 
> > iptables -t nat -N sshuttle-12300
> > iptables -t nat -F sshuttle-12300
> > iptables -t nat -I OUTPUT 1 -j sshuttle-12300
> > iptables -t nat -I PREROUTING 1 -j sshuttle-12300
> > iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.0/8 -p tcp
> > iptables -t nat -A sshuttle-12300 -j RETURN --dest 10.0.0.0/8 -p tcp
> > iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 0.0.0.0/0 -p tcp 
> --to-ports 12300 -m ttl ! --ttl 42
> > 
> > as I expected, and outgoing TCP connections _from netvm_ were proxied as
> > I expected, but outgoing TCP connections from other VMs failed with "no
> > route to host".
> > 
> > I haven't explored how the Qubes intra-host networking setup works,
> > haven't started debugging with tcpdump, etc.; I'm just hoping that
> > someone else has already looked at this.
>
> sshuttle needs to accept connection from external ips (only localhost by
> default) and listen on fixed port:
> sshuttle -v -l 0.0.0.0:123000 -r speed 0/0 -x 10/8
>
> Allow the redirected packets:
> iptables -I INPUT 1 -i vif+ -p tcp --dport 12300 -j ACCEPT
>
> WARNING: This makes FORWARD firewall rules ineffective.
>
>
> HW42
>
>
>

-- 
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/6cc6eba0-a1ac-48de-9146-1b3e3db8948dn%40googlegroups.com.

Re: [qubes-users] Tails VM: network broken since Qubes r4.2 (was online in r4.1)

[Stickstoff]

Thank you for looking into this!



Does using the static route you have in Debian, and adding static
neighbor entries for the peer, fix the problem?


I noticed the default routes actually differ a bit more between Tails and 
Debian [8] than I wrote
in my original mail (I have to type anything going in and out of Tails, no 
global clipboard yet).
I replaced the Tails default route with the Debian default route, but that did 
not help.
As I only try to ping the network VM, in the same ip network, routes shouldn't 
be necessary
nor interfere I guess?


If not, can you try this command?
$ sudo ip neighbour replace to 10.137.0.9 dev eth0 lladdr fe:ff:ff:ff:ff:ff nud 
permanent

That adds a permanent neighbour entry.  If it changes stuff it means
that ARP is broken.


I added that lookup entry, the network VM is still not reachable.
Afterwards, I checked the ARP cache. The ips of both VMs I tried to reach 
(firewall and networking)
are listed, with the same fe:ff:ff:ff:ff:ff mac. The newly added entry has "flags 
mask: CM", the other
has "C".

Stickstoff



[8]
Tails default route:
default via 10.137.0.9 dev eth0 proto static metric 100
10.137.0.0/24 dev eth0 proto kernel scope link src 10.137.0.32 metric 100

Debian default route:
default via 10.137.0.9 dev enX0 proto static metric 100
10.137.0.9 dev enX0 proto static scope link metric 100


On 2024-03-29 00:21, Demi Marie Obenour wrote:

On Thu, Mar 28, 2024 at 10:29:15PM +, Stickstoff wrote:

Hello everyone,



I have a difficult time with my Tails VM in Qubes (which I need for Tails 
specific developing and documentation work).
It gets no network connectivity no matter what I try. With "network 
connectivity" I mean the Tails VM can't even ping any network VM.



I set up a Tails VM [1] a while ago on an up-to-date Qubes r4.1 system (so it 
should be similar to r4.2?). After assigning the Tails VM a static ip [2],
it was online right away. Now I had to reinstall Qubes on new hardware, and 
installed r4.2. I copied the old Tails VM into the r4.2, and it is stuck 
offline.
I then created a new Tails VM, exactly the same way I did before with [1] and 
[2], it couldn't reach any networking VM neither.
Next, I purged iptable [3], removed all routes [4] except the default route and 
shutdown all network devices except eth0 [5].
Still, there is no ping response even from the networking VM (which does reply 
to other VM's pings).



Finally, I used a regular Debian 12 live image to create another standalone VM 
with [1]. It was online right away.
Tails is based on Debian 12 too.
The only meaningful difference between the Tails and the Debian VMs I could 
find was that their default routes [6] look a bit different, where I don't
know if this might be related.



So it does look like a Tails problem after all. But then, why was the same 
Tails VM online when hosted by an up-to-date r4.1 Qubes and offline on
a fresh installed r4.2 Qubes?
I found hints online that others experience the same [7] symptoms of non 
reachable networking VMs, where r4.1 vs r4.2 was brought up.




Does anyone have suggestions what else I might check and try?
I would be very grateful for any help. It would feel archaic and 
counterproductive to use another machine for working on Tails..



Stickstoff












[1] Installing a live linux into a standalone Qubes vm:
Create a new standalone qube: HVM, 2GB+  memory.
dom0: sudo sh -c 'qvm-run --pass-io BrowserVM "cat ~/downloads/tailsimage.img"' 
> /tmp/tailsimage.img
dom0: sudo dd if=/dev/zero of=root.img bs=1 count=0 seek=8G 
# new empty 8GB root.img as sparse file
dom0: sudo dd bs=32M conv=notrunc status=progress if=/tmp/tailsimage.img 
of=root.img# copy the image to the start of root.img
Tails: remove "live-media=removable" in grub bootloader (necessary at each boot 
of Tails)




[2] Setting up networking in Tails:
dom0: qvm-ls -n TailsVM # get the IP that dom0 assigned to the 
Tails VM
Tails: set static ip, netmask, gateway and dns



[3] purge iptable rules, allow everything:
Tails: sudo iptables -F
Tails: sudo iptables -X
Tails: sudo iptables -P INPUT ACCEPT
Tails: sudo iptables -P OUTPUT ACCEPT
Tails: sudo iptables -P FORWARD ACCEPT



[4] purge routes and add new default route:
Tails: sudo ip route del 
Tails: sudo ip route add default via 10.137.0.9 dev eth0



[5] shutdown network devices:
sudo ip link set dev  down



[6]
ip route Tails:
default via 10.137.0.9 dev eth0 proto static metric 100
10.137.0.0/24 dev eth0 proto kernel scope link src 10.137.0.32 metric 100
^



ip route Debian:
default via 10.137.0.9 dev enX0 proto static metric 100
10.137.0.9 dev enX0 proto kernel scope link src 10.137.0.32 metric 100
^^




[7]
https://forum.qubes-os.org/t/tailsos-template/23635/6


Does using the static route you have in Debian, and adding static
neighbor entries for the peer, fix the problem?  If not, can you try
this command?

$ sudo ip neighbour replace to 

Re: [qubes-users] Tails VM: network broken since Qubes r4.2 (was online in r4.1)

[Demi Marie Obenour]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, Mar 28, 2024 at 10:29:15PM +, Stickstoff wrote:
> Hello everyone,
> 
> I have a difficult time with my Tails VM in Qubes (which I need for Tails 
> specific developing and documentation work).
> It gets no network connectivity no matter what I try. With "network 
> connectivity" I mean the Tails VM can't even ping any network VM.
> 
> I set up a Tails VM [1] a while ago on an up-to-date Qubes r4.1 system (so it 
> should be similar to r4.2?). After assigning the Tails VM a static ip [2],
> it was online right away. Now I had to reinstall Qubes on new hardware, and 
> installed r4.2. I copied the old Tails VM into the r4.2, and it is stuck 
> offline.
> I then created a new Tails VM, exactly the same way I did before with [1] and 
> [2], it couldn't reach any networking VM neither.
> Next, I purged iptable [3], removed all routes [4] except the default route 
> and shutdown all network devices except eth0 [5].
> Still, there is no ping response even from the networking VM (which does 
> reply to other VM's pings).
> 
> Finally, I used a regular Debian 12 live image to create another standalone 
> VM with [1]. It was online right away.
> Tails is based on Debian 12 too.
> The only meaningful difference between the Tails and the Debian VMs I could 
> find was that their default routes [6] look a bit different, where I don't
> know if this might be related.
> 
> So it does look like a Tails problem after all. But then, why was the same 
> Tails VM online when hosted by an up-to-date r4.1 Qubes and offline on
> a fresh installed r4.2 Qubes?
> I found hints online that others experience the same [7] symptoms of non 
> reachable networking VMs, where r4.1 vs r4.2 was brought up.
> 
> 
> Does anyone have suggestions what else I might check and try?
> I would be very grateful for any help. It would feel archaic and 
> counterproductive to use another machine for working on Tails..
> 
> Stickstoff
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> [1] Installing a live linux into a standalone Qubes vm:
> Create a new standalone qube: HVM, 2GB+  memory.
> dom0: sudo sh -c 'qvm-run --pass-io BrowserVM "cat 
> ~/downloads/tailsimage.img"' > /tmp/tailsimage.img
> dom0: sudo dd if=/dev/zero of=root.img bs=1 count=0 seek=8G   
> # new empty 8GB root.img as sparse file
> dom0: sudo dd bs=32M conv=notrunc status=progress if=/tmp/tailsimage.img 
> of=root.img  # copy the image to the start of root.img
> Tails: remove "live-media=removable" in grub bootloader (necessary at each 
> boot of Tails)
> 
> 
> [2] Setting up networking in Tails:
> dom0: qvm-ls -n TailsVM   # get the IP that dom0 assigned 
> to the Tails VM
> Tails: set static ip, netmask, gateway and dns
> 
> [3] purge iptable rules, allow everything:
> Tails: sudo iptables -F
> Tails: sudo iptables -X
> Tails: sudo iptables -P INPUT ACCEPT
> Tails: sudo iptables -P OUTPUT ACCEPT
> Tails: sudo iptables -P FORWARD ACCEPT
> 
> [4] purge routes and add new default route:
> Tails: sudo ip route del 
> Tails: sudo ip route add default via 10.137.0.9 dev eth0
> 
> [5] shutdown network devices:
> sudo ip link set dev  down
> 
> [6]
> ip route Tails:
> default via 10.137.0.9 dev eth0 proto static metric 100
> 10.137.0.0/24 dev eth0 proto kernel scope link src 10.137.0.32 metric 100
> ^
> 
> ip route Debian:
> default via 10.137.0.9 dev enX0 proto static metric 100
> 10.137.0.9 dev enX0 proto kernel scope link src 10.137.0.32 metric 100
> ^^
> 
> 
> [7]
> https://forum.qubes-os.org/t/tailsos-template/23635/6

Does using the static route you have in Debian, and adding static
neighbor entries for the peer, fix the problem?  If not, can you try
this command?

$ sudo ip neighbour replace to 10.137.0.9 dev eth0 \
  lladdr fe:ff:ff:ff:ff:ff nud permanent

That adds a permanent neighbour entry.  If it changes stuff it means
that ARP is broken.
- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmYF+2YACgkQsoi1X/+c
IsFJ8Q/+NTsgrVCFAqn3IHkWbgni8WJxwFHZ0spRiPxCb/B+iBQnS/tk5phId5Wn
B8Sfscoq79vTlVZJrK7GoYfTTvgcd60xDj6HsQRy/ymyqhJ3SQtlw7l+xi//acDY
7A38Un+UXwN4QtGLQQ0mCqm8/YjeugqwHQq7sy7jodehjFDJkx021urlqob49xkc
40CFG6sI+PWZYMxzqphyICu2sMX8SnKzyKpPXJzKD3LSkFzukbVU3524EgGTv3Th
Rfliq/tljOhaIzZQSNsTiLAi0aPblPQ9PlO0X5gC8rzPF7YPIwYfEDJIEM+41UH6
l0OuhkE21rXOBbXnijmtesTHHYUzIcOUQWIuTdMGjjBYRlQ1igrRzc8WvFXXr7d6
tWYvaHXfIimpcfcM3CE15aMXmoEfjTkoHfnkpscZECzqxK5fKz0bLyIqqeilr92t
HLnKtWaiYnFXYcYtxwpWJ4vo4CdMMoJH1DEL6zM3EA3ajQsiN8Bx1T23qvFgj1wQ
OjfepcB2xpbOCjXgqUCR8uCPJKTLFxCbxAYduO1xQN9wYkm5/LUXn1b8ktp7V2Y2
McYGxCTJjYnZe7rn0+hfExkffhSM/WWbSttXsliD7FL0i8VSAQRSEs7IwHHz0lJT
8H1W3aa90Idt4MQQnWAuQfHKPgqHQrqBgsAx1Iqusf9mE5AQ3RY=
=t6k7
-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 

[qubes-users] Tails VM: network broken since Qubes r4.2 (was online in r4.1)

[Stickstoff]

Hello everyone,

I have a difficult time with my Tails VM in Qubes (which I need for Tails 
specific developing and documentation work).
It gets no network connectivity no matter what I try. With "network 
connectivity" I mean the Tails VM can't even ping any network VM.

I set up a Tails VM [1] a while ago on an up-to-date Qubes r4.1 system (so it 
should be similar to r4.2?). After assigning the Tails VM a static ip [2],
it was online right away. Now I had to reinstall Qubes on new hardware, and 
installed r4.2. I copied the old Tails VM into the r4.2, and it is stuck 
offline.
I then created a new Tails VM, exactly the same way I did before with [1] and 
[2], it couldn't reach any networking VM neither.
Next, I purged iptable [3], removed all routes [4] except the default route and 
shutdown all network devices except eth0 [5].
Still, there is no ping response even from the networking VM (which does reply 
to other VM's pings).

Finally, I used a regular Debian 12 live image to create another standalone VM 
with [1]. It was online right away.
Tails is based on Debian 12 too.
The only meaningful difference between the Tails and the Debian VMs I could 
find was that their default routes [6] look a bit different, where I don't
know if this might be related.

So it does look like a Tails problem after all. But then, why was the same 
Tails VM online when hosted by an up-to-date r4.1 Qubes and offline on
a fresh installed r4.2 Qubes?
I found hints online that others experience the same [7] symptoms of non 
reachable networking VMs, where r4.1 vs r4.2 was brought up.


Does anyone have suggestions what else I might check and try?
I would be very grateful for any help. It would feel archaic and 
counterproductive to use another machine for working on Tails..

Stickstoff










[1] Installing a live linux into a standalone Qubes vm:
Create a new standalone qube: HVM, 2GB+  memory.
dom0: sudo sh -c 'qvm-run --pass-io BrowserVM "cat ~/downloads/tailsimage.img"' 
> /tmp/tailsimage.img
dom0: sudo dd if=/dev/zero of=root.img bs=1 count=0 seek=8G 
# new empty 8GB root.img as sparse file
dom0: sudo dd bs=32M conv=notrunc status=progress if=/tmp/tailsimage.img 
of=root.img# copy the image to the start of root.img
Tails: remove "live-media=removable" in grub bootloader (necessary at each boot 
of Tails)


[2] Setting up networking in Tails:
dom0: qvm-ls -n TailsVM # get the IP that dom0 assigned to the 
Tails VM
Tails: set static ip, netmask, gateway and dns

[3] purge iptable rules, allow everything:
Tails: sudo iptables -F
Tails: sudo iptables -X
Tails: sudo iptables -P INPUT ACCEPT
Tails: sudo iptables -P OUTPUT ACCEPT
Tails: sudo iptables -P FORWARD ACCEPT

[4] purge routes and add new default route:
Tails: sudo ip route del 
Tails: sudo ip route add default via 10.137.0.9 dev eth0

[5] shutdown network devices:
sudo ip link set dev  down

[6]
ip route Tails:
default via 10.137.0.9 dev eth0 proto static metric 100
10.137.0.0/24 dev eth0 proto kernel scope link src 10.137.0.32 metric 100
^

ip route Debian:
default via 10.137.0.9 dev enX0 proto static metric 100
10.137.0.9 dev enX0 proto kernel scope link src 10.137.0.32 metric 100
^^


[7]
https://forum.qubes-os.org/t/tailsos-template/23635/6

--
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/b57c3dfb-f3af-46cf-a44d-86b233269910%40posteo.de.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Star Labs StarBook certified with intel only?

['జిందం వాఐి' via qubes-users]

On 2024-03-26 23:05, 'జిందం వాఐి' via qubes-users wrote:

On 2024-03-26 22:18, Andrew David Wong wrote:

On 3/25/24 11:25 AM, 'జిందం వాఐి' via qubes-users wrote:


As you can see, only Intel processors are listed. I'm not personally 
aware of any changes since then, but when it comes to Qubes-certified 
hardware, you should always consult the vendor's website for the 
latest information.


thanks for headsup, i will contact them


* contacted vendor
* hardware is certified for intel only
* my query and vendor reply_
https://support.starlabs.systems/conversations/starbook-qubesos-certification-intel-amd-or-both/perma?token=06aab71bb3930
* hope this helps



--
regards,
జిందం వాఐి [ jindam, vani ]
web_ jindam.neocities.org
[matrix]_ @jindam:oikei.net


--
regards,
జిందం వాఐి [ jindam, vani ]
web_ jindam.neocities.org
[matrix]_ @jindam:oikei.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/9c4341b68c14f0f9822a12cab904743e%40disroot.org.

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

[qubist]

On Tue, 26 Mar 2024 14:46:12 -0700 Andrew David Wong wrote:

> ## What's new in Qubes OS 4.2.1?
> 
> [...]
> 
> For more information about the changes included [...]

It would be much better to have a more detailed (yet concise)
changelog. It is highly unlikely that the user will read pages upon
pages of issues on a bug tracker, just to find out what is new.

My $0.02. :)

-- 
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/20240327095752.29f39474%40localhost.

Re: [qubes-users] Star Labs StarBook certified with intel only?

['జిందం వాఐి' via qubes-users]

On 2024-03-26 22:18, Andrew David Wong wrote:

On 3/25/24 11:25 AM, 'జిందం వాఐి' via qubes-users wrote:


As you can see, only Intel processors are listed. I'm not personally 
aware of any changes since then, but when it comes to Qubes-certified 
hardware, you should always consult the vendor's website for the latest 
information.


thanks for headsup, i will contact them


--
regards,
జిందం వాఐి [ jindam, vani ]
web_ jindam.neocities.org
[matrix]_ @jindam:oikei.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/ef689eaffdd99ccdb995f9847ee4db9a%40disroot.org.

Re: [qubes-users] Star Labs StarBook certified with intel only?

[Andrew David Wong]

On 3/25/24 11:25 AM, 'జిందం వాఐి' via qubes-users wrote:
> * i see an option to purchase
> laptop for amd also on their
> website
> * is this certified with only
> intel?
> 

As far as I know, that's correct, but you should check with Star Labs to be 
sure. The original certification announcement listed the certified 
configuration options at the time:

https://www.qubes-os.org/news/2024/01/10/starlabs-starbook-qubes-certified/

As you can see, only Intel processors are listed. I'm not personally aware of 
any changes since then, but when it comes to Qubes-certified hardware, you 
should always consult the vendor's website for the latest information.

-- 
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/7b434b32-7486-4115-aa4c-48b081960837%40qubes-os.org.

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

[Andrew David Wong]

Dear Qubes Community,

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

## Recommended actions

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

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

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

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

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

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

## What about patch releases?

The Qubes OS Project uses the [semantic versioning](https://semver.org/) 
standard. Version numbers are written as `..`. When a 
major or minor release reaches EOL, all of its patch releases also reach EOL. 
For example, in this case, when we say that "Qubes 4.1" (without specifying a 
`` number) is approaching EOL, we're specifying a particular minor 
release, inclusive of all patch releases within it. This means that Qubes 
4.1.0, 4.1.1, and 4.1.2 will all reach EOL at the same time (on 2024-06-18), 
since they are all just patch releases of the same minor release.

## How are EOL dates determined?

According to our [support 
policy](https://www.qubes-os.org/doc/supported-releases/), stable Qubes OS 
releases are supported for six months after each subsequent [major or minor 
release](https://www.qubes-os.org/doc/version-scheme/). This means that Qubes 
4.1 reaches EOL six months after Qubes 4.2 was released. Since Qubes 4.2.0 was 
[released on 
2023-12-18](https://www.qubes-os.org/news/2023/12/18/qubes-os-4-2-0-has-been-released/),
 Qubes 4.1's EOL date is six months later, on 2024-06-18.


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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-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/0e20b8fa-8d37-485c-b747-8cf51010e31f%40qubes-os.org.

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

[Andrew David Wong]

Dear Qubes Community,

We're pleased to announce the stable release of Qubes OS 4.2.1! This [patch 
release](#what-is-a-patch-release) aims to consolidate all the security 
patches, bug fixes, and other updates that have occurred since the release of 
Qubes 4.2.0. Our goal is to provide a secure and convenient way for users to 
install (or reinstall) the latest stable Qubes release with an up-to-date ISO. 
The ISO and associated [verification 
files](https://www.qubes-os.org/security/verifying-signatures/) are available 
on the [downloads](https://www.qubes-os.org/downloads/) page.

## What's new in Qubes OS 4.2.1?

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

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

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

## How to get Qubes OS 4.2.1

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

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

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

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

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

## Reminder: new signing key for Qubes OS 4.2

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

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

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

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

## What is a patch release?

The Qubes OS Project uses the [semantic versioning](https://semver.org/) 
standard. Version numbers are written as `..`. Hence, we 
refer to releases that increment the third number as "patch releases." A patch 
release does not designate a separate, new major or minor release of Qubes OS. 
Rather, it designates its respective major or minor release (in this case, 4.2) 
inclusive of all updates up to a certain point. (See [supported 
releases](https://www.qubes-os.org/doc/supported-releases/) for a comprehensive 
list of major and minor releases.) Installing the initial Qubes 4.2.0 release 
and fully [updating](https://www.qubes-os.org/doc/how-to-update/) it results in 
essentially the same system as installing Qubes 4.2.1. You can learn more about 
how Qubes release versioning works in the [version 
scheme](https://www.qubes-os.org/doc/version-scheme/) documentation.


This announcement 

Re: [qubes-users] Configure Network Qubes 4.2

[Michael Belless]

Also, in the future.  This might be faster to get responses

https://forum.qubes-os.org/

Welcome to our forum.

On Mon, Mar 25, 2024 at 6:12 PM Catacombs  wrote:

> HI,  Not exactly sure if this is what you want.
> It is an excellent question for a newcomer.
> Upper right hand side of screen.  Red,
> Two red terminals.  Click on this.
> What do you get?
>
> On Monday, March 25, 2024 at 11:43:31 AM UTC-4 Bapak Ireng wrote:
>
>> Sorry, i discuss in the Qubes Communityfaster responses, better
>> systemthen google groups
>>
>> Bapak Ireng schrieb am Montag, 25. März 2024 um 16:32:33 UTC+1:
>>
>>> i tried sudo /usr/libexec/initial-setup/initial-setup-graphical
>>>
>>> and the following is the output / result:
>>>
>>>
>>>
>>>
>>> i tried to sent pictures, but google did not let me sent them. 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/2bc3dbd0-2f6c-4e43-a411-1eac28bbe359n%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/CABsyOzHsrwP%3D2%3DaitHVEcwkWLS%2BQSZ9tHA0i%3DkU%3D0TAPFhJJVA%40mail.gmail.com.

Re: [qubes-users] Configure Network Qubes 4.2

[Catacombs]

I am sorry I was slow to reply.  I was having problems today, apparently 
from the large solar flares we have been having the last several days.  

Some of it is reflective of a earlier version, but
 https://www.qubes-os.org/doc/


On Monday, March 25, 2024 at 5:12:23 PM UTC-5 Catacombs wrote:

> HI,  Not exactly sure if this is what you want.  
> It is an excellent question for a newcomer.
> Upper right hand side of screen.  Red, 
> Two red terminals.  Click on this.  
> What do you get?
>
> On Monday, March 25, 2024 at 11:43:31 AM UTC-4 Bapak Ireng wrote:
>
>> Sorry, i discuss in the Qubes Communityfaster responses, better 
>> systemthen google groups
>>
>> Bapak Ireng schrieb am Montag, 25. März 2024 um 16:32:33 UTC+1:
>>
>>> i tried sudo /usr/libexec/initial-setup/initial-setup-graphical
>>>
>>> and the following is the output / result:
>>>
>>>
>>>
>>>
>>> i tried to sent pictures, but google did not let me sent them. 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/c24bc1d4-6648-430e-8c27-528ba31c73f1n%40googlegroups.com.

[qubes-users] Star Labs StarBook certified with intel only?

['జిందం వాఐి' via qubes-users]

* i see an option to purchase
laptop for amd also on their
website
* is this certified with only
intel?

--
regards,
జిందం వాఐి [ jindam, vani ]
web_ jindam.neocities.org
[matrix]_ @jindam:oikei.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/ccfaea3acfd69873fb339ebf90d74178%40disroot.org.

Re: [qubes-users] Configure Network Qubes 4.2

[Catacombs]

HI,  Not exactly sure if this is what you want.  
It is an excellent question for a newcomer.
Upper right hand side of screen.  Red, 
Two red terminals.  Click on this.  
What do you get?

On Monday, March 25, 2024 at 11:43:31 AM UTC-4 Bapak Ireng wrote:

> Sorry, i discuss in the Qubes Communityfaster responses, better 
> systemthen google groups
>
> Bapak Ireng schrieb am Montag, 25. März 2024 um 16:32:33 UTC+1:
>
>> i tried sudo /usr/libexec/initial-setup/initial-setup-graphical
>>
>> and the following is the output / result:
>>
>>
>>
>>
>> i tried to sent pictures, but google did not let me sent them. 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/2bc3dbd0-2f6c-4e43-a411-1eac28bbe359n%40googlegroups.com.

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

[Andrew David Wong]

Dear Qubes Community,

*Update*: Marek Marczykowski-Górecki’s PGP signature is now available (see 
below).

We have updated [Qubes Security Bulletin (QSB) 101: Register File Data Sampling 
(XSA-452) and Intel Processor Return Predictions Advisory 
(INTEL-SA-00982)](https://github.com/QubesOS/qubes-secpack/blob/345734de68d6994d99f461f26e63a09043d4c09c/QSBs/qsb-101-2024.txt).
 The text of this updated QSB (including a changelog) and its accompanying 
cryptographic signatures are reproduced below, followed by a general 
explanation of this announcement and authentication instructions.

## Qubes Security Bulletin 101

```

 ---===[ Qubes Security Bulletin 101 ]===---

  2024-03-12

  Register File Data Sampling (XSA-452) and
 Intel Processor Return Predictions Advisory (INTEL-SA-00982)

Changelog
--

2024-03-12: Original QSB
2024-03-17: Add information about INTEL-SA-00982

User action


Continue to update normally [1] in order to receive the security updates
described in the "Patching" section below. No other user action is
required in response to this QSB.

Summary


On 2024-03-12, the Xen Project published XSA-452, "x86: Register File
Data Sampling" [3]:

| Intel have disclosed RFDS, Register File Data Sampling, affecting some
| Atom cores.
|
| This came from internal validation work.  There is no information
| provided about how an attacker might go about inferring data from the
| register files.

For more information, see Intel's security advisory. [4]

In addition, Intel published INTEL-SA-00982/CVE-2023-38575 [6] on the
same day:

| Non-transparent sharing of return predictor targets between contexts
| in some Intel® Processors may allow an authorized user to potentially
| enable information disclosure via local access.

Information about this vulnerability is very sparse.

Impact
---

On systems affected by Register File Data Sampling (RFDS), an attacker
might be able to infer the contents of data previously held in floating
point, vector, and/or integer register files on the same core, including
data from a more privileged context.

On systems affected by INTEL-SA-00982, an attacker might be able to leak
information from other security contexts, but the precise impact is
unclear.

Affected systems
-

At present, Register File Data Sampling (RFDS) is known to affect only
certain Atom cores from Intel. Other Intel CPUs and CPUs from other
hardware vendors are not known to be affected. RFDS affects Atom cores
between the Goldmont and Gracemont microarchitectures. This includes
Alder Lake and Raptor Lake hybrid client systems that have a mix of
Gracemont and other types of cores.

At the time of this writing, Intel has not published information about
which systems INTEL-SA-00982 affects. Systems that are still receiving
microcode updates from Intel [7] and that received a microcode update as
part of the microcode release on 2024-03-12 [5] may be affected, even if
they are not affected by RFDS.

Patching
-

The following packages contain security updates that address the
vulnerabilities described in this bulletin:

  For Qubes 4.1, in dom0:
  - Xen packages version 4.14.6-7
  - microcode_ctl 2.1-57.qubes1

  For Qubes 4.2, in dom0:
  - Xen packages version 4.17.3-4
  - microcode_ctl 2.1-57.qubes1

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

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.

Credits


See the original Xen Security Advisory.

References
---

[1] https://www.qubes-os.org/doc/how-to-update/
[2] https://www.qubes-os.org/doc/testing/
[3] https://xenbits.xen.org/xsa/advisory-452.html
[4] 
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/register-file-data-sampling.html
[5] 
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md#microcode-20240312
[6] 
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00982.html
[7] 
https://www.intel.com/content/www/us/en/support/articles/22396/processors.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/k12ftx2sIn61lWk8hgw4GoFAmYAyxAACgkQ1lWk8hgw

Re: [qubes-users] Configure Network Qubes 4.2

['Bapak Ireng' via qubes-users]

Sorry, i discuss in the Qubes Communityfaster responses, better 
systemthen google groups

Bapak Ireng schrieb am Montag, 25. März 2024 um 16:32:33 UTC+1:

> i tried sudo /usr/libexec/initial-setup/initial-setup-graphical
>
> and the following is the output / result:
>
>
>
>
> i tried to sent pictures, but google did not let me sent them. 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/2f09b820-5a8d-4ba3-804a-142aa513f828n%40googlegroups.com.

Re: [qubes-users] Configure Network Qubes 4.2

['Bapak Ireng' via qubes-users]

i tried sudo /usr/libexec/initial-setup/initial-setup-graphical

and the following is the output / result:




i tried to sent pictures, but google did not let me sent them. 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/af6316e9-b3a7-461a-9fac-2ff5bd66f324n%40googlegroups.com.

Re: [qubes-users] Configure Network Qubes 4.2

['haaber' via qubes-users]

Hi, after successfully installing Qubes 4.2 i am left all alone to
configure network (internet) Access.


I appreciate it very much if somebody could guide me to the right options.


The question is so vague, no one can reasonably answer it.

Does sys-net start on boot?

Does it have access to the hardware (qubes settings -> devices tab)?

Do we talk about ethernet / wireless? If wireless, are the needed
drivers in your sys-net linux distri?


and so forth

--
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/358c320a-15dd-4fd4-8486-b1c5c973d5a0%40web.de.

[qubes-users] Configure Network Qubes 4.2

['Bapak Ireng' via qubes-users]

Hi, after successfully installing Qubes 4.2 i am left all alone to 
configure network (internet) Access. 

I appreciate it very much if somebody could guide me to the right options.

Best regards, Bapak Hitam

-- 
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/7e187f48-3bc5-4153-9703-fdb84bc38f1bn%40googlegroups.com.

Re: [qubes-users] Re: Qubes 4.2: Attach usb audio device to appvm

['Rune Philosof' via qubes-users]

It was not fixed...
Apparently just an example of how random it is.
It was working for an hour or so. Now it is back to mic not working, just
sending out that beep beep sound.

On Wed, Mar 20, 2024 at 9:16 AM 'Rune Philosof' via qubes-users <
qubes-users@googlegroups.com> wrote:

> Installing a new template fixed it.
> I installed fedora-39 and switched to it.
>
> The old template had been upgraded in-place several times, back from
> fedora-36, I think.
> Maybe something is missing in the upgrade from 4.1 to 4.2, or in the
> instructions on how to upgrade existing templates to 4.2.
>
>
> On Wednesday, March 20, 2024 at 8:17:25 AM UTC+1 Rune Philosof wrote:
>
>> Now it is more consistent in how it is not working.
>> Audio output is connected properly.
>> But microphone is still not working. It does not capture any sound from
>> the microphone, but it does repeat a ticking sound. I have attached a 3
>> second recording of the ticking sound.
>>
>> I have not changed any audio settings.
>> I have tested with two different usb soundcards.
>> It worked in Qubes 4.1.
>>
>> I wonder what has changed in the audio setup from Qubes 4.1 to 4.2.
>>
>> On Thursday, February 29, 2024 at 12:23:30 PM UTC+1 Rune Philosof wrote:
>>
>>> After upgrading to 4.2 my audio device does not work.
>>>
>>> I plug in a usb audio device, then attach that usb device to an appvm
>>> and try to use it in e.g. meet.google.com.
>>> For some reason it only works for the audio microphone or the speaker,
>>> not both.
>>> Example:
>>> 1. I attach the usb device to the appvm.
>>> 2. meet.google.com automatically switches to the new microphone, but I
>>> cannot hear anything and the speaker list does not show the usb device.
>>> 3. I then detach from the appvm and reattach the usb device to the same
>>> appvm.
>>> 4. meet.google.com does not show the usb device in the list of
>>> microphones. but somehow the "default" speaker now outputs through the usb
>>> device.
>>>
>>> In 4.1 it would either work for both mic and speaker or for none.
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "qubes-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/qubes-users/NDRrrYrLkpQ/unsubscribe.
> To unsubscribe from this group and all its topics, 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/f66bbd6a-ad20-4c30-a005-32bad82c8282n%40googlegroups.com
> 
> .
>


-- 
Med venlig hilsen / Best regards

Rune Philosof
Software developer

+45 28 45 64 08
r...@abtion.com


Vesterbrogade 15, 3
1620 København V

Sverigesgade 18
5000 Odense C

https://abtion.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/CAL8J5gaHuuvugFkwSEOTc6n2VnfzE0U-1yngaFu3zxqBAn2aZg%40mail.gmail.com.

[qubes-users] Re: HVM standalone: no mouse after suspend-to-ram

[Stickstoff]

Dear group,


After I wake Qubes from suspend-to-ram, the mouse doesn't work in
Tails any more.


this issue resolved itself after reinstalling qubes r4.2  freshly, on 
another hardware.
Maybe because it was a fresh install, maybe because it was directly r4.2 
and not upgraded from earlier versions, maybe the difference is the 
different hardware.

I did not, however, change anything in the Tails VM for it to now work.

Cheers,

Stickstoff




On 2024-02-01 13:40, Stickstoff wrote:

Dear group,

I am having issues with the mouse not coming back after standby.

I am running Qubes 4.1.2 (R4.1), kernel 5.15.52-1.fc32.qubes.x86_64 
The VM is a HVM standalone, running Tails OS, kernel 6.1.0-13-amd64 
(Debian 6.1.55-1). After I wake Qubes from suspend-to-ram, the mouse

doesn't work in Tails any more. The mouse still works in Qubes OS and
other VMs. The (internal, non-usb) keyboard still works everywhere. I
do not have any other standalone VMs installed to compare. In Tails,
after waking up I only see two errors:

clocksource: timekeeping watchdog on CPU3: Marking clocksource
'tsc' as unstable because the skew is too large

and

usb 1-1: Failed to suspend device, error -110
where usb 1-1 seems to be the "QEMU USB Tablet" virtual mouse. 
Reading up, "error -110" seems to be some kind of timeout error.


Any ideas on this one? Is it even Qubes or XEN or qemu related, or
rather on the Tails side?

(Yes, Tails doesn't like to be in VMs. Yes, this comes with its own 
security implications.)


Thank you,

Stickstoff



--
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/ffa2654d-8c5e-4518-9b67-d29c67a9a689%40posteo.de.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Inconsistency between `qvm-template list` and `qvm-template-gui`

['unman' via qubes-users]

Without seeing the screenshot, I think I know the issue.
They are from the same repository.
qvm-template lists *all* the template in the repo, whereas
qvm-template-gui filters to only show the most recent supported
versions.
-- 
I never presume to speak for the Qubes team.  
When I comment in the mailing lists I speak for 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/Zfq6MxZ7JMd5HZqM%40thirdeyesecurity.org.

[qubes-users] Re: Qubes 4.2: Attach usb audio device to appvm

['Rune Philosof' via qubes-users]

Installing a new template fixed it.
I installed fedora-39 and switched to it.

The old template had been upgraded in-place several times, back from 
fedora-36, I think.
Maybe something is missing in the upgrade from 4.1 to 4.2, or in the 
instructions on how to upgrade existing templates to 4.2.


On Wednesday, March 20, 2024 at 8:17:25 AM UTC+1 Rune Philosof wrote:

> Now it is more consistent in how it is not working.
> Audio output is connected properly.
> But microphone is still not working. It does not capture any sound from 
> the microphone, but it does repeat a ticking sound. I have attached a 3 
> second recording of the ticking sound.
>
> I have not changed any audio settings.
> I have tested with two different usb soundcards.
> It worked in Qubes 4.1.
>
> I wonder what has changed in the audio setup from Qubes 4.1 to 4.2.
>
> On Thursday, February 29, 2024 at 12:23:30 PM UTC+1 Rune Philosof wrote:
>
>> After upgrading to 4.2 my audio device does not work.
>>
>> I plug in a usb audio device, then attach that usb device to an appvm and 
>> try to use it in e.g. meet.google.com.
>> For some reason it only works for the audio microphone or the speaker, 
>> not both.
>> Example:
>> 1. I attach the usb device to the appvm.
>> 2. meet.google.com automatically switches to the new microphone, but I 
>> cannot hear anything and the speaker list does not show the usb device.
>> 3. I then detach from the appvm and reattach the usb device to the same 
>> appvm.
>> 4. meet.google.com does not show the usb device in the list of 
>> microphones. but somehow the "default" speaker now outputs through the usb 
>> device.
>>
>> In 4.1 it would either work for both mic and speaker or for none.
>>
>

-- 
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/f66bbd6a-ad20-4c30-a005-32bad82c8282n%40googlegroups.com.

[qubes-users] Where exactly does qubesdb-write write the data?

[qubist]

Hi,

Where exactly does qubesdb-write write the data?

What RPC policy is necessary for qube A to be able to read/write
'/somepath' of qube B? (but *no* other paths)

What can this be used for (safely)?

-- 
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/20240318165349.46dbf170%40localhost.

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

[Andrew David Wong]

Dear Qubes Community,

We have updated [Qubes Security Bulletin (QSB) 101: Register File Data Sampling 
(XSA-452) and Intel Processor Return Predictions Advisory 
(INTEL-SA-00982)](https://github.com/QubesOS/qubes-secpack/blob/c5693c8a4b81b3afb7cd7e6e44db3bbc36987049/QSBs/qsb-101-2024.txt).
 The text of this updated QSB (including a changelog) and its accompanying 
cryptographic signature are reproduced below, followed by a general explanation 
of this announcement and authentication instructions.

## Qubes Security Bulletin 101

```

 ---===[ Qubes Security Bulletin 101 ]===---

  2024-03-12

  Register File Data Sampling (XSA-452) and
 Intel Processor Return Predictions Advisory (INTEL-SA-00982)

Changelog
--

2024-03-12: Original QSB
2024-03-17: Add information about INTEL-SA-00982

User action


Continue to update normally [1] in order to receive the security updates
described in the "Patching" section below. No other user action is
required in response to this QSB.

Summary


On 2024-03-12, the Xen Project published XSA-452, "x86: Register File
Data Sampling" [3]:

| Intel have disclosed RFDS, Register File Data Sampling, affecting some
| Atom cores.
|
| This came from internal validation work.  There is no information
| provided about how an attacker might go about inferring data from the
| register files.

For more information, see Intel's security advisory. [4]

In addition, Intel published INTEL-SA-00982/CVE-2023-38575 [6] on the
same day:

| Non-transparent sharing of return predictor targets between contexts
| in some Intel® Processors may allow an authorized user to potentially
| enable information disclosure via local access.

Information about this vulnerability is very sparse.

Impact
---

On systems affected by Register File Data Sampling (RFDS), an attacker
might be able to infer the contents of data previously held in floating
point, vector, and/or integer register files on the same core, including
data from a more privileged context.

On systems affected by INTEL-SA-00982, an attacker might be able to leak
information from other security contexts, but the precise impact is
unclear.

Affected systems
-

At present, Register File Data Sampling (RFDS) is known to affect only
certain Atom cores from Intel. Other Intel CPUs and CPUs from other
hardware vendors are not known to be affected. RFDS affects Atom cores
between the Goldmont and Gracemont microarchitectures. This includes
Alder Lake and Raptor Lake hybrid client systems that have a mix of
Gracemont and other types of cores.

At the time of this writing, Intel has not published information about
which systems INTEL-SA-00982 affects. Systems that are still receiving
microcode updates from Intel [7] and that received a microcode update as
part of the microcode release on 2024-03-12 [5] may be affected, even if
they are not affected by RFDS.

Patching
-

The following packages contain security updates that address the
vulnerabilities described in this bulletin:

  For Qubes 4.1, in dom0:
  - Xen packages version 4.14.6-7
  - microcode_ctl 2.1-57.qubes1

  For Qubes 4.2, in dom0:
  - Xen packages version 4.17.3-4
  - microcode_ctl 2.1-57.qubes1

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

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.

Credits


See the original Xen Security Advisory.

References
---

[1] https://www.qubes-os.org/doc/how-to-update/
[2] https://www.qubes-os.org/doc/testing/
[3] https://xenbits.xen.org/xsa/advisory-452.html
[4] 
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/register-file-data-sampling.html
[5] 
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md#microcode-20240312
[6] 
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00982.html
[7] 
https://www.intel.com/content/www/us/en/support/articles/22396/processors.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

At the time of this writing, Marek is traveling and is therefore not available 
to sign this QSB update. He will sign it when he returns. In the meantime, you 
can still authenticate his [original 

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

[Andrew David Wong]

Dear Qubes Community,

We're pleased to announce that the first [release candidate 
(RC)](#what-is-a-release-candidate) for Qubes OS 4.2.1 is now available for 
[testing](https://www.qubes-os.org/doc/testing/). This [patch 
release](#what-is-a-patch-release) aims to consolidate all the security 
patches, bug fixes, and other updates that have occurred since the release of 
Qubes 4.2.0. Our goal is to provide a secure and convenient way for users to 
install (or reinstall) the latest stable Qubes release with an up-to-date ISO. 
The ISO and associated [verification 
files](https://www.qubes-os.org/security/verifying-signatures/) are available 
on the [downloads](https://www.qubes-os.org/downloads/) page. For more 
information about the changes included in this version, see the [full list of 
issues completed since the release of 
4.2.0](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+is%3Aclosed+reason%3Acompleted+closed%3A2023-12-18..2024-03-14+-label%3A%22R%3A+cannot+reproduce%22+-label%3A%22R%3A+declined%22+-label%3A%22R%3A+duplicate%22+-label%3A%22R%3A+not+applicable%22+-label%3A%22R%3A+self-closed%22+-label%3A%22R%3A+upstream+issue%22+).

## When is the stable release?

That depends on the number of bugs discovered in this RC and their severity. As 
explained in our [release 
schedule](https://www.qubes-os.org/doc/version-scheme/#release-schedule) 
documentation, our usual process after issuing a new RC is to collect bug 
reports, triage the bugs, and fix them. If warranted, we then issue a new RC 
that includes the fixes and repeat the process. We continue this iterative 
procedure until we're left with an RC that's good enough to be declared the 
stable release. No one can predict, at the outset, how many iterations will be 
required (and hence how many RCs will be needed before a stable release), but 
we tend to get a clearer picture of this as testing progresses. Here is the 
latest update:

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

## Testing Qubes 4.2.1-rc1

If you're willing to [test](https://www.qubes-os.org/doc/testing/) this new RC, 
you can help us improve the eventual stable release by [reporting any bugs you 
encounter](https://www.qubes-os.org/doc/issue-tracking/). We encourage 
experienced users to join the [testing 
team](https://forum.qubes-os.org/t/joining-the-testing-team/5190). The best way 
to test Qubes 4.2.1-rc1 is by performing a [clean 
installation](https://www.qubes-os.org/doc/installation-guide/) with the new 
ISO. We strongly recommend [making a full 
backup](https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/) 
beforehand.

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

## Reminder: new signing key for Qubes OS 4.2

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

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

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

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

## What is a release candidate?

A release candidate (RC) is a software build that has the potential to become a 
stable release, unless significant bugs are 

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

[Leo28C]

Anybody going from USA willing to take me in their luggage hit me up. I
bring my own food and oxygen

On Wed, Mar 13, 2024 at 3:56 PM Andrew David Wong  wrote:

> Dear Qubes Community,
>
> In conjunction with [3mdeb](https://3mdeb.com/), the sixth edition of our
> Qubes OS Summit will be held live this year from September 20 to 22 in
> Berlin, Germany! For more information about this event, please see: <
> https://vpub.dasharo.com/e/16/qubes-os-summit-2024>
>
> If you would like to submit a proposal, the Call for Participation (CFP)
> is open until August 5: 
>
>
> This announcement is also available on the Qubes website:
> https://www.qubes-os.org/news/2024/03/13/qubes-os-summit-2024/
>
> --
> You received this message because you are subscribed to the Google Groups
> "qubes-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/b9b4b9d7-7283-44c0-b1db-fe4264d71f6e%40qubes-os.org
> .
>

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

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

[Andrew David Wong]

Dear Qubes Community,

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


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


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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-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/b9b4b9d7-7283-44c0-b1db-fe4264d71f6e%40qubes-os.org.

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

[Andrew David Wong]

Dear Qubes Community,

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

## XSAs that DO affect the security of Qubes OS

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

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

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

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

- [XSA-453](https://xenbits.xen.org/xsa/advisory-453.html)
  - The Qubes security team concurs with the Xen security team's assessment in 
the "VULNERABLE SYSTEMS" section of XSA-453.

## About this announcement

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-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/332b7027-9eae-4cb5-9b23-f4456d5f8204%40qubes-os.org.

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

[Andrew David Wong]

Dear Qubes Community,

We have published [Qubes Security Bulletin 101: Register File Data Sampling 
(XSA-452)](https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-101-2024.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 101

```

 ---===[ Qubes Security Bulletin 101 ]===---

  2024-03-12

 Register File Data Sampling (XSA-452)

User action


Continue to update normally [1] in order to receive the security updates
described in the "Patching" section below. No other user action is
required in response to this QSB.

Summary


On 2024-03-12, the Xen Project published XSA-452, "x86: Register File
Data Sampling" [3]:
| Intel have disclosed RFDS, Register File Data Sampling, affecting some
| Atom cores.
|
| This came from internal validation work.  There is no information
| provided about how an attacker might go about inferring data from the
| register files.

For more details, see [4].

Impact
---

An attacker might be able to infer the contents of data held previously
in floating point, vector, and/or integer register files on the same
core, including data from a more privileged context.

Affected systems
-

At present, RFDS is known to affect only certain Atom cores from Intel.
Other Intel CPUs and CPUs from other hardware vendors are not known to
be affected.

RFDS affects Atom cores between the Goldmont and Gracemont
microarchitectures. This includes Alder Lake and Raptor Lake hybrid
client systems that have a mix of Gracemont and other types of cores.

Patching
-

The following packages contain security updates that address the
vulnerabilities described in this bulletin:

  For Qubes 4.1, in dom0:
  - Xen packages version 4.14.6-7
  - microcode_ctl 2.1-57.qubes1

  For Qubes 4.2, in dom0:
  - Xen packages version 4.17.3-4
  - microcode_ctl 2.1-57.qubes1

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

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.

Credits


See the original Xen Security Advisory.

References
---

[1] https://www.qubes-os.org/doc/how-to-update/
[2] https://www.qubes-os.org/doc/testing/
[3] https://xenbits.xen.org/xsa/advisory-452.html
[4] 
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/register-file-data-sampling.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/k12ftx2sIn61lWk8hgw4GoFAmXxsFQACgkQ1lWk8hgw
4GptDhAAm63FkT4jC++iZbU8JWgVtR2YEwIDRTKeYV6qerfFSr3QJxIu4OVesfwS
d0YOXDKmu3S0mbOIqcOk9BGkh1zSTbm3wQTkzPlnKdv7TOzS0GrRAmH6a6YCBoxC
UkpnRiQI8i5ABeYG4nDKg2Tv7qY76/cGsshnh4ntuXllV0TekwTjE89qHwcy9p5T
g0v7Jir6Wk+SBmAmxNatnfipdAiX/zlXdvHusCjRjbfdqh0e1/1Ho47nUj0GtRZV
fwXBZkG1QlxffEoTbwa6K9D3EMY6RdH9O/Z80DM7mD6UT/TTwZ1LlJ4gvk/Q/kjF
6Lsc7EEbgdi9oPsO69GJiUxYLFKXpmdH3KbqLGcHPzVluh93FJl0TpKEyINCB+xE
bUSWi5SZZXWmnmlrttef+S6K8vyYxdYmZq8uhG7Qzxt5EVlnWxTu2FFHrFNO0gB8
wBaqscABiGJ8VCXgVi8rgwdXOIThethXNSlptpu419l747w07DygSGEPkgKkSzt1
UqshFG9WM47o06UH/mGOrwSFYHwq1kA0m8s38wn0Qmw4V8wwnYq9bXA+ZO2QILIa
5B5yTEOCHpqqOCDAc+WopTiQFmJ9m5+dWYalSb2XcmPoIc21bHsYalWODFLr76Zv
Fj4Vxhb9Sp1DE3FfFpI78KG/4AZbv9nfwexy8Hpy6krRwzJxJSo=
=CgMr
-END PGP SIGNATURE-
```

*Source*: 


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

```
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEE6hjn8EDEHdrv6aoPSsGN4REuFJAFAmXxqpEACgkQSsGN4REu
FJAAmg/+JqRz8x1gF0bjKNSr38FWI2FgNg/DkmWw3cYtRiInobZejlvLy9vvX1ZL
yFYn/e4E0YIbhralqzmxYvE/dJ7DZdLQdJHODwJVk3QJT/DLrK65PmbAFxnof+wk
URWsouaQ0AAwAdWQCnTnlBHaKM8o/bdmcV9WbuSuKb64zJf2ciIU3iOQHPyxPj2Q
Whu8tg2JQZq6TVsVd6JcnD73ckQlkE58j8nyJP6WF4z5JfYvnCyzcgqbqDqabzbh
YhZyC5X8pNg5BVkX25xvun0NBj/P5NxeC1rcVTHK3XdYB8bBmoS6GobPC7T3jpCe
TQ8E2DbuAi5+oWZnMj8v0kdtNjezzP/9iWLsm865W6dczCMWZeh/nAs4aM6L1rG6
T7FogCV5lE9cVx3RqCPZpzAY9uaN0WryIZ/dLrmFbZR8T54UKWscmfWlak4TvBCS
1i3F2O4NgnzttaV/JW13hT9BUCMxc5uzYP/sRzw6zWGtxvQoSO+p3KmaFuscEhdt
tLNR5FAcmkbUUXg1uMOrrhfy5jEyLHretUzId3T9WPy9pnazcKnd6zT4HB6J+5bf

[qubes-users] Error updating Whonix Workstation 17

[Ulrich Windl]

I had updated the Whonix Workstation 17 successfully, but a System Check 
suggested that there are updates outstanding, so I tried another round:


Unfortunately there was an odd error:

...

Get:20 tor+https://deb.debian.org/debian bookworm-backports/main amd64 
Packages T-2024-03-12-0211.22-F-2024-02-23-1408.06.pdiff [19.4 kB]

Ign:18 https://deb.qubes-os.org/r4.2/vm bookworm InRelease
Ign:18 https://deb.qubes-os.org/r4.2/vm bookworm InRelease
Err:18 https://deb.qubes-os.org/r4.2/vm bookworm InRelease
  Something wicked happened resolving 'deb.qubes-os.org:https' (-4 - 
Non-recoverable failure in name resolution)

Fetched 566 kB in 15s (37.2 kB/s)
Reading package lists... Done
E: Failed to fetch 
https://deb.qubes-os.org/r4.2/vm/dists/bookworm/InRelease Something 
wicked happened resolving 'deb.qubes-os.org:https' (-4 - Non-recoverable 
failure in name resolution)
E: Some index files failed to download. They have been ignored, or old 
ones used instead.

zsh: exit 100   upgrade-nonroot


When retrying after a while, it worked!

--
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/1f19e92d-bace-490d-b6d1-24ee586a0f75%40gmail.com.

[qubes-users] Qubes Canary 038

[Andrew David Wong]

Dear Qubes Community,

We have published [Qubes Canary 
038](https://github.com/QubesOS/qubes-secpack/blob/main/canaries/canary-038-2024.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 038

```

---===[ Qubes Canary 038 ]===---


Statements
---

The Qubes security team members who have digitally signed this file [1]
state the following:

1. The date of issue of this canary is March 11, 2024.

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

3. The Qubes Master Signing Key fingerprint is:

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

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

5. We plan to publish the next of these canary statements in the first
   fourteen days of June 2024. 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, 11 Mar 2024 01:10:33 +

Source: DER SPIEGEL - International 
(https://www.spiegel.de/international/index.rss)
Jan Marsalek an Agent for Russia? The Double Life of the former Wirecard 
Executive
The Russian Invasion - A Visit to the Ukrainian Troops in the Trenches on the 
Front
The Marseille Experiment: Macron Attempts to Save a City Rocked by Drug Violence
How Vladimir Putin Controls the Russians: Everyday Repression and Resignation
A Visit to the Swamp: The Town Made Famous by Neo-Nazi Students

Source: NYT > World News 
(https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Israel Finds a Lifeline in the U.A.E. as Its Ties to Arab Countries Fray
Photo of Catherine, Prince of Wales, Manipulated, News Agencies Say
‘It’s a Way of Life’: Women Make Their Mark in the Ukrainian Army
China’s Growth Slows but Xi Jinping Keeps to His Vision
The Colombian Town That Gabriel García Márquez’s Legacy Helped Transform

Source: BBC News (https://feeds.bbci.co.uk/news/world/rss.xml)
Oscars 2024: Oppenheimer and Poor Things scoop early awards
Oscars red carpet fashion: Stars turn on the style
Ukraine criticises Pope's 'white flag' comment
Portugal vote too close to call as far right surges
Six skiers missing near Matterhorn in Swiss Alps

Source: Blockchain.info
7602e7b20b10a857d9222c78a375fe6334613dff2b60


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/k12ftx2sIn61lWk8hgw4GoFAmXuX3AACgkQ1lWk8hgw
4Goh5A//TkwqT8ryJY5ptnaQyrwx7MYC4NlfEe7OayOAxG+LFYQLmV+FOC471/bi
K1zZa4n5tJTGODuGNH/AwVwE02kmNpFSSgkL4KAGWk56OjpmhT27RS5DPYKz1URX
VMi+JD9Z84J4NfbPNtp39z7OoQaYI9GUwHnW45U5gfFduwzVlDvuy0LIjRTtO9Z3
6zWWqGZ1gdOBJZzOM2t8M9UE5suJzhyjBAavKq7yc4UGqHmV4T2AHUzFzCa9b8D1
z1Djo5QJondtcGH2XOZ50/8iEIKBysorjOqaXAjQPhWjxVlm/Bw/zSe5hLnTugcU
sto0wzdBOGWZR/NzC0+x2WxMH31IuRxl/YawrguEiH/Va3j+nsD9OM14kpxNBMc9

Re: [qubes-users] Windows 10 and Qubes OS Dualboot

['Marcelo' via qubes-users]

Hi one7two99,

I have Qubes and Linux already installed in different partitions in legacy 
mode and both work fine. Now I need to install windows 10 (to run Fusion 
360 for personal use). I don't want to install it as a qube as my hardware 
is not very powerful. I don't need Bitlocker. Could you please help? All 
info I've found is for installing qubes after windows.

Thanks
Regards

Marcelo

On Monday 27 January 2020 at 18:38:02 UTC-3 one7two99 wrote:

> Hello Maria,
>
> Yes it is perfectly possible to run Windows 10 and Qubes in a dual boot 
> environment.
>
> I have spent several hours when I was researching how to put everything 
> together but mainly because I wanted to have the following setup:
>
> - CoreBoot
>
> - Dualboot with Windows 10 and Qubes
>
> - Bitlocker Encryption (to be compliant to my corporate standards)
>
>
> As I often spent some time to get everything working like I want it to 
> be, I keep notes and those might also be a good starting point for you:
>
>
> https://github.com/one7two99/my-qubes/blob/master/docs/coreboot/howto-dualboot-qubes-win-coreboot-bitlocker.md
>
> If you need further help, do not hesitate to contact, I can also 
> translate my notes to english, if it will help you.
>
>
> Regarding a Laptop for Qubes I can and will always suggest the Lenovo 
> Thinkpad X230 with 16 GB RAM and a SSD. It is working perfect with 
> Qubes, can be Coreboot'ed and you can also plugin a LTE-card which will 
> also work great with Qubes.
>
> - one7two99
>
>
>

-- 
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/2f816b64-3140-43b4-bd80-8f7cb71e2d75n%40googlegroups.com.

Re: [qubes-users] 80x24 geometry used by qvm-console-dispvm

[qubist]

On Wed, 6 Mar 2024 14:48:54 -0800 Andrew David Wong wrote:

> I rejected it, because although it contains a "Why did you implement
> XYZ this way...?" question, the rest of the message implies a "How do
> I...?" request for help or support.

Well, it was rather "I am trying to modify existing functionality".
Anyway, thanks for clarifying. It's a blurry line I guess. :)

-- 
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/20240307080813.5cec4b2f%40localhost.

Re: [qubes-users] 80x24 geometry used by qvm-console-dispvm

[Demi Marie Obenour]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, Mar 07, 2024 at 01:52:58AM +0100, Marek Marczykowski-Górecki wrote:
> On Wed, Mar 06, 2024 at 06:16:03PM -0500, Demi Marie Obenour wrote:
> > On Wed, Mar 06, 2024 at 10:49:11PM +0100, Marek Marczykowski-Górecki wrote:
> > > On Wed, Mar 06, 2024 at 06:13:50PM +0100, Ulrich Windl wrote:
> > > > Haven't done it for ages, but can't you configure the size using X 
> > > > resources?
> > > > Like this:
> > > > Now to set the size of the console itself, you would add this to the 
> > > > ~/.Xresources file:xterm*geometry: 127x37
> > > 
> > > It isn't the problem of changing xterm window size. It's a problem of
> > > telling the target VM what the size is. You can probably do that
> > > manually by calling `stty cols W rows H` inside (after you resize the
> > > window), but I don't know how to make automatic. If anybody has some
> > > idea, patches welcome.
> > 
> > For PV consoles, I wonder if there should be a side-channel in the
> > protocol.
> 
> Maybe? I don't think there is one. BTW I think the same issue applies to
> a real serial console too. SSH has such side-channel. And AFAIR telnet
> does it in-band via some special bytes.

There isn’t one _right now_, hence me proposing that one should be
added.  I assume that it would be sufficiently simple that if we need to
do any conversions in dom0, those conversions could be done securely.
- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmXpFCwACgkQsoi1X/+c
IsHDuxAAn9xSU4nS2iIdbQbOWGyD6QCJUkgriuLdf5MXYXAvzVvJ039jSYlf8/yZ
AgRhHNhX5jBhXXV439sAL9Vv+uq6u8KGc1BMfYCzjBrS3HnwNqin8mex+ueF8LT9
l2nUYHr5XrCwclMYgJcD/hSmnx1J1dtKnih58Xz93Wc+GCmBo3tuomUIpFSPXORw
O0THhHyWGzmGzNH8w82EdISz9nkiSOcXXuoINRSO+piP2leXzDpnIURq3YlajGa8
7JdflPUkgKP5jSOCS7jNLonN/IuiMYyLRmsh5LNKTUQv97mMXNz4zvFjmaDGc5xm
0MGkYrg2Nsu4FdiEZMzdaucO1U4xKekBFzhWTSy6d8lytvlPDRH4p9UOvQWLJfFl
Wy21AoTHzaDBbob+voboBLaAiLbxEfPaAGVA3lzeLSCivexz2LKuXaKiuMJk0icZ
Xru/xJ2CerlZ+aldsutVhn9AI84aN4mjpPfy1Ngo7ijTWtxGxHBwYV1bGF5lrbCJ
ZUI20I3Q9TFWgiMDxRwRZXyg+vSXIJRVW2kSHlGJP4IWRTuBeIlOM9BoNVuXSLFH
0GnQBAZQoiq+1MvCvZFx2R46h9Ne0ByWaPas7cTQ8t8kNwdPZz255wfzcu1JOBMA
t4KJ9MVA2xPxaYM6Y+gOTbhPWXhCzaEAIlZxvw228Yazbxm67BU=
=ErqT
-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/ZekUK_wgASUIjqHo%40itl-email.

Re: [qubes-users] 80x24 geometry used by qvm-console-dispvm

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Mar 06, 2024 at 06:16:03PM -0500, Demi Marie Obenour wrote:
> On Wed, Mar 06, 2024 at 10:49:11PM +0100, Marek Marczykowski-Górecki wrote:
> > On Wed, Mar 06, 2024 at 06:13:50PM +0100, Ulrich Windl wrote:
> > > Haven't done it for ages, but can't you configure the size using X 
> > > resources?
> > > Like this:
> > > Now to set the size of the console itself, you would add this to the 
> > > ~/.Xresources file:xterm*geometry: 127x37
> > 
> > It isn't the problem of changing xterm window size. It's a problem of
> > telling the target VM what the size is. You can probably do that
> > manually by calling `stty cols W rows H` inside (after you resize the
> > window), but I don't know how to make automatic. If anybody has some
> > idea, patches welcome.
> 
> For PV consoles, I wonder if there should be a side-channel in the
> protocol.

Maybe? I don't think there is one. BTW I think the same issue applies to
a real serial console too. SSH has such side-channel. And AFAIR telnet
does it in-band via some special bytes.

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXpD+oACgkQ24/THMrX
1yxnhAf/bzFwsUtwDb0Ylu+aSE96wkboLAbWFqPFUAr3fagrTek4N6uACLw4MRdo
j6wPGg5G5dvJZlSa6K3UDbjJamQzPazHzk+SN0ROX+AkixlF0eiEMcl3Tg14PZCr
9Xx+lE+MMtCvaWjKO4xWxKY8K4jAMU8foQlQsFftWKgCBBneQGoqjQDYyuALhfCO
bU+Nem9hBDg7WCDpLeEc1emtYSLWkBDvTyz3HhmyopfbVxBE5EM6WQSNUSGaeRap
ejK/xtfjxspxO3IfT6GWllIoAKdMr3u4xNJEQkqOm/AWIXSOJ/wvJ/boioqKbtQA
LxvXhjhvSMYkfO4qtFn7uty6DE4prA==
=nyiP
-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/ZekP6uoxgl_WEz3N%40mail-itl.

Re: [qubes-users] 80x24 geometry used by qvm-console-dispvm

[Demi Marie Obenour]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, Mar 06, 2024 at 10:49:11PM +0100, Marek Marczykowski-Górecki wrote:
> On Wed, Mar 06, 2024 at 06:13:50PM +0100, Ulrich Windl wrote:
> > Haven't done it for ages, but can't you configure the size using X 
> > resources?
> > Like this:
> > Now to set the size of the console itself, you would add this to the 
> > ~/.Xresources file:xterm*geometry: 127x37
> 
> It isn't the problem of changing xterm window size. It's a problem of
> telling the target VM what the size is. You can probably do that
> manually by calling `stty cols W rows H` inside (after you resize the
> window), but I don't know how to make automatic. If anybody has some
> idea, patches welcome.

For PV consoles, I wonder if there should be a side-channel in the
protocol.
- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmXo+TMACgkQsoi1X/+c
IsHNShAAn9edCHCMdfv5wO9UzhBcf3uAwK5TdlW0bD3Zy9rDZcmkk8wN8NIHsc0V
CQxvoGUYrSYHR4i3y+49rMG3MUUvSIqVMinjNyMskapWZeLqr7KIU+EhA03Vr6lG
kS0xkamCNvOP5copx7G9A655c5cpxGOxitGxyC4iP6RhBhiUSWqxmo9m6sPPFwV4
qa/a28KEIC6e8d0FxEDGk6y7QqyA/oXCrLg5BgY9odPOj4W4Y1ABqldpREoITeQZ
e3H5rnRJnKd7qcHjz3iz9r0PxG6InFOZPf7+7MfF83zvlTSHYCGVtkiHbBtxjBI1
Q/O0UjWXDpsOV/RSiuTGXld4OG56Q+ZG/RUROS+PuGpQVIfV4Ex4sl/qj2ttDvxp
+sUTdiWB76E6PYtxVEZRkYwSTN+Y0F9xw/aUoejNNZk+DGJgOj9p62WrLRTLQU/e
9hAv+8Wd9ew04wJkxNlAMFm/plKpVAb88DJFHSsNGDcC6+RTKFkioqAtli71Yd63
mEReuX+VbBo6kWHEPCDYYjwgf6dmorEvbAKqJUNOvUX2jI3kCavYkgPlH9dgAF7Q
tMZ/kupyfy4F/KGzAO76275ZzeyiMhePuKLnXEey31PTs246Z1HRHtUJMABnJulO
JJxNPLE1IEuUpCqmO8AZo4yT6PzcY7L9r63QN0D3G6XNMZH0yh0=
=HeWx
-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/Zej5M30rCvKJBnfZ%40itl-email.

Re: [qubes-users] 80x24 geometry used by qvm-console-dispvm

[Andrew David Wong]

On 3/6/24 10:37 AM, qubist wrote:
> On Wed, 6 Mar 2024 18:14:53 +0100 Marek Marczykowski-Górecki wrote:
> 
>> The way that console works does not support sending information about
>> window size (changes).
> 
> Do I understand correctly there is no way to change it and it is
> impossible, hence not planned?
> 
> 
>> You must subscribe to qubes-devel mailing list to post there.
> 
> I am subscribed. I was subscribed at the time of posting it, yet it was
> explicitly rejected:
> 
> On Tue, 05 Mar 2024 14:26:01 -0800 Google Groups wrote:
> 
>> Google Groups (https://groups.google.com/d/overview)
>>
>> Unfortunately, your recent post to the qubes-devel  
>> (https://groups.google.com/d/forum/qubes-devel) group
>> was rejected by a group owner or manager.
>>
>> Message from the group owner or manager:
>> Your message to the qubes-devel group has been rejected. For more  
>> information, please see:
>>
>> https://www.qubes-os.org/support/
>>
>> You may wish to send your message to the qubes-users mailing list
>> instead:
>>
>> https://www.qubes-os.org/support/#qubes-users
>>
>> Possible reasons your post was rejected include:
>>* Your post was more relevant to a different group or conversation.
>>* Your post did not conform to the posting guidelines of this
>> group.
>>* Your post needs more information.
>>
>> Google Groups allows you to create and participate in online forums
>> and email-based groups with a rich community experience. You can also
>> use your Group to share documents, pictures, calendars, invitations,
>> and other resources.
>>
>>
>> Visit Google Groups Help Center at  
>> https://support.google.com/groups/answer/46601?hl=en.
> 

I rejected it, because although it contains a "Why did you implement XYZ this 
way...?" question, the rest of the message implies a "How do I...?" request for 
help or support.

-- 
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/2a9c8788-b988-4da4-8fef-de839c947c1a%40qubes-os.org.

Re: [qubes-users] 80x24 geometry used by qvm-console-dispvm

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Mar 06, 2024 at 06:13:50PM +0100, Ulrich Windl wrote:
> Haven't done it for ages, but can't you configure the size using X resources?
> Like this:
> Now to set the size of the console itself, you would add this to the 
> ~/.Xresources file:xterm*geometry: 127x37

It isn't the problem of changing xterm window size. It's a problem of
telling the target VM what the size is. You can probably do that
manually by calling `stty cols W rows H` inside (after you resize the
window), but I don't know how to make automatic. If anybody has some
idea, patches welcome.

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXo5NcACgkQ24/THMrX
1yys0Qf6AmYB8Z7OIahL8zabnZ+RZkGc+YmJNcAnxeayFDBBkbOXjuNqKUSvCJ8w
1sKGOiV03tZzztfxMLqZvf03xjLz8l9807t15fFtjXD/pfJDts35nFcGYsLw9zZz
j4KjDbJNZNgxgxS1URKh3X3KNR1lCSEhGjI0z3ZWjTHC0MYebOSOfjoe3vSg1Gj9
xTQy4i+yxZkFJ4kuo1vCIyah/K1oY8UetjwCtvmfYbLf7QbXrqqLgb9YZXAWOjox
faSTtl4HNLNf3DBgAJrgKQFygqfb7B825yFwCOTWdBrRnXg7L3OidIDu52lbrZMQ
YRaShECp/WzRrHmQQcds2exx9hDcMw==
=3kg0
-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/Zejk154ohmR-bei6%40mail-itl.

Re: [qubes-users] 80x24 geometry used by qvm-console-dispvm

[qubist]

On Wed, 6 Mar 2024 18:14:53 +0100 Marek Marczykowski-Górecki wrote:

> The way that console works does not support sending information about
> window size (changes).

Do I understand correctly there is no way to change it and it is
impossible, hence not planned?


> You must subscribe to qubes-devel mailing list to post there.

I am subscribed. I was subscribed at the time of posting it, yet it was
explicitly rejected:

On Tue, 05 Mar 2024 14:26:01 -0800 Google Groups wrote:

> Google Groups (https://groups.google.com/d/overview)
> 
> Unfortunately, your recent post to the qubes-devel  
> (https://groups.google.com/d/forum/qubes-devel) group
> was rejected by a group owner or manager.
> 
> Message from the group owner or manager:
> Your message to the qubes-devel group has been rejected. For more  
> information, please see:
> 
> https://www.qubes-os.org/support/
> 
> You may wish to send your message to the qubes-users mailing list
> instead:
> 
> https://www.qubes-os.org/support/#qubes-users
> 
> Possible reasons your post was rejected include:
>* Your post was more relevant to a different group or conversation.
>* Your post did not conform to the posting guidelines of this
> group.
>* Your post needs more information.
> 
> Google Groups allows you to create and participate in online forums
> and email-based groups with a rich community experience. You can also
> use your Group to share documents, pictures, calendars, invitations,
> and other resources.
> 
> 
> Visit Google Groups Help Center at  
> https://support.google.com/groups/answer/46601?hl=en.

-- 
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/20240306183705.48152996%40localhost.

Re: [qubes-users] 80x24 geometry used by qvm-console-dispvm

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Mar 06, 2024 at 03:42:23PM -, qubist wrote:
> Hello,
> 
> What is the reason for the '80x24' geometry of xterm used by
> qvm-console-dispvm through the management_dispvm?
> 
> I tried to remove the option in the policy file in order to utilize the
> full available workspace, as well as to change it to a bigger window,
> but in both cases it just stops working.

That's the standard terminal size that various tools assume in lack of
other information. Technically you can use bigger window, but tools like
vim or top will still assume it's 80x24. The way that console works does
not support sending information about window size (changes).

> P.S. I posted that initially in qubes-devel because it fits completely
> the "Why did you implement XYZ this way and not the other way?" example
> in https://qubes-os.org/support/ but it was rejected. Quite confusing.

You must subscribe to qubes-devel mailing list to post there.

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXopI0ACgkQ24/THMrX
1yy46gf9FCrYbcTkY9BYGOVSY9JUSU2d7XAdflrQeL+uQIVljhXTLBA9iN3P3euW
lO+1AVNIpEgt+hwwAfd3A75EHt/zbXw6xjdxDZxo/aXqvjFl3OHffT39hViNCr20
HtFNH9DsonCvc08TmGxbPQsIGpQFhdEI8hr26AQ//MnJrfCNUjUIUpcCmmbirAII
bZZTHMdIWaa5yD5lWiCtaCdo0tmzxJzHRswGHyJBCQy8wynH3QMwMEXfAdm6bWk/
eInWbarRBRwJX9fuR+xJfyMlJar0YQhFqkNf5LRgReNnC+y9nZjizdWoqxb94mSg
C5H5VEzS3BZj0eEVRHK2erIDeodtCQ==
=RdnV
-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/ZeikjeH0dPBxAvjj%40mail-itl.

[qubes-users] 80x24 geometry used by qvm-console-dispvm

[Ulrich Windl]

Haven't done it for ages, but can't you configure the size using X resources?
Like this:
Now to set the size of the console itself, you would add this to the 
~/.Xresources file:xterm*geometry: 127x37

-- 
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/179f126d-075b-4261-99d9-bdd465f7e64e%40gmail.com.

[qubes-users] 80x24 geometry used by qvm-console-dispvm

[qubist]

Hello,

What is the reason for the '80x24' geometry of xterm used by
qvm-console-dispvm through the management_dispvm?

I tried to remove the option in the policy file in order to utilize the
full available workspace, as well as to change it to a bigger window,
but in both cases it just stops working.



P.S. I posted that initially in qubes-devel because it fits completely
the "Why did you implement XYZ this way and not the other way?" example
in https://qubes-os.org/support/ but it was rejected. Quite confusing.

-- 
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/20240306154223.450b2348%40localhost.

[qubes-users] Re: HCL - Dell Inspiron 5570 (P75F, P75F001)

[Anirban Kar]

My, Dell Inspiron 15 5570 has i5 8250, 12GB DDR RAM , 1TB SATA HDD. I have 
created a bootable Qubes 4.2.0 with dd command in Ubuntu and trying to boot 
my Dell Inspiron with it. However it is failing to boot and restarting and 
falling back to Ubuntu 23.10. Should I try to boot in legacy BIOS mode ? 
Currently I am trying to boot in UEFI mode with Secure Boot and PTT (TPM) 
enabled. To boot in Legacy BIOS mode I have to disable Secure Boot and 
PTT(TPM). Please advice.

On Saturday 5 January 2019 at 06:11:11 UTC+5:30 rex mat wrote:

> Need mouse to install. Install base system (not usbvm, whonix etc.), add 
> those later from packages. Ethernet must be active at startup, does not 
> detect cable plug-in. Slow (8 Gb, rotating hd, i5), but works.
>
>
> Citromail.hu levelezőrendszerből küldve
> Lépj be  vagy regisztrálj 
>  

-- 
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/bcb8ca66-1613-4c90-b10e-33b19fddc502n%40googlegroups.com.

Re: [qubes-users] HCL - Beelink SER5 Ryzen 7 5800H AMD Integrated Graphics (RX Vega 8)

['bozoslivehere' via qubes-users]

Suspend works
On Monday, March 4th, 2024 at 2:33 PM, 'bozoslivehere' via qubes-users 
 wrote:

> ---layout:
>   'hcl'
> type:
>   'Mini PC'
> hvm:
>   'yes'
> iommu:
>   'yes'
> slat:
>   'yes'
> tpm:
>   '2.0'
> remap:
>   'yes'
> brand: |
>   AZW
> model: |
>   SER
> bios: |
>   5800H603
> cpu: |
>   AMD Ryzen 7 5800H with Radeon Graphics
> cpu-short: |
>   FIXME
> chipset: |
>   Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne Root Complex [1022:1630]
> chipset-short: |
>   FIXME
> gpu: |
>   Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [Radeon Vega Series / Radeon 
> Vega Mobile Series] [1002:1638] (rev c5) (prog-if 00 [VGA controller])
> gpu-short: |
>   FIXME
> network: |
>   Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit 
> Ethernet Controller [10ec:8168] (rev 15)
>   Intel Corporation Wi-Fi 6 AX200 [8086:2723] (rev 1a)
> memory: |
>   29618
> scsi: |
> 

> usb: |
>   4
> certified:
>   'no'
> versions:
>   - works:
>       'FIXME:yes|no|partial'
>     qubes: |
>       R4.2.0
>     xen: |
>       4.17.2
>     kernel: |
>       6.1.62-1
>     remark: |
>       FIXME
>     credit: |
>       FIXAUTHOR
>     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/gbc92TxqDjODOV7Paes3zsLMjLiaQ1rTcC9qg6bK8k8PKyQ3bxOJLrli4QgnVJ6mOzSAoUHRRgCGgNXlqzVtn0QP_FRvRUY0SWZMPhM78i4%3D%40protonmail.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/EGB9Fy7Bx8dUd9xqNv11QMV4_1IZ0NgwuH5bxjWQJcyhD3ANVb1h-sTcc71pImk-bFxiVeEzsc53_bwRYcys2wW79tI-MdkY96T-M4p1YhE%3D%40protonmail.com.


publickey - bozoslivehere@protonmail.com - 0x25C30629.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

[qubes-users] HCL - Beelink SER5 Ryzen 7 5800H AMD Integrated Graphics (RX Vega 8)

['bozoslivehere' via qubes-users]

---layout:
  'hcl'
type:
  'Mini PC'
hvm:
  'yes'
iommu:
  'yes'
slat:
  'yes'
tpm:
  '2.0'
remap:
  'yes'
brand: |
  AZW
model: |
  SER
bios: |
  5800H603
cpu: |
  AMD Ryzen 7 5800H with Radeon Graphics
cpu-short: |
  FIXME
chipset: |
  Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne Root Complex [1022:1630]
chipset-short: |
  FIXME
gpu: |
  Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [Radeon Vega Series / Radeon 
Vega Mobile Series] [1002:1638] (rev c5) (prog-if 00 [VGA controller])
gpu-short: |
  FIXME
network: |
  Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit 
Ethernet Controller [10ec:8168] (rev 15)
  Intel Corporation Wi-Fi 6 AX200 [8086:2723] (rev 1a)
memory: |
  29618
scsi: |

usb: |
  4
certified:
  'no'
versions:
  - works:
      'FIXME:yes|no|partial'
    qubes: |
      R4.2.0
    xen: |
      4.17.2
    kernel: |
      6.1.62-1
    remark: |
      FIXME
    credit: |
      FIXAUTHOR
    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/gbc92TxqDjODOV7Paes3zsLMjLiaQ1rTcC9qg6bK8k8PKyQ3bxOJLrli4QgnVJ6mOzSAoUHRRgCGgNXlqzVtn0QP_FRvRUY0SWZMPhM78i4%3D%40protonmail.com.


Qubes-HCL-AZW-SER-20240302-173628.yml
Description: application/yaml


publickey - bozoslivehere@protonmail.com - 0x25C30629.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

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

[Andrew David Wong]

Dear Qubes Community,

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

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

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-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/0a4b53ec-6449-4dec-a084-2c0f67ec1a1a%40qubes-os.org.

Re: [qubes-users] Ethernet socket device not available in Network Connections

['unman' via qubes-users]

[quote] 
my sys-net is also sys-usb because I used the USB ethernet adapter so I
think this is the problem but I don't know how to fix.
[/quote]
I doubt that this is the problem.
Have you assigned the device to sys-net in the "devices" tab of sys-net
settings.
When sys-net boots up, can you run `sudo journalctl -b ` in sys-net and look for
any entries relating to networking devices.
It may be that you need specific drivers for the NIC, so knowing what it
is would be a help.

-- 
I never presume to speak for the Qubes team.  
When I comment in the mailing lists I speak for 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/ZeO5oqfRsyO49pVY%40thirdeyesecurity.org.

[qubes-users] Ethernet socket device not available in Network Connections

[alesser]

I was using USB ethernet adapter before, but now I have enabled my 
laptop's own Gb socket and I would like to use this.


The device is listed in lspci:

> Ethernet controller: Intel Corporation Ethernet Connection blabla

The device is not listed in Network Connections application. The only 
device there is `vif`.


I know this device is working in Ubuntu which I am using before.

my sys-net is also sys-usb because I used the USB ethernet adapter so I 
think this is the problem but I don't know how to fix.


--
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/d50f5b93-e244-4423-900d-34469b414478%40magenta.de.

[qubes-users] Where to run undervolt script?

[alesser]

What is the safest way to use undervolt script in Qubes?

https://github.com/georgewhewell/undervolt.git

This is running on Python. Is it better to use new service qube for this 
or can I run it in dom0/sys-net/sys-firewall?


--
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/85e151b0-3709-441a-9f13-f17abf07ed1a%40magenta.de.

Re: [qubes-users] Screen sleep doesn't disable backlight

[alesser]

Neil du Preez:

On 2024-02-24 16:19, ales...@magenta.de wrote:

On Qubes 4,2, when the screen goes to sleep after idle time or when I lock
the screen, the screen is black but the backlight is still on. Only when the
system goes to Suspend is the backlight turned off. How can I fix this?


Hi,

I have attached screenshots of xscreensaver and power manager settings
that work for me. I discovered them long ago through trial and error,
but I don't remember what other combinations worked and didn't.

Hope it helps.



Yes this helps. Now Lock Screen backlight is off but I didn't try idle 
sleep yet.


--
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/bea24b39-9098-442e-a66c-65286d093038%40magenta.de.

Re: [qubes-users] Qubes 4.2 error: Failed to remove old efi boot entry.

[alesser]

Neil du Preez:

On 2024-02-24 16:02, ales...@magenta.de wrote:

In my fresh install of 4.2 this error appeared.


The following error occurred while installing the boot loader. The system

will not be bootable.

Would you like to ignore this and continue with installation?
Failed to remove old efi boot entry. This is most likely a kernel or

firmware bug.

But it would be nice to understand why this happens and how to fix it.


You might have a setting in your BIOS that prevents boot entries from
being removed.



I think you are right, there is the option "boot order lock" enabled in 
the BIOS. I will try to use efibootmanager to fix this after I have 
disabled this setting.


Thank you for the suggestion!

--
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/8640d9b9-8b29-484d-90bd-e1f163193749%40magenta.de.

[qubes-users] Qubes 4.2: Attach usb audio device to appvm

['Rune Philosof' via qubes-users]

After upgrading to 4.2 my audio device does not work.

I plug in a usb audio device, then attach that usb device to an appvm and 
try to use it in e.g. meet.google.com.
For some reason it only works for the audio microphone or the speaker, not 
both.
Example:
1. I attach the usb device to the appvm.
2. meet.google.com automatically switches to the new microphone, but I 
cannot hear anything and the speaker list does not show the usb device.
3. I then detach from the appvm and reattach the usb device to the same 
appvm.
4. meet.google.com does not show the usb device in the list of microphones. 
but somehow the "default" speaker now outputs through the usb device.

In 4.1 it would either work for both mic and speaker or for none.

-- 
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/bff4746d-a10d-482a-a913-dc82cf5e1ab6n%40googlegroups.com.

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

[Andrew David Wong]

Dear Qubes Community,

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

## XSAs that DO affect the security of Qubes OS

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

- (none)

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

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

- [XSA-451](https://xenbits.xen.org/xsa/advisory-451.html)
  - Denial of service (DoS) only

## About this announcement

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-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/d21b067f-877f-4fb7-8625-8a31c04616a4%40qubes-os.org.

[qubes-users] [Qubes 4.1] issue with thunderbird after recent debian update

['haaber' via qubes-users]

Hi,

since a recent update, thunderbird throws artefacts on xfce screen
(parts of its menu), that spawn virtual screen, survive log off & on
again, but disappear if VM is closed. And re-appear when thunderbird is
restarted. Very annoying! Am I alone with this type of glitch?


Thanks, 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/2fd0bfee-864c-4c14-a6d6-7200144fe994%40web.de.

Re: [qubes-users] 4.2 issue with pam_sss.so

[David Hobach]

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

--
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/de7bbcbf-e17b-4c36-bd4b-07c53b87d81d%40hackingthe.net.


OpenPGP_0x08DEA51AE90C3780.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] 4.2 issue with pam_sss.so

[Manuel Amador (Rudd-O)]

Install sssd_client package and it goes away.

On January 20, 2024 1:26:00 AM GMT+01:00, Ulrich Windl  
wrote:
>Hi!
>
>
>I just noticed these messages (in my upgraded Qubes OS):
>
>Jan 20 01:22:39 dom0 sudo[25013]: PAM unable to 
>dlopen(/usr/lib64/security/pam_sss.so): /usr/lib64/security/pam_sss.so: cannot 
>open shared object file: No such file or directory
>Jan 20 01:22:39 dom0 sudo[25013]: PAM adding faulty module: 
>/usr/lib64/security/pam_sss.so
>
>Am I the only one to see them?
>
>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/c0dcefc4-dba7-4a3c-9085-262408f33872%40gmail.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/0206D65D-4C02-414C-A7C4-FD9D9A98653E%40rudd-o.com.

Re: [qubes-users] issue with URL handler in Thunderbird: started VM receives truncated URL

[Manuel Amador (Rudd-O)]

I have this you can use:

https://github.com/Rudd-O/qvm-open-in-another-vm

After building the package and installing it in the template, you can 
shut off the template, restart the qube where you want to configure link 
clicks to launch in another qube, and follow these instructions:


https://github.com/Rudd-O/qvm-open-in-another-vm?tab=readme-ov-file#how-set-urls-to-open-in-a-separate-vm

With that, any link you click on a non-browser app will prompt you to 
open the link in any qube of you choice.


On 23/02/2024 20.57, 'Skyler Ferris' via qubes-users wrote:

[quote="Ulrich_Windl1, post:8, topic:24602"]
I kind of disagree: When passing the URL as "$1", it is passed as one
single parameter. The user cannot be expected to know to how much more
levels of shell script the parameter will be passed to, so any deeper
layers have to keep the single parameter. That is: Every layer of shell
script may not remove one level of quotes. Anything else is just an
unreliable mess IMHO.
[/quote]

I want to make sure we're on the same page about exactly why the quotes
are removed, because it sounds like you're attributing this to
`qvm-run-vm`, when in fact it is the bash invocation in the script itself.

When bash (as in, the instance of bash spawned by the `#!/bin/bash` at
the top of the `run-vm-firefox` script) reads the line `qvm-run-vm
'$dispvm' /bin/firefox "$1"`, it interprets the quotes to mean "this is
one single argument and the quotations are not a part of that argument".
So the script does not send the quotation marks to `qvm-run-vm`. It
could quote all arguments automatically and there are good
justifications for doing so but it would not be a strict improvement.
For example, even with double quotes globbing is disabled and some
callers might want to use this feature.

[quote="Demi, post:7, topic:24602"]
I suggest escaping single quotes in the $1 and adding a "--" before it.
This prevents command injection attacks via a malicious URL.

So the result might be

```bash
#!/bin/bash --
exec qvm-run-vm @dispvm /bin/firefox -- "'${1//\'/\'\\\'\'}'"
```
[/quote]

I believe this is a script improvement. The URL is not trusted data and
these safeguards do not have an impact on valid inputs.



--
Rudd-O
https://rudd-o.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/dd2497e1-b86c-4d88-b782-90dacdb1fcaf%40rudd-o.com.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Qubes 4.2 error: Failed to remove old efi boot entry.

[Neil du Preez]

On 2024-02-24 16:02, ales...@magenta.de wrote:
> In my fresh install of 4.2 this error appeared.
> 
> > The following error occurred while installing the boot loader. The system
> will not be bootable.
> > Would you like to ignore this and continue with installation?
> > Failed to remove old efi boot entry. This is most likely a kernel or
> firmware bug.
> 
> I ignored this and I was able to boot 4.2 with rEFInd so I have no problem.
> But it would be nice to understand why this happens and how to fix it.

You might have a setting in your BIOS that prevents boot entries from
being removed.

I once had the opposite error where the installer failed to create the
entry. Adding an entry manually with efibootmgr didn't work initially
either, I had to clear the CMOS before I could add an entry. It also
turned out that the efibootmgr command in this section of the docs is
outdated:

https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-finished-but-qubes-boot-option-is-missing-and-xencfg-is-empty--installation-fails-with-failed-to-set-new-efi-boot-target

The .efi file path was different and the "placeholder /mapbs /noexitboot"
part wasn't needed in my case.

Luckily I had another working Qubes machine where I could dump a working
efibootmgr entry and configure the machine accordingly:

Boot0001* Qubes OS 
HD(1,GPT,REDACTED,REDACTED,REDACTED)/File(\EFI\qubes\grubx64.efi)

I haven't had time to submit a pull request to update the docs.

-- 
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/ZdrgrbF5YoPaXaai%40localhost.