Re: [EXT] Re: [qubes-users] Verifying signatures
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)
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
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
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
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
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
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.