[qubes-users] Qubes T-shirts, polos, and sweatshirts now available from HELLOTUX

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all,

Thanks to Frédéric, Qubes T-shirts, polos, and sweatshirts are now
available from HELLOTUX. A small portion of each purchase will be
donated back to the Qubes OS Project.

Please see this page for additional Qubes merchandise options and
general information:

https://www.qubes-os.org/merchandise/

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl8s81gACgkQ203TvDlQ
MDDDCw/+PkkWUl/rQ40dEbl35sMVAd8B4/SppqtIZdBs1C36XZGs/jXHNx7mnDE8
wAKplX7/Bi1bIrBwL1Nbvfqru9queT1jayNbCiM79P3flGwhp19I3U6oM7tdj0Je
czLiE0ZGcecUNECDHSFUYQib6uc2m8P0ded/r7mSIaGIA/6tjTzk8PQwa163xQ5m
pcFdaQhgPqm5iEzuAMEUtbTwt1z/lOia4tMNIVuLq8iEXQQy9OynjigBLi4OX6ZK
65qe+8C0bRkEAxE7rWbBiPDa4YPm30rIKVYFXWr7boH/OjWHHZfWSsmd2b5qUK3V
Xt5PaVfFgovpMkIoIS7CtkW7SANYM//dUxdo2PlW1PSO04pTFhmpz+6TYA/HSlrh
xr3tbp5VqX/5quHY1+daIwLwLsbzjV8RMJEokb6o7rbKAhqFCbqQVup7LeaNyK5O
dPivzxMyg1MSZYssRFRxD/M7Hz/WbjgYFQn2QYgCUwlLy+NumLUPVXFDiLf0N5PX
bhu7QouGYHRquDZRcmspQz71vvh90x8OAo0VDU8BnGlErtpNOioSfhXxwD69t3f6
CFrx+/BqFebm5dkBnLRiaRRCZe1UbUbV+5MpEJQKkGwQrZXjB++/XNX4NBRaLIu+
lt04CesC8MqjyXxZGkn/ZQt7OKucn+urPQ/qfPeO3B4MgkcAyhU=
=b+xD
-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/87eaeb72-89b0-5305-8bcd-29d64e929e70%40qubes-os.org.

Re: [EXT] Re: [qubes-users] Update templates in parallel

[fiftyfourthparallel]

On Friday, 7 August 2020 02:40:58 UTC+8, Chris Laprise wrote:
>
> Yes. Note that Qubes Security Bulletins are issued for vulns that affect 
> dom0 and they reference the package versions that contain the patches. 
> For example: 
>
>
> https://groups.google.com/d/msgid/qubes-users/34eddc9a-300c-743c-cb12-acc677f5784f%40qubes-os.org
>  
>
> However, most vulns that affect templates are not addressed by QSBs 
> because they're not Qubes-specific. That's one reason to avoid Fedora 
> templates in general. 
>
> -- 
> Chris Laprise, tas...@posteo.net  
> https://github.com/tasket 
> https://twitter.com/ttaskett 
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886 
>

That's great to know. I was worried my efforts at secure computing have 
been in vain. I suppose those who need to use Fedora should stick with 
CentOS. Thanks a bunch, Chris! 

-- 
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/dca34216-c0f4-44c5-892a-be53d3ab4c77o%40googlegroups.com.

[qubes-users] Playing Videos On Streaming Wesites

[Qubes]

Perhaps someone here can suggest something better than what I currently 
have. A default Firefox on a default Fedora-32 template does not play 
videos on something like Invidio.us. The video thumbnails display 
everything looks exactly as it should just the videos will not play.


I've been scratching around and found that if I install the 
qt5-qtwebengine-freeworld package then videos play on various video 
streaming platforms, including Invidio.us.


The 'problem' with having qt5-qtwebengine-freeworld installed in a 
fedora-32-media template (cloned from fedora-32), along with other bits 
of software , is it creates dependency issues. This causes trouble with 
the updater widget, it never goes away and it always displays updates 
for the fedora-32-media template. If the template is fully updated the 
widget will say it has outstanding updates. If you run through the 
process you get the output I have attached in the four files. This 
becomes endless. It is after having updated fedora-32-media several 
times and noticing the output of the update widget staying exactly the 
same that I ran 'sudo dnf upgrade' in a fedora-32-media terminal. Then 
seeing the below output.


Instead of trying to fix this, which would likely mean I would have to 
install qt5-qtwebengine-freeworld in a dedicated template, the scenario 
I would like to avoid, is there perhaps a different package that I can 
install that also enables playing videos on streaming websites?



[user@fedora-32-media ~]$ sudo dnf upgrade --refresh
Fedora 32 openh264 (From Cisco) - x86_64 
466 
B/s | 986  B 00:02
Fedora Modular 32 - x86_64 
6.3 
kB/s |  16 kB 00:02
Fedora Modular 32 - x86_64 - Updates 
6.3 
kB/s |  16 kB 00:02
Fedora 32 - x86_64 - Updates 
5.7 
kB/s |  14 kB 00:02
Fedora 32 - x86_64 
6.7 
kB/s |  16 kB 00:02
Qubes OS Repository for VM (updates) 
1.5 
kB/s | 3.8 kB 00:02
RPM Fusion for Fedora 32 - Free 
1.3 
kB/s | 3.1 kB 00:02
RPM Fusion for Fedora 32 - Nonfree 
1.4 
kB/s | 2.9 kB 00:02

Dependencies resolved.

 Problem 1: package qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64 
requires qt5-qtbase(x86-64) = 5.13.2, but none of the providers can be 
installed
  - cannot install both qt5-qtbase-5.14.2-5.fc32.x86_64 and 
qt5-qtbase-5.13.2-4.fc32.x86_64
  - cannot install both qt5-qtbase-5.13.2-4.fc32.x86_64 and 
qt5-qtbase-5.14.2-5.fc32.x86_64
  - cannot install the best update candidate for package 
qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64
  - cannot install the best update candidate for package 
qt5-qtbase-5.13.2-4.fc32.x86_64
 Problem 2: package vlc-core-1:3.0.9.2-3.fc32.x86_64 requires 
libdav1d.so.3()(64bit), but none of the providers can be installed
  - cannot install both libdav1d-0.7.1-1.fc32.x86_64 and 
libdav1d-0.5.2-2.fc32.x86_64
  - cannot install both libdav1d-0.5.2-2.fc32.x86_64 and 
libdav1d-0.7.1-1.fc32.x86_64
  - cannot install the best update candidate for package 
vlc-core-1:3.0.9.2-3.fc32.x86_64
  - cannot install the best update candidate for package 
libdav1d-0.5.2-2.fc32.x86_64
 Problem 3: package vlc-1:3.0.9.2-3.fc32.x86_64 requires 
libvlccore.so.9()(64bit), but none of the providers can be installed
  - package vlc-1:3.0.9.2-3.fc32.x86_64 requires vlc-core(x86-64) = 
1:3.0.9.2-3.fc32, but none of the providers can be installed
  - package vlc-core-1:3.0.9.2-3.fc32.x86_64 requires 
libebml.so.4()(64bit), but none of the providers can be installed
  - cannot install both libebml-1.4.0-1.fc32.x86_64 and 
libebml-1.3.10-2.fc32.x86_64
  - cannot install both libebml-1.3.10-2.fc32.x86_64 and 
libebml-1.4.0-1.fc32.x86_64
  - cannot install the best update candidate for package 
vlc-1:3.0.9.2-3.fc32.x86_64
  - cannot install the best update candidate for package 
libebml-1.3.10-2.fc32.x86_64

 Problem 4: problem with installed package vlc-core-1:3.0.9.2-3.fc32.x86_64
  - package vlc-core-1:3.0.9.2-3.fc32.x86_64 requires 
libmatroska.so.6()(64bit), but none of the providers can be installed
  - cannot install both libmatroska-1.6.0-1.fc32.x86_64 and 
libmatroska-1.5.2-2.fc32.x86_64
  - cannot install both libmatroska-1.5.2-2.fc32.x86_64 and 
libmatroska-1.6.0-1.fc32.x86_64
  - cannot install the best update candidate for package 
libmatroska-1.5.2-2.fc32.x86_64
 Problem 5: problem with installed package 
qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64
  - package qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64 requires 
libQt5Gui.so.5(Qt_5.13.2_PRIVATE_API)(64bit), but none of the pro

Re: [EXT] Re: [qubes-users] Update templates in parallel

[Chris Laprise]

On 8/6/20 12:23 PM, fiftyfourthparal...@gmail.com wrote:

On Friday, 7 August 2020 00:13:52 UTC+8, Chris Laprise wrote:

IIRC that setting refers to checking packages, not the repomd.xml
files.
That's why an attacker can't replace packages with their own versions;
they have to manipulate the metadata to hold back packages from
receiving updates.

-- 
Chris Laprise, tas...@posteo.net

https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886


So as long as I verify that the version numbers of packages in dom0 
match those of the actual repo website, I can assume that my dom0 
updates have not been tampered with by adversaries?


Yes. Note that Qubes Security Bulletins are issued for vulns that affect 
dom0 and they reference the package versions that contain the patches. 
For example:


https://groups.google.com/d/msgid/qubes-users/34eddc9a-300c-743c-cb12-acc677f5784f%40qubes-os.org

However, most vulns that affect templates are not addressed by QSBs 
because they're not Qubes-specific. That's one reason to avoid Fedora 
templates in general.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/69233e9d-5108-d729-77ba-85df12474e14%40posteo.net.

[qubes-users] HCL - Z97X-UD5H

[William Distelhorst]

Remarks: a TPM module will need to be installed before TPM function can be
enabled.

-- 
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/CA%2BeZGO0druUFgTHaCyPB2n9tHVM8Uh8-4fVUy0nm7CL9gFTq6A%40mail.gmail.com.


Qubes-HCL-Gigabyte_Technology_Co___Ltd_-Z97X_UD5H-20200806-134959.yml
Description: application/yaml


Qubes-HCL-Gigabyte_Technology_Co___Ltd_-Z97X_UD5H-20200806-134959.cpio.gz
Description: application/gzip

Re: [EXT] Re: [qubes-users] Update templates in parallel

[fiftyfourthparallel]

On Friday, 7 August 2020 00:13:52 UTC+8, Chris Laprise wrote:
>
> IIRC that setting refers to checking packages, not the repomd.xml files. 
> That's why an attacker can't replace packages with their own versions; 
> they have to manipulate the metadata to hold back packages from 
> receiving updates. 
>
> -- 
> Chris Laprise, tas...@posteo.net  
> https://github.com/tasket 
> https://twitter.com/ttaskett 
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886 
>

So as long as I verify that the version numbers of packages in dom0 match 
those of the actual repo website, I can assume that my dom0 updates have 
not been tampered with by adversaries? 

-- 
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/7dc6bda2-e90f-47d1-a8c2-809cf1d996dco%40googlegroups.com.

Re: [EXT] Re: [qubes-users] Update templates in parallel

[Chris Laprise]

On 8/6/20 10:37 AM, fiftyfourthparal...@gmail.com wrote:

I hate to break that feeling, but Fedora is unique in that it doesn't
sign its repo metadata, and sadly that is what matters. They put a
bandaid on it by fetching more hashes via https... so the update
security in Fedora is based on the strength of https. That is bad, as
https can be subverted by resourceful attackers.


On the other hand, following the instructions on these sites shows me 
that /etc/yum.conf and the repos in /etc/yum.repos.d/  all have 
gpgcheck=1. I'm not sure what this means.


https://www.qubes-os.org/doc/security-guidelines/

https://docs.fedoraproject.org/en-US/Fedora/12/html/Deployment_Guide/sec-Configuring_Yum_and_Yum_Repositories.html 


IIRC that setting refers to checking packages, not the repomd.xml files. 
That's why an attacker can't replace packages with their own versions; 
they have to manipulate the metadata to hold back packages from 
receiving updates.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/acb5bfda-3d1e-1fac-051a-fae865491f19%40posteo.net.

Re: [EXT] Re: [qubes-users] Update templates in parallel

[fiftyfourthparallel]

>
> I hate to break that feeling, but Fedora is unique in that it doesn't
> sign its repo metadata, and sadly that is what matters. They put a
> bandaid on it by fetching more hashes via https... so the update
> security in Fedora is based on the strength of https. That is bad, as
> https can be subverted by resourceful attackers.


On the other hand, following the instructions on these sites shows me that 
/etc/yum.conf and the repos in /etc/yum.repos.d/  all have gpgcheck=1. I'm 
not sure what this means.

https://www.qubes-os.org/doc/security-guidelines/

https://docs.fedoraproject.org/en-US/Fedora/12/html/Deployment_Guide/sec-Configuring_Yum_and_Yum_Repositories.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/0950de97-2bf0-44ad-9c06-fb1be34a93e7o%40googlegroups.com.

Re: [EXT] Re: [qubes-users] Update templates in parallel

[fiftyfourthparallel]

On Thursday, 6 August 2020 18:05:25 UTC+8, Chris Laprise wrote:
>
> I hate to break that feeling, but Fedora is unique in that it doesn't 
> sign its repo metadata, and sadly that is what matters. They put a 
> bandaid on it by fetching more hashes via https... so the update 
> security in Fedora is based on the strength of https. That is bad, as 
> https can be subverted by resourceful attackers. 
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1130491 
>
> What this potentially allows is an attacker to blind Fedora systems to 
> specific package updates, where the systems appear to retrieve updates 
> normally without the users being aware that particular packages with 
> known vulnerabilities have been held back. 
>
> -- 
> Chris Laprise, tas...@posteo.net  
> https://github.com/tasket 
> https://twitter.com/ttaskett 
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886 
>

That's highly concerning and might put me off from using Qubes for 
sensitive work, which defeats the entire purpose of installing Qubes. This 
is a massive gaping whole that, to me, invalidates all the other security 
strengths of Qubes, since dom0 is the key to the kingdom.

The reason why I'm anxious about the security of packages is because my 
dom0 has exhibited strange behavior not present before my dom0 update (and 
I know because I spent a lot of time with my OS before connecting it for 
the first time). My dom0 update itself has been behaving strangely and I 
made a post about it earlier, where I also asked about package 
verification, but received no response.

>
> Hi all,
>  
> Every time I use qubes-dom0-update in a fresh installation (which I've 
> done around ten times now), I get strange outputs where the repositories 
> aren't shown being queried but the update proceeds. It looks something like 
> this: 

error:could not delete old database at /var/lib/qubes/dom0-updates/home/user
> /.rpmdbold.965
> https://
> mirrors.phx.ms/qubes/repo/yum/r4.0/current/dom0/fc25/repodata/repomd.xml:[Errno
>  
> 
>  14]curl#6-"Could 
> not resolve host:mirror.phx.ms"
> Trying other mirror.
> https://mirror.linux.pizza/
> qubes-os.org/repo/yum/r4.0/current/dom0/fc25/repodata/repomd.xml:[Errno14]HTTPS
>  
> 
>  Error 
> 404 -Not Found
> Trying other mirror.
> https://mirror.linux.pizza/
> qubes-os.org/repo/yum/r4.0/templates-til/repodata/repomd.xml:[Errno 
> 
>  14] 
> HTTPS Error 404 - Not Found
> Trying other mirror.
> No Match for argument
> No Match for argument
> No Match for argument
> No Match for argument
> No Match for argument
> No Match for argument
> No Match for argument
> No Match for argument
> -->Running transaction check
> --->Package kernel[...] will be installed
>
>
> [...]
> --->Finished Dependency Resolution
> [Starts downloading]
> This is consistent even when updating over tor, and has been bugging me. 
> Does anyone else see this when they first update dom0? 


 Also, it dom0 update consistently gives me two [Y/n] prompts in a row 
before installation, which seems very strange.

-- 
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/3ffe-d63d-4247-a548-eb2b7731bd9do%40googlegroups.com.

Re: [qubes-users] Re: Whonix-gw: trouble after disabling passwordless root access

[fiftyfourthparallel]

On Thursday, 6 August 2020 17:36:05 UTC+8, Chris Laprise wrote:
>
> IIRC she gave some indication that guest VMs shouldn't be defenseless 
> internally. 
>
> -- 
> Chris Laprise, tas...@posteo.net  
> https://github.com/tasket 
> https://twitter.com/ttaskett 
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886 
>

Found it!

There might be potential attacks against the hypervisor or daemons/backends 
in dom0 that require root access. Qubes founder Joanna Rutkowska initially 
assessed there was limited benefit from isolating the root account from the 
user account, because all user data is already accessible from the latter 
 
[archive] 
.
 
However, she later changed her opinion on the matter; see here 

 [archive] 

.

https://www.whonix.org/wiki/Qubes-Whonix_Security#cite_note-11 

https://web.archive.org/web/20200323113623/https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-301316132

The Whonix documentation for Qubes is actually generally applicable beyond 
Whonix--I highly recommend anyone interested in securing their computers 
look around the Whonix wiki (i.e. basically everyone reading this). The 
page I linked is a good starting point. Kudos to the Whonix Wiki maintainer.


>My own philosophy (which prompted me to create Qubes-VM-hardening) is
that if we're going to have these VMs running regular OSes, they should
at least have their normal security or some equivalent intact. And also
that the combination of normal security and Qubes security should yield
extra benefits, which I think Qubes-VM-hardening does.

This is what baffles me about some people's mindsets--if they prize 
security so much that thet take the time and trouble to install and learn 
Qubes --no small feat for most of us-- why not go a bit further and batton 
down the hatches of their VMs? It's usually a one-time investment that 
requires little to no maintenance with a huge payoff with regard to their 
goal (which I presume is secure computing). Kudos to you for making this 
process a heck of a lot easier for non-technical people, like me.

-- 
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/222144ba-abd7-41c8-a68e-2a4aa88dff0eo%40googlegroups.com.

Re: [qubes-users] GPT or MBR?

[Stumpy]

On 2020-08-05 21:13, unman wrote:

On Wed, Aug 05, 2020 at 09:04:41PM +0200, Qubes wrote:

On 8/5/20 8:31 PM, Stumpy wrote:

On 2020-08-05 12:06, Stumpy wrote:

I have win installed on a drive with mbr, should I be able make a
vhd and convert that to a RAW and run it as a template in Qubes?

If i remember correctly gpt does not play well with qubes?



I guess more to the point, "MBR is better" or "GPT is better" or "either
is fine" is what I am looking for.
Thanks!


Coreboot is better, look into Coreboot, https://www.coreboot.org.

Otherwise I would rank UEFI above BIOS in terms of security.




GPT is part of the UEFI standard, but can be used with legacy BIOS.
Coreboot, UEFI, and legacy BIOS are not clearly related to partition
tables, which is what MBR and GPT are.
Both are fine in the context of Qubes.
Stock templates are built using gpt.



Great, thank you both - I actually wasnt clear on how BIOS, Coreboot, 
and UEFI relate to MBR and GPT.


Cheers

--
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/4aa17e3d-94b4-c233-4e19-32c9fb3d7044%40posteo.net.

Re: [EXT] Re: [qubes-users] Update templates in parallel

[Chris Laprise]

On 8/6/20 3:54 AM, fiftyfourthparal...@gmail.com wrote:

On Thursday, 6 August 2020 12:31:44 UTC+8, Emily wrote:


-- I'm not unman, but I just checked the repo data and it appears
they use sha256


This is reassuring. Thanks, Emily


I hate to break that feeling, but Fedora is unique in that it doesn't 
sign its repo metadata, and sadly that is what matters. They put a 
bandaid on it by fetching more hashes via https... so the update 
security in Fedora is based on the strength of https. That is bad, as 
https can be subverted by resourceful attackers.


https://bugzilla.redhat.com/show_bug.cgi?id=1130491

What this potentially allows is an attacker to blind Fedora systems to 
specific package updates, where the systems appear to retrieve updates 
normally without the users being aware that particular packages with 
known vulnerabilities have been held back.


Note that RHEL and Centos _do_ sign their repomd.xml. So we're looking 
at some kind of decision made either by Red Hat's marketing department 
(keep Fedora off RHEL's expensive turf) or by some idea that Fedora is 
not for serious mission critical environments, or both.


So this is a sizable hole in Qubes security. The best advice I can give 
is to avoid using Fedora templates and pay attention to Qubes Security 
Bulletins when they mention which dom0 components will be updated (and 
pay close attention when running qubes-dom0-update to look for the 
mentioned components).


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/6ca8adf5-f8bc-3995-2db3-10c347835b72%40posteo.net.

Re: [qubes-users] Re: Whonix-gw: trouble after disabling passwordless root access

[Chris Laprise]

On 8/5/20 11:48 PM, fiftyfourthparal...@gmail.com wrote:

On Thursday, 6 August 2020 00:37:08 UTC+8, Qubes wrote:

What risk(s) are you mitigating by disabling passwordless root?


  You should look at this the other way around--what do I stand to lose 
by keeping passwordless root? If I can take a low-cost step that would 
dramatically raise the cost for would-be attackers, wouldn't it be a 
prudent step to take? Besides, even Joanna herself backtracked on her 
claim that passwordless root is the best option (forgot where I read it, 
but I definitely did)


IIRC she gave some indication that guest VMs shouldn't be defenseless 
internally.


My own philosophy (which prompted me to create Qubes-VM-hardening) is 
that if we're going to have these VMs running regular OSes, they should 
at least have their normal security or some equivalent intact. And also 
that the combination of normal security and Qubes security should yield 
extra benefits, which I think Qubes-VM-hardening does.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/b0affe12-6844-38db-509b-ee5d60f68a2a%40posteo.net.

Re: [EXT] Re: [qubes-users] Update templates in parallel

[fiftyfourthparallel]

On Thursday, 6 August 2020 12:31:44 UTC+8, Emily wrote:
>
>
> -- I'm not unman, but I just checked the repo data and it appears they 
> use sha256
>

This is reassuring. Thanks, Emily

-- 
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/e4058562-8112-4264-9de2-cc4e45eb5e6co%40googlegroups.com.