Re: [qubes-users] Trezor in Qubes
On Fri, Sep 03, 2021 at 07:54:56AM +, taran1s wrote: Thank you for the guide. I tried to follow the official guide on trezor wiki, abstaining from fedora a bit more, but still erroring. To your guide. The last 4 lines: copy to fedora-3x in fedora-3x sudo rpm -i /path/to/trezor.rpm ...are to be done in the fedora-3x template, right? Will it work on fedora-33-minimal too, or it needs to be full template? I don't know. All done, but I wasnt able to find any signed hash of the bridge or something and so I get this error: [user@fedora-33-min-trezor ~]$ sudo rpm -i trezor-bridge-2.0.27-1.x86_64.rpm warning: trezor-bridge-2.0.27-1.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID b9a02a3d: NOKEY package trezor-bridge-2.0.27-1.x86_64 does not verify: Header V4 RSA/SHA256 Signature, key ID b9a02a3d: NOKEY Weird. You have to install the Trezor verification key. I had to do this the first time I installed, but after re-imaging my system, it wasn't necessary on the most recent install, so I took the section out of my notes. Unfortunately I don't remember what the steps were to install the key! -- 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/YTPfjQCizVDm8sen%40danwin1210.me.
Re: [qubes-users] Trezor error with qubes
have you seen this? https://github.com/Qubes-Community/Contents/blob/e7443c960228c1abec9b97f2c2027dbc01f45f63/docs/common-tasks/setup-trezor-cryptocurrency-hardware-wallet.md On Tue, Aug 31, 2021 at 02:53:47PM +, 'taran1s' via qubes-users wrote: Hello, In my last message I mentioned my attempts to start using the Trezor with qubes. I try to follow this guide, from the official trezor website: https://wiki.trezor.io/Qubes_OS I use the sys-usb based on debian-10 and tried the same with sys-usb based on debian-10-minimal with similar error. My online AppVM in anon-whonix. After I finished the procedures described in the guide, I installed the trezor Bridge and Udev rules in the sys-usb, and the Trezor Suite in the anon-whonix, with sudo dpkg -i required-package. Once I start both sys-usb and anon-whonix and attach the trezor-T I get following error (suite is seen by the sys-usb): 2021-08-31T14:38:06.967Z - ERROR(process-trezord): Status error: request to http://127.0.0.1:21325/ failed, reason: connect ECONNREFUSED 127.0.0.1:21325 Do you see any workarounds to make it work? -- 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/753fdebf-f149-5ba4-8f24-f19802a0b525%40mailbox.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/YTPcR2PRFOL/AjKf%40danwin1210.me.
Re: [EXT] Re: [qubes-users] resume from suspend issue after QSB-070
On 9/3/21 11:41 PM, Marek Marczykowski-Górecki wrote: [...]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. [] 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. [] This is kind of similar issue as the one discussed here. That's why it's better to disable HT in BIOS - to not show those 8 CPUs at all. But from the OS level, we don't have other choice, and we prefer a secure default - that's why we disable HT at Xen level, to provide safer option regardless of what user has set in the BIOS. Couldn't xen/qubes set a boot warning to users that rely only on (2) to encourage more strongly to disable by BIOS (1)? That seems a logic measure to me. 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/c52d5e57-a3d3-fc55-ee67-d2032095fdd5%40web.de.
