[qubes-users] Re: Any appetite for tiny tweaks to make initial usability better?
On Wednesday, 24 July 2019 01:23:55 UTC+1, qtpie wrote: > > Martin Gladdish: > > New Qubes user here, with less than a week's experience. > > > > Having fumbled my way through the initial install I'm now encountering a > > few tiny niggles that should be simple to fix. > > > > The first one that springs to mind is the default keyboard shortcuts in > > Terminal for Copy and Paste, which are Ctrl-Shift-C and Ctrl-Shift-V. > But > > these clash with the inter-qube copy and paste shortcuts. > > > > Changing the default modifier in the Terminal app to use Alt instead of > > Ctrl would seem to make sense? So Alt-Shift-C and Alt-Shift-V. > > > > Smoothing these wrinkles, although each of them is tiny, could make a > big > > difference IMHO. > > > > Thoughts? > > > > > Hi Martin, > > In terminal you can use Ctrl+Insert as an alternative to Ctrl+Shift+C, > and Shift+Insert as an alternative to Ctrl+Shift+V. Maybe make a list of > all you annoyances and their solutions, and submit it to Qubes for > inclusion in the manual? > Whilst I'm more than happy to contribute to the manual, I think this should be changed in the app settings too. The labels on the menu items are where I'd look to see which shortcuts to use, and out of the box they say Ctrl-Shift-C, etc. I didn't know about those alternate shortcuts, and don't think I would have gone looking on the manual for them (but dead useful, thanks!). But yes, happy to put a niggle list together and see what we can do about them. What's a good place for sharing such a doc online? I'd normally use GDocs, but after google shafted my production service the other week by mistakenly flagging it on its spam databases I'm loathe to touch anything of theirs again. -- 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/75bbdfc8-dbe5-4850-ac49-5a572728b952%40googlegroups.com.
Re: [qubes-users] Any appetite for tiny tweaks to make initial usability better?
On Tue, Jul 23, 2019 at 3:16 PM Martin Gladdish wrote: > > New Qubes user here, with less than a week's experience. > > Having fumbled my way through the initial install I'm now encountering a few > tiny niggles that should be simple to fix. > > The first one that springs to mind is the default keyboard shortcuts in > Terminal for Copy and Paste, which are Ctrl-Shift-C and Ctrl-Shift-V. But > these clash with the inter-qube copy and paste shortcuts. > > Changing the default modifier in the Terminal app to use Alt instead of Ctrl > would seem to make sense? So Alt-Shift-C and Alt-Shift-V. > > Smoothing these wrinkles, although each of them is tiny, could make a big > difference IMHO. I personally use Super+C and Super+V Kushal -- Public Interest Technologist, Freedom of the Press Foundation CPython Core Developer Director, Python Software Foundation https://kushaldas.in -- 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/CAAzeMbyhPHoLdPxZxPOD4H%3DpHieaQ6H0iErcR-NHU-mS8FAVgw%40mail.gmail.com.
Re: [qubes-users] Re: Any appetite for tiny tweaks to make initial usability better?
On Wed, Jul 24, 2019 at 12:47:12AM -0700, Martin Gladdish wrote: > > > On Wednesday, 24 July 2019 01:23:55 UTC+1, qtpie wrote: > > > > Martin Gladdish: > > > New Qubes user here, with less than a week's experience. > > > > > > Having fumbled my way through the initial install I'm now encountering a > > > few tiny niggles that should be simple to fix. > > > > > > The first one that springs to mind is the default keyboard shortcuts in > > > Terminal for Copy and Paste, which are Ctrl-Shift-C and Ctrl-Shift-V. > > But > > > these clash with the inter-qube copy and paste shortcuts. > > > > > > Changing the default modifier in the Terminal app to use Alt instead of > > > Ctrl would seem to make sense? So Alt-Shift-C and Alt-Shift-V. > > > > > > Smoothing these wrinkles, although each of them is tiny, could make a > > big > > > difference IMHO. > > > > > > Thoughts? > > > > > > > > Hi Martin, > > > > In terminal you can use Ctrl+Insert as an alternative to Ctrl+Shift+C, > > and Shift+Insert as an alternative to Ctrl+Shift+V. Maybe make a list of > > all you annoyances and their solutions, and submit it to Qubes for > > inclusion in the manual? > > > > Whilst I'm more than happy to contribute to the manual, I think this should > be changed in the app settings too. > > The labels on the menu items are where I'd look to see which shortcuts to > use, and out of the box they say Ctrl-Shift-C, etc. I didn't know about > those alternate shortcuts, and don't think I would have gone looking on the > manual for them (but dead useful, thanks!). > > But yes, happy to put a niggle list together and see what we can do about > them. What's a good place for sharing such a doc online? I'd normally use > GDocs, but after google shafted my production service the other week by > mistakenly flagging it on its spam databases I'm loathe to touch anything > of theirs again. > Hi Martin Thanks for the input - keep the niggles coming. I'd suggest just posting in this thread for the moment. The Ctrl+Shift+C combination in gnome-terminal is a gnome shortcut, which can be configured as normal in gnome. There's an alternative (Ctrl+Insert) as qtpie pointed out. The use of Ctrl+Shift+C in Qubes is Qubes specific, and can be configured by editing /etc/qubes/guid.conf This question has been raised before, and there are open issues at github.com/qubesos/qubes-issues/issues The greatest problem with proposed replacements is that they will almost always conflict with shortcuts used by other users in specific programs. There's been some discussion about this before and it doesn't seem possible to find combinations that wont conflict *somewhere*. For example your proposed use of Alt+Shift+C is used in i3 to reload configuration. So it's left to users to configure as suits them. (In general Qubes policy is not to change stuff that ships with distro defaults.) unman -- 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/20190724132731.s5rlhwqparvjstuo%40thirdeyesecurity.org.
Re: [qubes-users] qubes Update Icon shows updates available but no updates
On Tue, Jul 23, 2019 at 07:39:09AM -0400, qubeszz9user...@zz9pluralzalpha.eu
wrote:
> Hello List,
>
> Not too important but:
>
> I have two identical laptops (apart from ram)
>
> The first one works perfectly and all updates fine.
>
> On the second one every vm is updated as well ("by hand" in the running
> template and via right manager, no updates available in?? debian-9,
> whonix-15 and fedora-30 (and some clones)),
>
> but the Update icon in the taskbar is still saying that there are upates
> available. This started a few days with fedora and now every vm/template
> wants updates (according to the panel plugin), but all VMs can be
> updated fine by hand?!
>
> So this is only cosmetic but strange.
>
> (maybe correlated: Dom0 says on "qubes-dom0-update" that some packages
> are already downloaded but doesn't seem to install them)
>
> Thanks a lot in advance
> Fr
>
The update icon issue is a known issue , and the fix is in the pipeline.-
There's an additional problem where disposableVM are created with
"update available" set, but that also is being fixed.
On the dom0 issue, you can (generally) resolve this by opening a
terminal in dom0 and manually installing the updates -
sudo dnf install
--
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/20190724135531.ee7nidk2nmoyrfc2%40thirdeyesecurity.org.
Re: [qubes-users] Using Salt to update TemplateVMs
On Mon, Jul 22, 2019 at 07:38:27PM -0500, Andrew David Wong wrote: > > Sorry, I'm not following your example. What does it mean to "do the > equivalent of qvm-create and qvm-prefs"? I had no idea you could create > the effects of those commands without those commands. This sounds like a > rather arcane area of Qubes wizardry into which I have not ventured. > Actually you probably have ventured, but not realised it. When you run the installer and configure the system, the various qubes are created with salt. The state files are in /srv/formulas/base/virtual-machines-formula/qvm and you can inspect them there. These files use templating. For example the sys-net.sls file uses: name: sys-net present: - label: red prefs: - netvm: '' - virt_mode: hvm etc etc You could get the same effect by calling the qvm functions directly: --- sys-net: qvm.present: -name: sys-net -template: debian-10 -label: red sys-net-prefs: qvm.prefs: -netvm: '' -virt_mode: hvm --- If you look at the example I linked to you can see a breakdown of how to create a Qubes builder qube. The steps are: clone template and create qube, install necessary software in template,configure qube. I've left that as simple as I can. By keeping these formulae, you can (re)create any aspects of your Qubes system in a few commands. Of course, you can do this using batch files calling qvm-create, qvm-prefs, qvm-copy-to-vm, and assorted calls to qvm-run. imo the salt formulae are clearer and easier to maintain. Also salt handles very well cases where (e.g) package names differ between distributions, or you want the configuration to change between debian-9 and debian-10, or between individual qubes, I'm happy to post simple examples if anyone wants to give a specification. unman -- 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/20190724142208.wa3gonlngf55bymx%40thirdeyesecurity.org.
Re: [qubes-users] Re: Announcement: Insurgo PrivacyBeast X230 Laptop meets and exceeds Qubes 4.0 hardware certification
Le lundi 22 juillet 2019 11:40:44 UTC-4, Chris Laprise a écrit : > > On 7/21/19 5:44 PM, Lorenzo Lamas wrote: > > Very nice to finally have a certified Qubes laptop! > > > > Personally, for me it would be nice if there was a more powerful > > alternative in the future. I'm currently using something with about the > > same resource power and I find myself often wishing I had something > > faster because Qubes is quite heavy compared to a standard OS. It would > > be great to have a quad core CPU(and a proper one, not one of those > > power-saving U line from Intel), 32GB RAM or more and a NVMe SSD instead > > of SATA. > > Also, there is the issue of the CPU being a 3rd gen Intel i CPU. Maybe > > this is specifically chosen because later CPU's are harder to get blob > > free, I don't know the details. However, Intel had quite a few side > > channel vulnerabilities over the past year, and this year they dropped > > microcode update support for 1st gen CPU's, so there is a pretty high > > chance they will drop 2nd gen support next year and 3rd gen support the > > year after that. > > There is even one statement from Intel out there that they've > tentatively already dropped support for 3rd gen (which is what the X230 > and its 'sister' the T430s uses). > I didn't find such statement. Would love to find confirming/infirming information for i7-3520M. Microcode updates were released for Windows: https://support.microsoft.com/en-us/help/4494451/kb4494451-intel-microcode-updates They do not seem to have been injected them in Intel repository, though: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files No idea if they are included in Fedora, to be applied by dom0 in QubesOS. > > The Lenovo G505s should be slightly more powerful than the X230, and its > AMD A10 processor is significantly less prone to attack. > > The only problems with it are that HEADS doesn't work (not a big > disadvantage, given how vulnerable X230's older TPM is), TPM was not vulnerable to weak RSA cert generation of 2017: https://web.archive.org/web/20190203222631/https://support.lenovo.com/us/en/product_security/len-15552 And since the TPM is used under Heads as one of the first modified instructions of Coreboot, I don't see how boot measurements could be impacted by S3 resume vulnerability of 2018: https://github.com/kkamagui/napper-for-tpm and to install > Qubes you need to flash it with a Coreboot config that requires you to > add an un-signed graphics driver (I think if enough people posted SHA256 > hashes of the driver it wouldn't be a big problem). > > It also accepts ECC RAM, which reduces the DDR3 side-channel > vulnerabilities somewhat. > For the side-channel attacks, I would love to see a PoC, since from my understanding, it is not possible to access other's qubes memory and those timing attacks are even weaker in virtualized environments: https://security.stackexchange.com/questions/127806/are-virtualized-environments-vulnerable-to-the-row-hammer-attack/130762 For the G505S: I can only redirect to the work needing to be done on that model to reduce size so it could support Librem Key and its external measurements without a TPM (the G505s doesn't have a TPM). After which GPG, cryptsetup-reencrypt and other tools can be injected in the ROM to support a trustworthy "root of trust" on which QubesOS can securely be preinstalled/used: https://github.com/osresearch/heads/issues/453#issuecomment-514652215 > > So the alternative to the 2012 laptop is the 2013 laptop. A bit > underwhelming. > > - > > The overall problem here is none of these open source OS projects are > true integrators or designers, not when it has anything to do with > hardware. The path to resolve this becomes clearer. We need open source hardware supported by QubesOS. ppc64 support is our best bet IMHO: https://github.com/QubesOS/qubes-issues/issues/4318 Meanwhile, actual best solutions needs to be upstreamed, and this is the path i've decided to take which got funded: https://github.com/osresearch/heads/issues/540 > This is why Qubes project will identify USB controller > isolation as a major issue, but then do nothing about it (note the X230 > is lacking a secondary USB controller). That was adressed by unman in a precedent answer. > They'll say Intel or X86 is > fundamentally insecure, but won't begin to describe what a good > alternative would look like at the component level; without that, > there's nothing into which the hardware people to sink their teeth or > even notice Qubes. > ppc64 laptops are in the pipeline by RaptorEngineering. Those will need virtualization support, IOMMU and Open Source Firmware. Better would be to have encrypted memory from each VM to leverage side-channel theoretical attack impacts. Best would be to completely externalize internal SPI flash or design an equivalent. Something that could be hacked on on already existing hardware, or designed
[qubes-users] Re: Announcement: Insurgo PrivacyBeast X230 Laptop meets and exceeds Qubes 4.0 hardware certification
>sandybridge > $1,581.00 laught high. пятница, 19 июля 2019 г., 7:19:37 UTC+3 пользователь Andrew David Wong написал: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Dear Qubes Community, > > We are very pleased to announce that the Insurgo PrivacyBeast X230 [1] > has passed Qubes 4.0 Hardware Certification and is now a Qubes-certified > Laptop! [2] > > ## What is Qubes Certified Hardware? > > Qubes Certified Hardware [3] is hardware that has been certified by the > Qubes developers as compatible with Qubes OS. Beginning with Qubes 4.0, > in order to achieve certification, the hardware must satisfy a rigorous > set of requirements [4], and the vendor must commit to offering > customers the very same configuration (same motherboard, same screen, > same BIOS version, same Wi-Fi module, etc.) for at least one year. > > Qubes-certified Laptops [2], in particular, are regularly tested > by the Qubes developers to ensure compatibility with all of Qubes' > features. The developers test all new major versions and updates to > ensure that no regressions are introduced. > > It is important to note, however, that Qubes Hardware Certification > certifies only that a particular hardware *configuration* is *supported* > by Qubes. The Qubes OS Project takes no responsibility for any > manufacturing or shipping processes, nor can we control whether physical > hardware is modified (whether maliciously or otherwise) *en route* to > the user. (However, see below for information about how the Insurgo > team mitigates this risk.) > > ## About the Insurgo PrivacyBeast X230 Laptop > > The Insurgo PrivacyBeast X230 [1] is a custom refurbished ThinkPad X230 > [5] that not only *meets* all Qubes Hardware Certification requirements > [4] but also *exceeds* them thanks to its unique configuration, > including: > > - Coreboot [6] initialization for the x230 is binary-blob-free, > including native graphic initialization. Built with the > Heads [7] payload, it delivers an Anti Evil Maid (AEM) [8]-like > solution built into the firmware. (Even though our requirements [4] > provide an exception for CPU-vendor-provided blobs for silicon and > memory initialization, Insurgo exceeds our requirements by insisting > that these be absent from its machines.) > > - Intel ME [9] is neutered through the AltMeDisable bit, while all > modules other than ROMP and BUP, which are required to initialize > main CPU, have been deleted. [10] > > - A re-ownership process that allows it to ship pre-installed with > Qubes OS, including full-disk encryption already in place, but > where the final disk encryption key is regenerated only when the > machine is first powered on by the user, so that the OEM doesn't > know it. > > - Heads [7] provisioned pre-delivery to protect against malicious > interdiction. [11] > > ## How to get one > > Please see the Insurgo PrivacyBeast X230 [1] on the Insurgo website [12] > for more information. > > ## Acknowledgements > > Special thanks go to: > > - Thierry Laurion [13], Director of Insurgo, Technologies Libres (Open > Technologies), for spearheading this effort and making Heads+Qubes > laptops more broadly accessible. > > - Trammell Hudson [14], for creating Heads [7]. > > - Purism [15], for greatly improving the UX of Heads [7], including > the GUI menu, and for adding Nitrokey [16] and Librem Key [17] > support. > > > [1] > https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/ > > [2] > https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptop-insurgo-privacybeast-x230 > > [3] https://www.qubes-os.org/doc/certified-hardware/ > [4] > https://www.qubes-os.org/doc/certified-hardware/#hardware-certification-requirements > > [5] https://www.thinkwiki.org/wiki/Category:X230 > [6] https://www.coreboot.org/ > [7] https://github.com/osresearch/heads/ > [8] https://www.qubes-os.org/doc/anti-evil-maid/ > [9] https://libreboot.org/faq.html#intelme > [10] > https://github.com/osresearch/heads-wiki/blob/master/Clean-the-ME-firmware.md#how-to-disabledeactive-most-of-it > > [11] https://en.wikipedia.org/wiki/Interdiction > [12] https://insurgo.ca > [13] https://www.linkedin.com/in/thierry-laurion-40b4128/ > [14] https://trmm.net/About > [15] https://puri.sm/ > [16] https://www.nitrokey.com/ > [17] https://puri.sm/posts/introducing-the-librem-key/ > > This announcement is also available on the Qubes website: > > https://www.qubes-os.org/news/2019/07/18/insurgo-privacybeast-qubes-certification/ > > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl0xRMEACgkQ203TvDlQ > MDAEVQ//d5Ziw78qjjYCaepSpJTXwdlw6yiZVXm5ecB1xYMdS7UrQJYX3vS/on/R > i4Sh/fuQBfr5qzap8BHK7DyZ3IJYFjazVPkXS
[qubes-users] Re: Announcement: Insurgo PrivacyBeast X230 Laptop meets and exceeds Qubes 4.0 hardware certification
Also x230 can be more powerful. Look at this guyz https://world.taobao.com/item/550879131380.htm https://forum.51nb.com/forum.php?mod=viewthread&tid=1602437 http://thinkpads.kr/xe/REVIEW01/204307 https://forum.51nb.com/thread-1548345-1-1.html -- 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/d2732883-fd2f-4726-8650-dc29b03f9f22%40googlegroups.com.
Re: [qubes-users] Announcement: Insurgo PrivacyBeast X230 Laptop meets and exceeds Qubes 4.0 hardware certification
On Wed, Jul 24, 2019 at 7:16 AM Matthew Finkel wrote: > Hi Thierry, > > Thanks for the response. Maybe I'm not looking at the correct page.On > > https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/ > I see it says: > > "2x Fast USB 3. 0 ports (left side blue ports) + 1x USB 2.0 port > (right side yellow port)" > > But I don't see any mention of the number of distinct USB controllers > - specifically the number of controllers (and USB ports) that can be > isolated per qube. > There is 3 usb-controllers, all attached to sys-usb by default, added to the sdcard controller. See attachment. > Thanks, > > On Mon, Jul 22, 2019 at 3:21 PM Thierry Laurion > wrote: > > > > This is detailed under product page. > > Thanks > > > > On Sun, Jul 21, 2019, 03:34 Matthew Finkel, > wrote: > >> > >> On Friday, July 19, 2019, Andrew David Wong wrote: > >>> > >>> -BEGIN PGP SIGNED MESSAGE- > >>> Hash: SHA512 > >>> > >>> Dear Qubes Community, > >>> > >>> We are very pleased to announce that the Insurgo PrivacyBeast X230 [1] > >>> has passed Qubes 4.0 Hardware Certification and is now a > Qubes-certified > >>> Laptop! [2] > >> > >> > >> Can you say how many USB controllers this laptop has? > >> > >> Thanks, > >> Matt > >> > >> > >> -- > >> Matthew Finkel > >> > >> -- > >> 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/CAGF8hsvas-dcbgYYaHhtjerfnyMV9AO%3D0Dnd3ALoL5zhqKw3fQ%40mail.gmail.com > . > > > > -- > Matthew Finkel > -- 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/CAAzJznzSFHLd8sSKHOps%3Dn1w6_WkfwwXdyjkbf01YyhsykUMJg%40mail.gmail.com.
Re: [qubes-users] Re: Announcement: Insurgo PrivacyBeast X230 Laptop meets and exceeds Qubes 4.0 hardware certification
On Wed, Jul 24, 2019 at 1:16 PM wrote: > >sandybridge > > > > $1,581.00 > > laught high. > I can understand seeing the total price. The reality is 946$CAD, though for the Grade A refurbished laptop i7 2.9ghz, 16GB ram, 256Gb SSD drive and IPS screen. See product description. You pay an additional 500$CAD to have integrity attestation of firmware and QubesOS preinstallation, while supporting what I try to accomplish. Else you can do it yourself from locally available hardware, but I doubt you can find equivalent quality refurb grade A equivalent hardware with competitive price. The OEM Re-Ownership wizard in action, with important links and references: https://archive.org/details/oemuserreownership Regards, Thierry Laurion/Insurgo > > > пятница, 19 июля 2019 г., 7:19:37 UTC+3 пользователь Andrew David Wong > написал: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> Dear Qubes Community, >> >> We are very pleased to announce that the Insurgo PrivacyBeast X230 [1] >> has passed Qubes 4.0 Hardware Certification and is now a Qubes-certified >> Laptop! [2] >> >> ## What is Qubes Certified Hardware? >> >> Qubes Certified Hardware [3] is hardware that has been certified by the >> Qubes developers as compatible with Qubes OS. Beginning with Qubes 4.0, >> in order to achieve certification, the hardware must satisfy a rigorous >> set of requirements [4], and the vendor must commit to offering >> customers the very same configuration (same motherboard, same screen, >> same BIOS version, same Wi-Fi module, etc.) for at least one year. >> >> Qubes-certified Laptops [2], in particular, are regularly tested >> by the Qubes developers to ensure compatibility with all of Qubes' >> features. The developers test all new major versions and updates to >> ensure that no regressions are introduced. >> >> It is important to note, however, that Qubes Hardware Certification >> certifies only that a particular hardware *configuration* is *supported* >> by Qubes. The Qubes OS Project takes no responsibility for any >> manufacturing or shipping processes, nor can we control whether physical >> hardware is modified (whether maliciously or otherwise) *en route* to >> the user. (However, see below for information about how the Insurgo >> team mitigates this risk.) >> >> ## About the Insurgo PrivacyBeast X230 Laptop >> >> The Insurgo PrivacyBeast X230 [1] is a custom refurbished ThinkPad X230 >> [5] that not only *meets* all Qubes Hardware Certification requirements >> [4] but also *exceeds* them thanks to its unique configuration, >> including: >> >> - Coreboot [6] initialization for the x230 is binary-blob-free, >> including native graphic initialization. Built with the >> Heads [7] payload, it delivers an Anti Evil Maid (AEM) [8]-like >> solution built into the firmware. (Even though our requirements [4] >> provide an exception for CPU-vendor-provided blobs for silicon and >> memory initialization, Insurgo exceeds our requirements by insisting >> that these be absent from its machines.) >> >> - Intel ME [9] is neutered through the AltMeDisable bit, while all >> modules other than ROMP and BUP, which are required to initialize >> main CPU, have been deleted. [10] >> >> - A re-ownership process that allows it to ship pre-installed with >> Qubes OS, including full-disk encryption already in place, but >> where the final disk encryption key is regenerated only when the >> machine is first powered on by the user, so that the OEM doesn't >> know it. >> >> - Heads [7] provisioned pre-delivery to protect against malicious >> interdiction. [11] >> >> ## How to get one >> >> Please see the Insurgo PrivacyBeast X230 [1] on the Insurgo website [12] >> for more information. >> >> ## Acknowledgements >> >> Special thanks go to: >> >> - Thierry Laurion [13], Director of Insurgo, Technologies Libres (Open >> Technologies), for spearheading this effort and making Heads+Qubes >> laptops more broadly accessible. >> >> - Trammell Hudson [14], for creating Heads [7]. >> >> - Purism [15], for greatly improving the UX of Heads [7], including >> the GUI menu, and for adding Nitrokey [16] and Librem Key [17] >> support. >> >> >> [1] >> https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/ >> [2] >> https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptop-insurgo-privacybeast-x230 >> [3] https://www.qubes-os.org/doc/certified-hardware/ >> [4] >> https://www.qubes-os.org/doc/certified-hardware/#hardware-certification-requirements >> [5] https://www.thinkwiki.org/wiki/Category:X230 >> [6] https://www.coreboot.org/ >> [7] https://github.com/osresearch/heads/ >> [8] https://www.qubes-os.org/doc/anti-evil-maid/ >> [9] https://libreboot.org/faq.html#intelme >> [10] >> https://github.com/osresearch/heads-wiki/blob/master/Clean-the-ME-firmware.md#how-to-disabledeactive-most-of-it >> [11] https://en.wikipedia.or
Re: [qubes-users] Re: Announcement: Insurgo PrivacyBeast X230 Laptop meets and exceeds Qubes 4.0 hardware certification
Guyz, this is not serious. >100$ laptop >chink keyboard >lost battery >flashed with a $5 ch341a coreboot среда, 24 июля 2019 г., 20:48:11 UTC+3 пользователь Thierry Laurion написал: > > > > On Wed, Jul 24, 2019 at 1:16 PM > > wrote: > >> >sandybridge >> > >> >> $1,581.00 >> >> laught high. >> > I can understand seeing the total price. The reality is 946$CAD, though > for the Grade A refurbished laptop i7 2.9ghz, 16GB ram, 256Gb SSD drive and > IPS screen. See product description. You pay an additional 500$CAD to have > integrity attestation of firmware and QubesOS preinstallation, while > supporting what I try to accomplish. > > Else you can do it yourself from locally available hardware, but I doubt > you can find equivalent quality refurb grade A equivalent hardware with > competitive price. > The OEM Re-Ownership wizard in action, with important links and > references: https://archive.org/details/oemuserreownership > > Regards, > Thierry Laurion/Insurgo > > >> >> >> пятница, 19 июля 2019 г., 7:19:37 UTC+3 пользователь Andrew David Wong >> написал: >>> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA512 >>> >>> Dear Qubes Community, >>> >>> We are very pleased to announce that the Insurgo PrivacyBeast X230 [1] >>> has passed Qubes 4.0 Hardware Certification and is now a Qubes-certified >>> Laptop! [2] >>> >>> ## What is Qubes Certified Hardware? >>> >>> Qubes Certified Hardware [3] is hardware that has been certified by the >>> Qubes developers as compatible with Qubes OS. Beginning with Qubes 4.0, >>> in order to achieve certification, the hardware must satisfy a rigorous >>> set of requirements [4], and the vendor must commit to offering >>> customers the very same configuration (same motherboard, same screen, >>> same BIOS version, same Wi-Fi module, etc.) for at least one year. >>> >>> Qubes-certified Laptops [2], in particular, are regularly tested >>> by the Qubes developers to ensure compatibility with all of Qubes' >>> features. The developers test all new major versions and updates to >>> ensure that no regressions are introduced. >>> >>> It is important to note, however, that Qubes Hardware Certification >>> certifies only that a particular hardware *configuration* is *supported* >>> by Qubes. The Qubes OS Project takes no responsibility for any >>> manufacturing or shipping processes, nor can we control whether physical >>> hardware is modified (whether maliciously or otherwise) *en route* to >>> the user. (However, see below for information about how the Insurgo >>> team mitigates this risk.) >>> >>> ## About the Insurgo PrivacyBeast X230 Laptop >>> >>> The Insurgo PrivacyBeast X230 [1] is a custom refurbished ThinkPad X230 >>> [5] that not only *meets* all Qubes Hardware Certification requirements >>> [4] but also *exceeds* them thanks to its unique configuration, >>> including: >>> >>> - Coreboot [6] initialization for the x230 is binary-blob-free, >>> including native graphic initialization. Built with the >>> Heads [7] payload, it delivers an Anti Evil Maid (AEM) [8]-like >>> solution built into the firmware. (Even though our requirements [4] >>> provide an exception for CPU-vendor-provided blobs for silicon and >>> memory initialization, Insurgo exceeds our requirements by insisting >>> that these be absent from its machines.) >>> >>> - Intel ME [9] is neutered through the AltMeDisable bit, while all >>> modules other than ROMP and BUP, which are required to initialize >>> main CPU, have been deleted. [10] >>> >>> - A re-ownership process that allows it to ship pre-installed with >>> Qubes OS, including full-disk encryption already in place, but >>> where the final disk encryption key is regenerated only when the >>> machine is first powered on by the user, so that the OEM doesn't >>> know it. >>> >>> - Heads [7] provisioned pre-delivery to protect against malicious >>> interdiction. [11] >>> >>> ## How to get one >>> >>> Please see the Insurgo PrivacyBeast X230 [1] on the Insurgo website [12] >>> for more information. >>> >>> ## Acknowledgements >>> >>> Special thanks go to: >>> >>> - Thierry Laurion [13], Director of Insurgo, Technologies Libres (Open >>> Technologies), for spearheading this effort and making Heads+Qubes >>> laptops more broadly accessible. >>> >>> - Trammell Hudson [14], for creating Heads [7]. >>> >>> - Purism [15], for greatly improving the UX of Heads [7], including >>> the GUI menu, and for adding Nitrokey [16] and Librem Key [17] >>> support. >>> >>> >>> [1] >>> https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/ >>> >>> [2] >>> https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptop-insurgo-privacybeast-x230 >>> >>> [3] https://www.qubes-os.org/doc/certified-hardware/ >>> [4] >>> https://www.qubes-os.org/doc/certified-hardware/#hardware-cer
Re: [qubes-users] Re: Announcement: Insurgo PrivacyBeast X230 Laptop meets and exceeds Qubes 4.0 hardware certification
I won't feed trolls. But will invite you to find me comparative prices for grade A x230 i7 2.9ghz of the same specs. Those are not 200$ CAD, but 940+ (with IPS, 16GB RAM, 250GB SSD and Atheros card) + 80$ for a Librem Key (80$CAD) which will visually attest integrity of firmware at each boot, while permitting to sign boot configuration changes and attest that you approved the changes. Added to that price is 500$CAD for the service made on the laptop to neuter Intel ME, flash the rom, preinstall QubesOS and latet updates, preinstall a Windows7 TemplateVM that you can activate over Windows activation phone line. While permitting to have provable integrity, to attest to you that the laptop haven been tampered with in transit, added with a tamper evident sticker on the main screw of the laptop, required to unscrew to access internal hardware. Compare prices for yourself. You will find used hardware requiring fan/cpu thermal paste reaaplication, broken cases, 8GB memory equipped laptops with spinning HD without IPS screen. Please challenge me: https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop/ My goal is to start a workers/buyers cooperative with this, charging an additional flat fee on top of hardware cost for what is done on the refurbished hardware. That money is my salary and personal funding source to pay for other knowledgeable work, pay for QubesOS development and for sure, also pay myself so I do not have have a job outside of this and dedicate myself to open hardware and projects that need money to go forward, while continuing to do security trainings for right defenders, that need this kind of tool, btw. OEM reownership in action, permitting QubesOS preinstallation on "slightly more secured hardware" (Heads moto): https://archive.org/details/activateoemreownership The more refurbisher sources of high end and grade A hardware, the best prices users will get. Finding a secure source for that model was not an easy task. Try it for yourself. You will see. Its quite easy to find one super deal. Finding a provider is a different story. If you find one, contact me, you might become a distributor for your own country! Doing the OEM reownership to make QubesOS preinstallable was not an easy task either. https://github.com/osresearch/heads/pull/551 QubesOS certification was made bridge the gap on having QubesOS preinstalled, which never happened, even if it was supposed in the past. To finally promote QubesOS preinstalled machines, without compromising encrypted keys, while promoting my first move torward "Accessible security", project for which grant was received. Else users are redirected on the HCL page and not all people are technical enough to even choose the right hardware, even less ones that can boot from Open Source Firmware. And enven less of them will arrive to the point of having a provable root of trust. All of this work was made open source, and can be ported to other models and platforms, which I would really love to see happen though the Heads project. I also did the port for the KGPE-D16/KCMA-D8, which you can find on the Heads github site, which has OpenBMC iKVM module, can be used a QubesOS server and can be remotely booted, with provable root of trust through iserted Librem Key. You are more then welcome to join forces instead of criticizing in a nonconstructive way. I'm doing my best to pay myself back 2 years of development and laucnhing this all by myself. Now is a time for collaboration to make QubesOS more accessible to freedom defenders, journalists and others who needs this the most. I will do some of that development myself, made grant paper workto be able to pay other people's work and plan on doing that until we have something free to propose to the masses, which supports QubesOS. If you are knowledgeable/technical enough to be able to do it yourself and be able to own provable boot security, then you are more then welcome to do it yourself or be helped by a friend. If you are not in that situation, that is why I did that work and to be able to promote such solutions in my own security trainings for organizations and journalists. If you want to support my work, you are more then welcome to do it, by proposing collaboration and support other hardware through Heads or other Open Source Firmware where the same reownership logic could apply and guarantee integrity/security/confidentiality and in transit tamper evidence. As all of you, I would prefer promoting more performant hardware to the masses, but i'm not compromising myself in promoting FSP binary-blob dependent hardware initialized by non-free Coreboot, nor non-neuteured Intel ME or AMD equivalent crap running by default, or simply asked to be deactivated while binary blobs are still there in SPI flash. Cheers, Thierry/Insurgo Le mercredi 24 juillet 2019 13:54:53 UTC-4, travorfi...@gmail.com a écrit : > > Guyz, this is
[qubes-users] Re: EFI Xen Version
awokd: > When I boot a GRUB based Qubes PC, I see the Xen version is 4.8.5. > However, when I boot my UEFI one, Xen is 4.8.4. My guess is I am > pointing to the wrong .efi file, since I have to manually copy them to > BOOT folder when I update. Which one is the right one? There are three: > > /boot/efi/EFI/xen.efi. > /boot/efi/EFI/qubes/xen.efi > /boot/efi/EFI/qubes/xen-4.8.5-6.fc25.efi > > Should I be manually copying that last one over the first two whenever I > update it? They are different sizes and file dates. If you RTFM'd (step 3 of https://www.qubes-os.org/doc/uefi-troubleshooting/#boot-device-not-recognized-after-installing) you would see you need to copy the one with the long filename over top of the rest, including in BOOT/. Boot message and xl info showing the right Xen version now: 4.8.5-7.fc25 with the most recent update. -- 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/eba2f04e-dbc8-e528-5312-762623faaa51%40danwin1210.me.
[qubes-users] Re: is it possible to have two sys-net for one firewall vm?
On 7/22/19 2:51 PM, alain.cordat-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: hello, I use Qubes-os 4 on a computer which provides 2 ethernet intefaces. For my project iI need to separate these 2 interfaces (sys-net1, sys-net2). But i have to use only 1 firewall on which the 2 sys-net would be linked. Is it possible? I don't find the solution for the moment. One of these 2 sys-net is created without vif interface... Thanks a lot! Alain I know this is unrelated but when I look at Xentop I see two sys-net and 1 sys-firewall and 2 sys-vpn (appbased proxy VMs) but in Qubes manager there is 1 sys-net and 1 sys-vpnis this normal or what might cause 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/95343d88-e6cf-8771-d761-f406721cba4c%40riseup.net.
[qubes-users] Changing the clipboard shortcut in 4.0 doesn't work
I prefer to use a different shortcut for the Qubes clipboard because Ctrl+Shift+V is an existing shortcut for "paste without formatting" in most applications. However, I've tried editing /etc/qubes/guid.conf and restarting my VMs (I actually restarted my whole system), but no luck. I figure something changed now that the clipboard is a standalone application, but I'm not sure what needs to be modified. Thanks! -- 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/f89de975-447b-493d-bb12-0cf6b068cb97%40googlegroups.com.
Re: [qubes-users] Using Salt to update TemplateVMs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 24/07/2019 9.22 AM, unman wrote: > On Mon, Jul 22, 2019 at 07:38:27PM -0500, Andrew David Wong wrote: >> >> Sorry, I'm not following your example. What does it mean to "do the >> equivalent of qvm-create and qvm-prefs"? I had no idea you could create >> the effects of those commands without those commands. This sounds like a >> rather arcane area of Qubes wizardry into which I have not ventured. >> > > Actually you probably have ventured, but not realised it. > When you run the installer and configure the system, the various qubes > are created with salt. > The state files are in /srv/formulas/base/virtual-machines-formula/qvm > and you can inspect them there. > These files use templating. > > For example the sys-net.sls file uses: > name: sys-net > present: > - label: red > prefs: > - netvm: '' > - virt_mode: hvm > > etc etc > > You could get the same effect by calling the qvm functions directly: > > --- > sys-net: > qvm.present: > -name: sys-net > -template: debian-10 > -label: red > > sys-net-prefs: > qvm.prefs: > -netvm: '' > -virt_mode: hvm > --- > > If you look at the example I linked to you can see a breakdown of how to > create a Qubes builder qube. > The steps are: clone template and create qube, install necessary software in > template,configure qube. I've left that as simple as I can. > > By keeping these formulae, you can (re)create any aspects of your Qubes > system in a few commands. > Of course, you can do this using batch files calling qvm-create, > qvm-prefs, qvm-copy-to-vm, and assorted calls to qvm-run. imo the salt > formulae are clearer and easier to maintain. > > Also salt handles very well cases where (e.g) package names differ > between distributions, or you want the configuration to change between > debian-9 and debian-10, or between individual qubes, > > I'm happy to post simple examples if anyone wants to give a specification. > > unman > This is very instructive! Thank you, unman! - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl05KccACgkQ203TvDlQ MDC7lw//aAODJ4O990eexosaf9fihzizjysgIlIhv/00gaROt40+7fHbhE/AWnOz qhdzO6TCVp2NF6GFSlTWQDxNUErD2JuY7fitIPBFqeB50XR9MjtZKhPY6alGz9hY cyVy0wMvk1hd3rHUuyPzARsP1rK5rpc7nSTKR+T1v9t+yjG8OFIFw9hVvgUX0MZ9 A6qYsHnVonNBNh1LQy2yEd5MjkZbQKzJUkpq3/Ip16qQOsSrfy0tBjmGHyQq4U2c mfRQpobxWbMPJlgy0oqKQVPNe0fZQiOJWdXf2v5nFc64olNF01oBjFdGQxdrbnRS ytP0tndlDQ5fhItoJ993wP+vrkYopXgbKSUYnXDIxgtP07bxaEzIrkJq2ay5pmCG xxKtEhidKBgjUmV9bjpV50MT7fT+YNg6vIVtgGIlFHblzopE2rEiU4wjV5FsGNiJ bVGjfGkSni+uHeplJfPB+T8rBhRnKZV9qQK4noKTgOScn3lenweqUA7OfTRR1WNh 9j8r9z9PGMHw/qz1FIKhpoPQApuwF8BYj3L1XUrLc2pLkSAt5Codjlh7cZZm2p4q xmXmJmgj0sZiCzqz0q5X1s5YoCAbCpGla21VlxNGcxyB51BtIR3oW/YwTywsRxJR L52hoiT2Nvt5ywlaDKJxQnZ9YcVw1/oDeG7h8zkbKfFqA/mQaBU= =Ts5B -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/ee005c0c-9f6b-2667-dd6e-64f5c6fe9c28%40qubes-os.org.
[qubes-users] QSB #050: Reinstalling a TemplateVM does not reset the private volume
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Qubes Community, We have just published Qubes Security Bulletin (QSB) #050: Reinstalling a TemplateVM does not reset the private volume. The text of this QSB is reproduced below. This QSB and its accompanying signatures will always be available in the Qubes Security Pack (qubes-secpack). View QSB #050 in the qubes-secpack: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-050-2019.txt Learn about the qubes-secpack, including how to obtain, verify, and read it: https://www.qubes-os.org/security/pack/ View all past QSBs: https://www.qubes-os.org/security/bulletins/ ``` ---===[ Qubes Security Bulletin #50 ]===--- 2019-07-24 Reinstalling a TemplateVM does not reset the private volume Description === In Qubes OS, we have the ability to reinstall a TemplateVM by running `qubes-dom0-update --action=reinstall qubes-template-...` in dom0. [1] This is supposed to reset the corresponding TemplateVM to the state of the published package, i.e., no local changes should remain. One uncommon reason to perform such a reinstallation is that you suspect that a TemplateVM may be compromised. In such cases, it is very important that no local changes persist in order to ensure that the TemplateVM is no longer compromised. Due to a regression in R4.0 [2], however, reinstalling a TemplateVM using qubes-dom0-update does not completely reset all local changes to that TemplateVM. Although the tool itself and our documentation claim that the private volume of the TemplateVM is reset during reinstallation, the private volume does not actually get reset. This could allow a TemplateVM to remain compromised across a reinstallation of that TemplateVM using qubes-dom0-update. Workaround == Fixed packages are forthcoming. In the meantime, we recommend avoiding the qubes-dom0-update method of reinstalling a TemplateVM. Instead, we recommend manually removing the TemplateVM, then installing it again. Detailed instructions for this manual method are documented here: https://www.qubes-os.org/doc/reinstall-template/#manual-method (Note that we have updated this page with a warning against the automatic method.) Patching = We expect to have fixed packages available next week. In the meantime, please follow the workaround described in the previous section. We will update this QSB when fixed packages are available. Credits Thank you to Andrey Bienkowski for discovering and reporting this issue. References === [1] https://www.qubes-os.org/doc/reinstall-template/ [2] https://github.com/QubesOS/qubes-core-admin-linux/commit/552fd062ea2bb6c2d05faa1e64e172503cacbdbf#diff-6b87ee5cdb9e63b703415a14e5a505cdL192 - -- The Qubes Security Team https://www.qubes-os.org/security/ ``` This announcement is also available on the Qubes website: https://www.qubes-os.org/news/2019/07/24/qsb-050/ - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl05LEEACgkQ203TvDlQ MDCA2Q//SBZ/v5eDrOauzdvQcqpgDJHGZyT34b1POcu8u4iAFWXBrnBSYgefDN0d uMoxcZOy+q+GCy9r176MWl17m1td3ev/WnSgCwcUnDvegC2jLacixqMuoVxXDW3A 6Mvu/Ui73O7bh3fAemoRHP7ts4ZKCZ9LGWEcIzlzR+Sg6jYDLC2sg3xRhp+G1GLX Jduisn0ZnsTOGAgPnt0MZarn2MXoQt6A+6IwbN5g48Y/2anjiwz45Etkl9y2XTQZ kfWelmuraf+adKrbqEjYEapl6ARuPsuoR1rb3sSEqVApHZY1syfAioLNHbOfRrmW oqNPK/GnkOo7wWXyymZPQDDXor6GojYrLbocUcI+KcObiFnGEeqzzRp+s9lm641t cXHdk+309U1H+z7DRKWeeGW2UZ39hof14bxemWqQnIaLYn0flOX15ke8DANDh9dF 7BRDyTuoFBqOy3W8Ab1iJoVi5ZhyNDOOmzXzkvqyP0lzAtX2AtJlXWUGMIAo+Pqp z6JH3qXbpBZgJb71qIOU85Eb9FfYgseQa9y2msswiGCh/xpv+/il7WP577/w/FKr GzV/h2Bw/QTcFj+nLMCnCVF0RZ8XwZ9wz6p/Qy4DxYseNyV0C4efv0zrErzX9a4x /Ug8jcexTq96sawNTCLVIiIIdAtsIy3y7NCDQtjswiIxVCZKMcQ= =5Wik -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/f5c9a0d6-97ce-a7fa-8548-9a56e659b6cb%40qubes-os.org.
[qubes-users] Re: Confuse Update QUbes OS
On 7/19/19 9:11 PM, 'awokd' via qubes-users wrote: Luc libaweb: Hello, When I update my Dom0, I have : Failed to synchronize cach for repo "template" and "current" But, I have then nothing to do and complete. This error is usually temporary, like if you are having internet trouble. Try running update again. Qubes OS is updated ? My release cat is 4.0 but not 4.0.1 ? A fully patched install of 4.0 is no different than 4.0.1. I don't uderstand if I have to upgrade template or it's automatic whith the update tool. Thanks The update tool will update patches within templates. However, it does not handle updating to entirely new template versions like Fedora 29 to 30 or Debian 9 to 10. See https://www.qubes-os.org/doc/templates for those. if the debian 10 sentence is current, is the documentation soon to be updated ? any guesstimate on the -10 fresh templates ETA <-- sorry to ask :) PS: in tbird how does one reply to awokd I can a popup error recipient name rejected no domain found -- 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/577a44a3-ae99-7b8e-64b3-c2482cb33cb4%40riseup.net.
