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

2021-11-30 Thread Andrew David Wong

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

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

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

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

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

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

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

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

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


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


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

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


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

In particular, Marek commented (on #4378):

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

New signatures are made with SHA256 hash function."


If so, why not distribute a new one?



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


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




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


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



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

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

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





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

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


Re: [EXT] Re: [qubes-users] dnf remove lies to me (removing whonix-15 templates)

2021-11-30 Thread Ulrich Windl

On 11/21/21 9:39 PM, 'awokd' via qubes-users wrote:

Ulrich Windl:

qvm-template-postprocess: error: No Qube with this name exists


Maybe try to fake it out by cloning some other template to 
"whonix-ws-15", then run again?




Hmm: The template is no longer visible in Qubes Mangager (I think I had 
deleted it from there).


[master@dom0 ~]$ rpm -ql 
qubes-template-whonix-ws-15-4.0.1-201910102356.noarch

/var/lib/qubes/vm-templates/whonix-ws-15
/var/lib/qubes/vm-templates/whonix-ws-15/apps
/var/lib/qubes/vm-templates/whonix-ws-15/apps.tempicons
/var/lib/qubes/vm-templates/whonix-ws-15/apps.templates
/var/lib/qubes/vm-templates/whonix-ws-15/clean-volatile.img.tar
/var/lib/qubes/vm-templates/whonix-ws-15/icon.png
/var/lib/qubes/vm-templates/whonix-ws-15/netvm-whitelisted-appmenus.list
/var/lib/qubes/vm-templates/whonix-ws-15/private.img
/var/lib/qubes/vm-templates/whonix-ws-15/root.img
/var/lib/qubes/vm-templates/whonix-ws-15/root.img.part.00
/var/lib/qubes/vm-templates/whonix-ws-15/root.img.part.01
/var/lib/qubes/vm-templates/whonix-ws-15/root.img.part.02
/var/lib/qubes/vm-templates/whonix-ws-15/vm-whitelisted-appmenus.list
/var/lib/qubes/vm-templates/whonix-ws-15/volatile.img
/var/lib/qubes/vm-templates/whonix-ws-15/whitelisted-appmenus.list
[master@dom0 ~]$ rpm -V 
qubes-template-whonix-ws-15-4.0.1-201910102356.noarch

missing /var/lib/qubes/vm-templates/whonix-ws-15
missing /var/lib/qubes/vm-templates/whonix-ws-15/apps
missing /var/lib/qubes/vm-templates/whonix-ws-15/apps.tempicons
missing /var/lib/qubes/vm-templates/whonix-ws-15/apps.templates
missing /var/lib/qubes/vm-templates/whonix-ws-15/clean-volatile.img.tar
missing /var/lib/qubes/vm-templates/whonix-ws-15/icon.png
missing 
/var/lib/qubes/vm-templates/whonix-ws-15/netvm-whitelisted-appmenus.list

missing /var/lib/qubes/vm-templates/whonix-ws-15/root.img.part.00
missing /var/lib/qubes/vm-templates/whonix-ws-15/root.img.part.01
missing /var/lib/qubes/vm-templates/whonix-ws-15/root.img.part.02
missing 
/var/lib/qubes/vm-templates/whonix-ws-15/vm-whitelisted-appmenus.list
missing 
/var/lib/qubes/vm-templates/whonix-ws-15/whitelisted-appmenus.list


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/965ee31e-dbee-8a91-3f2f-63ed0f810317%40rz.uni-regensburg.de.


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

2021-11-30 Thread Ulrich Windl

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

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

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

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

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

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

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

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


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


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

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


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

In particular, Marek commented (on #4378):

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

New signatures are made with SHA256 hash function."


If so, why not distribute a new one?



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


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




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

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

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



--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/50280468-944c-348a-794f-a6b1b1c4dc86%40rz.uni-regensburg.de.


Re: [EXT] Re: [qubes-users] XSAs released on 2021-11-23

2021-11-30 Thread Ulrich Windl

On 11/27/21 11:03 AM, 'awokd' via qubes-users wrote:

Qubes:

Is there Qubes documentation outlining the steps to increase the size 
of /boot, or does one follow general disk management, with tools like 
using GParted for example. Although the disk is a LUKS encrypted 
volume. Can one decrypt, use GParted to resize, and then encrypt again?


Note that /boot itself is not encrypted, but you're right, you would 


Since GRUB can load LUKS-encrypted /boot, one could even encrypt /boot, 
but a part of GRUB is also encrypted then, it seems. At least there 
isn't much GRUB functionality until the LUKS volume is unlocked.
And it seems you only have one attempt to enter the passphrase 
correctly. Also GRUB decryption seems much slower than kernel decryption...


have to decrypt the rest to resize it. No Qubes specific docs. Procedure 
you describe should work, but might be further ahead by backing up your 
VMs to a removable encrypted drive, doing a fresh install of R4.1 (rc2 
last I saw) and adjusting the boot partition size on the installer 
screen, then restoring?




--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/492c9a9c-e566-38c1-bb6d-81fd792282db%40rz.uni-regensburg.de.


Re: [EXT] Re: [qubes-users] XSAs released on 2021-11-23

2021-11-30 Thread Ulrich Windl

On 11/26/21 3:47 PM, Qubes wrote:

'awokd' via qubes-users wrote:

Qubes:


And that is it. When I run update from CLI I get this,

"Error Summary
-
Disk Requirements:
    At least 33MB more space needed on the /boot filesystem."

Is that normal behavior? The disk /boot lives on is not full, the 
complaint is with /boot specific.


What does "df -h" say about /boot? If it's full and you've been 
updating the system for a while, check for old EFI images that haven't 
been cleaned up.




df -h shows /boot is full, 100% used.

I am not sure how to fix this, can you please give me advice?

Looking at ls -l for /boot I can see a lot of old images, but I guess 
that is because I have set my system to keep 15 kernels. However, I have 


Interestingly I see three kernels (and corresponding initramfs) here, 
but only one Xen version. So it seems kernels have versioning, but not Xen.

Of my 700MB /boot 41% (283MB) are used.

been on the 5.xxx kernel now since it was launched so I can safely 
remove the 4. kernels. How does one clean this up properly. If I 
just delete the files from /boot the system may still think they are 
there, is there a built-in process/procedure to follow for this?




--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7b6775ba-b76d-5908-3ffc-e0c1013b8984%40rz.uni-regensburg.de.


[qubes-users] Fedora 33 has reached EOL

2021-11-30 Thread Andrew David Wong

Dear Qubes Community,

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

We provide fresh Fedora 34 template packages through the official Qubes
repositories, which you can install in dom0 by following the standard
installation instructions [4]. Alternatively, we also provide
step-by-step instructions for performing an in-place upgrade [5] of an
existing Fedora template. After upgrading your templates, please
remember to switch all qubes that were using the old template to use
the new one [6].

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

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

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


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

[2] https://fedoraproject.org/wiki/End_of_life
[3] https://www.qubes-os.org/doc/templates/fedora/#upgrading
[4] https://www.qubes-os.org/doc/templates/fedora/#installing
[5] https://www.qubes-os.org/doc/template/fedora/upgrade/
[6] https://www.qubes-os.org/doc/templates/#switching
[7] https://www.qubes-os.org/doc/supported-releases/#templates
[8] https://www.qubes-os.org/doc/supported-releases/#note-on-dom0-and-eol

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/11/30/fedora-33-eol/

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

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


Re: [qubes-users] Verifying signatures

2021-11-30 Thread Andrew David Wong

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

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

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

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

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


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


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

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


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

In particular, Marek commented (on #4378):

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

New signatures are made with SHA256 hash function."


If so, why not distribute a new one?



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


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

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

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

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

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