Re: [qubes-users] qubes packages in Archlinux AUR repo
On Tue, Aug 31, 2021 at 07:38:33AM +0800, rss+qu...@armor-mail.com wrote:
> Hi unman,
>
> > I cant help with the AUR.
> > I build Arch packages for 4.0 and 4.1, and update them probably twice
> > a month ( other constraints permitting)
>
> Thanks very much for doing that, my Arch template originally came from
> your repo.
>
> > You can pick up templates and packages at https://qubes.3isec.org
> > unman
>
> I imported your package signing key with pacman-key ("pacman-key
> --finger unman" finds the key just fine) but if I try to do an upgrade
> (pacman -Syu) I get (transcribed so there may be typos):
>
> error: qubes-r4.0: signature from "unman (Qubes OS Signing Key)
> " is invalid
>
> Any thoughts? (I think I hit this iceberg before, and that is why I
> have been using the AUR packages.)
>
I've just confirmed that this works fine for me.
Can you try downloading the key from the Ubuntu keyserver, and checking against
the details at my GitHub account?
"Signature is invalid" - strange error. Is your date/time correct?
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/20210831014419.GB22652%40thirdeyesecurity.org.
Re: [qubes-users] resume from suspend issue after QSB-070
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Aug 30, 2021 at 05:39:40PM -0700, Andrew David Wong wrote: > On 8/30/21 2:12 PM, haaber wrote: > > > > > > Kind of answering my own question, but disabling hyperthreading > > > > happened to > > > > be a workaround for the resume from suspend issue. > > > > > > But shouldn't hyperthreading have already been disabled ever since > > > QSB-043? > > > > > > https://www.qubes-os.org/news/2018/09/02/qsb-43/ > > > > > I admit that I missed that one as well. Shame on me. Is there some way > > to detect active hyperthreading on boot && print out a big red warning ? > > > > That seems a reasonable measure, especially for new-comers how cannot > > reasonably be asked to read all old QSB's first :) > > > > I'm confused. I was under the impression that Qubes OS (after the QSB-043 > patches) automatically disables hyper-threading for you such that you don't > have to know anything, do anything, or read any past QSBs. > > As QSB-043 explains, you would have had to follow special instructions to > re-enable hyper-threading in Qubes 3.2, and no such instructions were > provided for re-enabling it in Qubes 4.0 (since, as the QSB explains, it's > never safe in that release), so I don't even know how'd you do it in that > release. > > But perhaps I'm mistaken or misunderstanding the question. There are (at least) two ways to disable hyper-threading: 1. In system BIOS (if there is such option) 2. In software - by disabling every second thread of each core. The QSB-043 uses the second method. It has is drawbacks, as the logic to bring up and down CPUs is quite complex. And yes, there are known issues[1] affecting suspend. Disabling hyper-threading in BIOS, prevents Xen from starting those secondary threads at all, and so it doesn't need to bring them down. [1] https://github.com/QubesOS/qubes-issues/issues/6066#issuecomment-901843312 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmEtfVgACgkQ24/THMrX 1yxJVgf8DMIUPdVfDjhTP6Lc/NEwIV+Fmgr0PZCa8zKQRVmKDosKH1zB2f5+fbl0 fJPygQBjx4YWu8J4p8a2kLb9T9QGRJuSFUZ1xtH0/wb5S9nZHsEEJSsFvD1NjOFN I5ynF1U+qaVbalztFSESJgRkTvTfgJLcCBT2GUvDsm6xqHEdK1BtaS0Mxogx00mQ 8xGHAUpUoC37FgLz2dSitgjmg6PzJJNiWQ14bDlKwydHy3ug9Z+fln0K9C3Pqv1s GzPs9LwM3OsNRZcKYwMNB3QGshJYIxFZMPn9s+dI9cy+DRQ6LWpGSgSdq3HLspYY MwMnD/wFxQCbNjp7c83uI7VD0wW50w== =lfCs -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/YS19WGKe0oTDpKhE%40mail-itl.
Re: [qubes-users] resume from suspend issue after QSB-070
On 8/30/21 5:39 PM, Andrew David Wong wrote: On 8/30/21 2:12 PM, haaber wrote: Kind of answering my own question, but disabling hyperthreading happened to be a workaround for the resume from suspend issue. But shouldn't hyperthreading have already been disabled ever since QSB-043? https://www.qubes-os.org/news/2018/09/02/qsb-43/ I admit that I missed that one as well. Shame on me. Is there some way to detect active hyperthreading on boot && print out a big red warning ? That seems a reasonable measure, especially for new-comers how cannot reasonably be asked to read all old QSB's first :) I'm confused. I was under the impression that Qubes OS (after the QSB-043 patches) automatically disables hyper-threading for you such that you don't have to know anything, do anything, or read any past QSBs. As QSB-043 explains, you would have had to follow special instructions to re-enable hyper-threading in Qubes 3.2, and no such instructions were provided for re-enabling it in Qubes 4.0 (since, as the QSB explains, it's never safe in that release), so I don't even know how'd you do it in that release. But perhaps I'm mistaken or misunderstanding the question. Ah, a thought just occurred to me. As QSB-043 states, "A CPU microcode update is required to take advantage of [these patches]." Perhaps the problem is that certain CPUs never received the required microcode updates, which explains why some users seem to have CPUs with hyper-threading enabled even though it's been years since QSB-043. Could that be it? Of course, it's generally also possible to disable hyper-threading in one's BIOS/EFI settings, regardless of whether it's disabled in Xen, and this does seem like a prudent measure given the risks associated with having it enabled and given the fact that Xen-level disablement appears to be hit-or-miss. So, perhaps your suggestion about detecting and warning about active hyper-threading might be a good idea after all. Please feel free to open an enhancement request. -- Andrew David Wong Community Manager The Qubes OS Project https://www.qubes-os.org -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/981e1775-e148-efc1-f2c8-6a457da618a3%40qubes-os.org. OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-users] resume from suspend issue after QSB-070
On 8/30/21 2:12 PM, haaber wrote: Kind of answering my own question, but disabling hyperthreading happened to be a workaround for the resume from suspend issue. But shouldn't hyperthreading have already been disabled ever since QSB-043? https://www.qubes-os.org/news/2018/09/02/qsb-43/ I admit that I missed that one as well. Shame on me. Is there some way to detect active hyperthreading on boot && print out a big red warning ? That seems a reasonable measure, especially for new-comers how cannot reasonably be asked to read all old QSB's first :) I'm confused. I was under the impression that Qubes OS (after the QSB-043 patches) automatically disables hyper-threading for you such that you don't have to know anything, do anything, or read any past QSBs. As QSB-043 explains, you would have had to follow special instructions to re-enable hyper-threading in Qubes 3.2, and no such instructions were provided for re-enabling it in Qubes 4.0 (since, as the QSB explains, it's never safe in that release), so I don't even know how'd you do it in that release. But perhaps I'm mistaken or misunderstanding the question. -- Andrew David Wong Community Manager The Qubes OS Project https://www.qubes-os.org -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a25ef0f0-6fb8-a710-2de8-4c2fd975c7c8%40qubes-os.org. OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-users] qubes packages in Archlinux AUR repo
Hi unman,
> I cant help with the AUR.
> I build Arch packages for 4.0 and 4.1, and update them probably twice
> a month ( other constraints permitting)
Thanks very much for doing that, my Arch template originally came from
your repo.
> You can pick up templates and packages at https://qubes.3isec.org
> unman
I imported your package signing key with pacman-key ("pacman-key
--finger unman" finds the key just fine) but if I try to do an upgrade
(pacman -Syu) I get (transcribed so there may be typos):
error: qubes-r4.0: signature from "unman (Qubes OS Signing Key)
" is invalid
Any thoughts? (I think I hit this iceberg before, and that is why I
have been using the AUR packages.)
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/20210831073736.1f6c2874%40gmx.com.
Re: [qubes-users] resume from suspend issue after QSB-070
Kind of answering my own question, but disabling hyperthreading happened to be a workaround for the resume from suspend issue. But shouldn't hyperthreading have already been disabled ever since QSB-043? https://www.qubes-os.org/news/2018/09/02/qsb-43/ I admit that I missed that one as well. Shame on me. Is there some way to detect active hyperthreading on boot && print out a big red warning ? That seems a reasonable measure, especially for new-comers how cannot reasonably be asked to read all old QSB's first :) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e960a4c1-1d50-a348-1d2c-da98b0780523%40web.de.
Re: [qubes-users] mounting root TemplatVM partition in dom0 fails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 rss+qu...@armor-mail.com: > I have some templates stored in a "file" pool where, for example, I > find the following files: > > private.img > private-cow.img > root.img > root-cow.img > > I can do this in dom0, no problem: > > sudo mount private.img /mnt > > But this fails: > > sudo mount root.img /mnt > > with a very common, uninformative error, ie. > > mount: wrong fs type, bad option, etc. etc. > > I would dearly love to mount the root.img and modify a file in /etc file > in a broken VM. Any hints would be welcome. It doesn't work for the 'root' volume because that contains multiple partitions. The / filesystem is on the 3rd. You could use kpartx to mount it, but mounting any VM or template filesystem in dom0 is insecure! The kernel can not be assumed to be robust against a potentially malicious filesystem. Better to attach your broken volume to a e.g. a trusted DisposableVM for recovery: https://github.com/QubesOS/qubes-issues/issues/4687#issue-396119132 https://github.com/QubesOS/qubes-issues/issues/4687#issuecomment-753492903 Rusty -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmEtPwBfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0 QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv Kt9EWw//SgfIibkUYNZzoidjiQgg7SSu9+jAFWFL3iBJU40el2hn6kiZ8cl/CGGg RAz/3AIyw2dtb1uoFc9TafjoUXlzlfXhcMEIHylggwzTkD2cL3EglBnhVw5x9a54 CS24qWUee8BhP50inZOEV0vUYCjO34948AveOKhD9YoVlwL0DUdvpeX8AaxiZmyP L+pl9jwvbdHE2DqhTle/vqL81lVHe3eM8ZQ798cm9q5pPbVH/x4nvmYdswmYgDN6 eSSNNblZ0BezuV7yuPpRSEOxxbkyhQMEfLqopvVEeFD8Ittv8z7C+jutp00RSmyT aOTyjCTWMoBKnSSE/IOOJkA3D+i6xHsK/lkP6j0AegRNiTV8m9oLKc+n4i1HNgPp MJz357hBF5Z8MPdfpNbT+hhpMpr7cVh2g1S3X01kO9Taom4QY3Mk+v1d61DgfgqO jWZuP8qV+9P8o9ifY0XsSXbVdixivujwOJS6hiiUl98fM502uHz1kDqzvmqR5umd Prb/c6yLRlCcBluM/cYIdBKcY6OhBx1eI/cUW2mmr/csICpjgwygVHsvJ82ou5yW aKMn9M2LCrbRy9tjDcs+Yd1ckEm0L/VIhJRfCx1hm8+twIzhwHqg2MDY+mAqfBZz bnykRv6i7YhaQXZ7Fy2ieaCDphFHnYOrAsi6FyVfnwmHZzL4Qc8= =dUVg -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/YS0/AM0jyOtQM6xy%40mutt.
[qubes-users] mounting root TemplatVM partition in dom0 fails
Hi, I have some templates stored in a "file" pool where, for example, I find the following files: private.img private-cow.img root.img root-cow.img I can do this in dom0, no problem: sudo mount private.img /mnt But this fails: sudo mount root.img /mnt with a very common, uninformative error, ie. mount: wrong fs type, bad option, etc. etc. I would dearly love to mount the root.img and modify a file in /etc file in a broken VM. Any hints would be welcome. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20210830191319.0090a549%40armor-mail.com.
Re: [qubes-users] Trezor in Qubes
tetrahedra via qubes-users: On Thu, Aug 26, 2021 at 02:27:35PM +, 'taran1s' via qubes-users wrote: Hello all, I would like to start to use Trezor with my qubes. I would like to follow this guide here https://wiki.trezor.io/Qubes_OS. My intention is to use the Trezor HW wallet in a anon-whonix AppVm with Trezor Suite qube through Tor. I run qubes on X230 Nitropad. I would like to check if the guide to install the Trezor Bridge and Udev rules in the sys-usb (see the official Trezor guide) is advised by qubes community or is it good practice not to install anything in the sys-usb and instead install the packages (bridge, udev rules and suite) in the target anon-whonix AppVM. It should be fine. See my pull request for step by step instructions: https://github.com/Qubes-Community/Contents/pull/145 https://github.com/Qubes-Community/Contents/blob/3e1785a11e90b52e086fb8b3b246e5c2de7faca5/docs/common-tasks/setup-trezor-cryptocurrency-hardware-wallet.md Thank you for the advice. You mention on github to verify the bridge, but I cannot find any signed hash or anything for Trezor bridge and udev rules. Can you point me to it? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20791bd4-38c6-28ff-d721-8440b6e00786%40mailbox.org.
