[qubes-users] qubes-split-ssh

[panina]

Hi!

Is anyone else using qubes-split-ssh these days?
I've been using it quite a long time, even though it's looking quite
outdated.
Today I realized something's happened to it - any ssh'ing I'm doing
takes an extremely long time to react.

Does anyone know what might be causing this? I'm not seeing anything in
the logs of the affeccted machines (ssh VM, ssh-vault VM, or dom0).

<3
/panina

-- 
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/81718bcf-cc25-f818-76d7-0aacd4ba403a%40nonbinary.me.


0x98EA97021E90087B.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Re: slightly off-topic: self-resetting OS idea

[panina]

On 8/29/19 8:52 PM, scoobyscra...@gmail.com wrote:
> You may want to take a look at Fedora's Silverblue immutable desktop
> operating system.  I had problems installing the latest version but
> conceptually the OS in time will be a good alternative to Qubes which I
> use as my daily driver.

Flawless, I had forgotten about this. It seems to be exactly what I'm
after. Hope it can handle my hardware.
But if not, I'll just wait for it to mature.

> 
> -- 
> 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/80448924-78cc-42c4-9ec2-c21fbed1d181%40googlegroups.com
> .

-- 
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/cf823de5-853f-1f62-ae47-ce8f61b04354%40nonbinary.me.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Re: nmcli loosing connectivity

[panina]

On 8/26/19 9:04 PM, 'awokd' via qubes-users wrote:
> panina:
> 
>> What usually happends is that the system looses connectivity from time
>> to time. Sys-net reports the wifi as connected, but cannot ping my
>> gateway. The solution is to use nmcli to bring the connection down, and
>> up again. This will most of the time bring up the connectivity again.
>> Restarting the NetworkManager service does not help.
> 
> Try swapping your sys-net template from Fedora to Debian or vice-versa.
> Sometimes one distro will handle a wifi card better than another.
> 

Brilliant idea!
But sadly turned out to be mainly informative. Debian doesn't see the
wifi card at all, it only works on fedora 29 & 30 (not 28). But I've
tried fedora 29 & 30 baremetal on this machine, and this doesn't happen
there. So it is either Qubes- or Xen-specific.

Any other ideas are welcome.

<3
/panina

-- 
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/9b986494-14a2-c315-96a8-4fa774a34dd8%40nonbinary.me.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] slightly off-topic: self-resetting OS idea

[panina]

On 8/26/19 11:22 AM, David Hobach wrote:
> On 8/26/19 10:24 AM, panina wrote:
>> Hi!
>>
>> This is not strictly Qubes-OS related, rather inspired by Qubes.
>>
>> I've been struggling with some parts of Qubes usage. Most of the time,
>> it is overkill for me, and putting some strain on my computer. The
>> bugginess is also quite annoying, whenever I just need to do some
>> everyday work.
>> I've been thinking I'd like some form of dual-boot solution, or possibly
>> a Live USB that could be used.
>> Most of the time I work with ssh and webapps, so the only persistent
>> data I need to work will fit on a smartcard.
>>
>> My thought is to have an installation that mounts most of the root
>> partition as readonly, and uses ramdisks wherever the system wants to
>> write (e.g /var/log). I'm also thinking it should be possible to get a
>> fingerprint or somesuch of the root partition, and use my TPM2 to check
>> this.
>>
>> The system should also have a possibility to update itself, that I can
>> choose to do in environments that I feel is safe.
>>
>> I am wondering if anyone knows of an OS that works like this? Or if
>> anyone knows of tools that might accomplish parts of this?
> 
> Ehm... You're describing Qubes OS with disposable VMs there? The
> fingerprinting is essentially AEM?
> 
> If you need to keep your data on an external disk (SDCard), you can use
> either a manual approach with qvm-copy, permanently attach the disk to a
> single disposable VM with a fixed name or use an automated solution such
> as [1]. You might also want to look into qvm-pool.
> 
> [1] https://github.com/3hhh/qcrypt
> 

What I'm after is something that does what dvm's do, but not through
Qubes. Same effect, on something that boots on a USB stick or so, much
in the way that Tails does.

<3
/eira

-- 
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/033531db-0710-5e95-3f6d-25ba81aa7048%40nonbinary.me.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Qubes/class, Was: slightly off-topic: self-resetting OS idea

[panina]

On 8/26/19 6:27 PM, 799 wrote:
> Hello
> 
> David Hobach mailto:trip...@hackingthe.net>>
> schrieb am Mo., 26. Aug. 2019, 11:22:
> 
>     On 8/26/19 10:24 AM, panina wrote:
> > Hi!
> >
> > This is not strictly Qubes-OS related, rather inspired by Qubes.
> >
> > I've been struggling with some parts of Qubes usage. Most of the time,
> > it is overkill for me, and putting some strain on my computer. The
> > bugginess is also quite annoying, whenever I just need to do some
> > everyday work.
> > I've been thinking I'd like some form of dual-boot solution, or
> possibly
> > a Live USB that could be used.
> > Most of the time I work with ssh and webapps, so the only persistent
> > data I need to work will fit on a smartcard.
> >
> > My thought is to have an installation that mounts most of the root
> > partition as readonly, and uses ramdisks wherever the system wants to
> > write (e.g /var/log). I'm also thinking it should be possible to get a
> > fingerprint or somesuch of the root partition, and use my TPM2 to
> check
> > this.
> >
> > The system should also have a possibility to update itself, that I can
> > choose to do in environments that I feel is safe.
> >
> > I am wondering if anyone knows of an OS that works like this? Or if
> > anyone knows of tools that might accomplish parts of this?
> 
> Ehm... You're describing Qubes OS with disposable VMs there? The
> fingerprinting is essentially AEM?
> 
> If you need to keep your data on an external disk (SDCard), you can use
> either a manual approach with qvm-copy, permanently attach the disk
> to a
> single disposable VM with a fixed name or use an automated solution
> such
> as [1]. You might also want to look into qvm-pool.
> 
> [1] https://github.com/3hhh/qcrypt
> 
> 
> I don't know why people are complaining about the "bugginess" and that
> it needs more performance.
> 
> If you buy the right hardware you'll not run into lots of bugs and get
> enough performance to run qubes. You can buy a Lenovo T530/430, W530,
> X230 for not much money, add a SSD some RAM and you'll not run into
> performance problems (normal use).

This is a view that I see quite a lot. It is a whole different
discussion. Hence the re-subjecting.

Firstly, this view completely lacks class analysis. Not everyone can
afford to buy the newest shiny. A lot of us have to use whatever we can
get our hands on.
Whenever a secure OS is mentioned, Qubes is the go-to. Everyone comes
here. The approach that you have to buy new, specific hardware to have a
functioning OS means anyone poor, or in a country with a poor dollar
exchange rate, is left behind.
If Qubes was one of many options, this would cause less damage. But
right now, there aren't many alternatives. So privacy and secure tech
becomes an economic issue, a luxury. I firmly claim that basic privacy
should be a human right.

However, this is a completely different discussion.

Furthermore, Qubes currently concentrates on Intel hardware. I do not in
any way feel that this is a sane choice right now. I feel it would be
rather stupid to buy new hardware right now that has Intel processors.
Too many security issues, and new ones popping up all the time.
So my second problem is: this approach would assume that I agree with
every choice that the Qubes team does, which I don't.

> 
> As David mentioned Qubes will do exactly what you need if you're using
> disposable VMs.
> Regarding the fingerprinting, you can use AEM (Anti Evil Maid) or write
> your own script.
> I tried something which will fingerprint all files in /boot and gpg sign
> the signature which is then stored in the LUKS encrypted root partition.
> 
> You can then free booting into Qubes check the current boot Partition
> against the fingerprints.
> https://github.com/one7two99/my-qubes/tree/master/docs/boot-protect
> 
> Not sure if this is really secure, would be nice to have this checked by
> someone who knows more about security.
> 
> [799]
> 
> -- 
> 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
> <mailto:qubes-users+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/CAJ3yz2vkPZAv4pTQzTn9_W%2Bp_yC5_ZtOz3rmdvi59on60u88Qw%40mail.gmail.com
> <https://groups.google.com/d/msgid/qubes-users/CAJ3yz2vkPZAv4pTQzTn9_W%2Bp_yC5_ZtOz3rmdvi59on60u88Qw%40mail.gmail.c

[qubes-users] nmcli loosing connectivity

[panina]

Hello

I've been using Qubes as my everyday OS for a month or so.
During the whole time I've had a lot of wifi issues. I'm guessing it
might be some problem with the passthrough, but am not sure.

What usually happends is that the system looses connectivity from time
to time. Sys-net reports the wifi as connected, but cannot ping my
gateway. The solution is to use nmcli to bring the connection down, and
up again. This will most of the time bring up the connectivity again.
Restarting the NetworkManager service does not help.

Does anyone recognize this issue, and does anyone have ideas on how to
find the bug?

My system is an AMD Lenovo Thinkpad A485, and my WiFi card is an Realtek
RTL8822BE.
The WiFi works fine under basic Fedora.

Grateful for any ideas, and just ask for more info (eg logs) if needed

<3
/panina

-- 
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/9500f313-3c07-49c5-5c06-15bae8ca592e%40nonbinary.me.


signature.asc
Description: OpenPGP digital signature

[qubes-users] slightly off-topic: self-resetting OS idea

[panina]

Hi!

This is not strictly Qubes-OS related, rather inspired by Qubes.

I've been struggling with some parts of Qubes usage. Most of the time,
it is overkill for me, and putting some strain on my computer. The
bugginess is also quite annoying, whenever I just need to do some
everyday work.
I've been thinking I'd like some form of dual-boot solution, or possibly
a Live USB that could be used.
Most of the time I work with ssh and webapps, so the only persistent
data I need to work will fit on a smartcard.

My thought is to have an installation that mounts most of the root
partition as readonly, and uses ramdisks wherever the system wants to
write (e.g /var/log). I'm also thinking it should be possible to get a
fingerprint or somesuch of the root partition, and use my TPM2 to check
this.

The system should also have a possibility to update itself, that I can
choose to do in environments that I feel is safe.

I am wondering if anyone knows of an OS that works like this? Or if
anyone knows of tools that might accomplish parts of this?

<3
/panina

-- 
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/38cd264c-51ba-a468-b514-438896b377cb%40nonbinary.me.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Re: whonix tor browser customization

[panina]

On 8/23/19 11:12 PM, Matthew Finkel wrote:
> On Fri, Aug 23, 2019 at 7:59 PM  wrote:
>> panina:
>>> On 7/31/19 5:35 PM, 'awokd' via qubes-users wrote:
>>>> panina:
>>>>> Hello.
>>>>>
>>>>>
>>>>> I've been looking for how to fix some bad default settings in the whonix
>>>>> tor browser. Namely, they removed NoScript from the toolbar, so that the
>>>>> NoScript cannot be used as intended.
>>>>>
>>>>> Since it's not adviced (and not easily possible) to start the browser in
>>>>> the template, I have to do this manually each time I start a whonix dvm.
>>>>> Since this is cumbersome, I'm not using the NoScript plugin as intended.
>>>>>
>>>>> Does anyone know how to get this plugin into the toolbar for each dvm? I
>>>>> realize that this is a Whonix issue, but all of the affected users are
>>>>> on this list...
>>>>
>>>> You might be able to hack it like in 14-
>>>> https://forums.whonix.org/t/how-do-i-customise-tor-browser-in-a-whonix-templatebased-dvm-in-whonix-14/5580/27.
>>>> Note it may compromise anonymity by making your browser unique or at
>>>> least less generic.
>>>>
>>>
>>> Can't seem to get this working. I get confused by how the dvm's work,
>>> and am not succeeding in starting any applications in the dvm template.
>>>
>>>
>>>
>>> On 8/9/19 9:05 AM, Patrick Schleizer wrote:
>>>>> panina:
>>>>> Namely, they removed NoScript from the toolbar, so that the
>>>>> NoScript cannot be used as intended.
>>>>
>>>>
>>>> We did not. Decision by upstream, The Tor Project.
>>>>
>>>>
>>> https://forums.whonix.org/t/workstation-15-dropped-both-noscript-and-https/7733
>>>
>>> Thanks, duly noted. Is there any chance to get them to add a setting for
>>> this? Or re-think their decision?
>>>
>>> <3
>>> /panina
>>>
>>
>>> Thanks, duly noted. Is there any chance to get them to add a setting for
>>> this? Or re-think their decision?
>>
>> Please see:
>> https://trac.torproject.org/projects/tor/ticket/30600
>> https://trac.torproject.org/projects/tor/ticket/30570
>>
>> TL;DR The TBB developers pushed out some half-baked changes that
>> compromise UX, are hostile to the idea of reverting those changes, and,
>> three months later, apparently have zero interest in fully baking those
>> changes.
>>
>> ¯\_(ツ)_/¯
> 
> That's a little harsh, isn't it? Saying there is no interest is
> ignoring the fact that Tor Browser is maintained by a team of 10
> people for four different operating systems. Tor Browser is useless
> (and actively harmful) if users are confused about which settings they
> should change (due to careful design choices) and which settings they
> shouldn't change. The Noscript and https-everywhere buttons on the
> toolbar allowed people to tweak the settings easily, and this was not
> something a normal user should do. If someone really needs to change
> these settings, then they can go through a more complicated procedure
> for accomplishing that.
> 
> The team will finish implementing this, but (in particular) the
> highest priority task right now is migrating the Tor Browser patches
> and build system from Firefox 60esr to 68esr within the next few
> weeks.
> 

Well, personally the Tor browser is largely useless with default
settings. I'm actively avoiding recommending Tor Browser to
non-technical users right now since it breaks webpages. Almost a
majority of them.
It's gone from being a superb way of hiding your traffic, usable by
everyday surfers behind government firewalls. The privacy-aware crowd
has been accused of being elitist, and this move is in line with that
accusation.

But the politics of TB isn't what this mailing list is for.

Since I can't seem to hack the whole template/DVM scheme, I think I'll
just have to go back to my own tweaked firefox setup. I guess I can put
that behind a whonix gateway, should go some way towards being anonymized...

wish a better day for y'all
/panina

-- 
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/fda5fa35-8090-ecf5-2c73-269ef63d79d1%40nonbinary.me.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Re: whonix tor browser customization

[panina]

On 7/31/19 5:35 PM, 'awokd' via qubes-users wrote:
> panina:
>> Hello.
>>
>>
>> I've been looking for how to fix some bad default settings in the whonix
>> tor browser. Namely, they removed NoScript from the toolbar, so that the
>> NoScript cannot be used as intended.
>>
>> Since it's not adviced (and not easily possible) to start the browser in
>> the template, I have to do this manually each time I start a whonix dvm.
>> Since this is cumbersome, I'm not using the NoScript plugin as intended.
>>
>> Does anyone know how to get this plugin into the toolbar for each dvm? I
>> realize that this is a Whonix issue, but all of the affected users are
>> on this list...
> 
> You might be able to hack it like in 14-
> https://forums.whonix.org/t/how-do-i-customise-tor-browser-in-a-whonix-templatebased-dvm-in-whonix-14/5580/27.
> Note it may compromise anonymity by making your browser unique or at
> least less generic.
> 

Can't seem to get this working. I get confused by how the dvm's work,
and am not succeeding in starting any applications in the dvm template.



On 8/9/19 9:05 AM, Patrick Schleizer wrote:
>> panina:
>> Namely, they removed NoScript from the toolbar, so that the
>> NoScript cannot be used as intended.
>
>
> We did not. Decision by upstream, The Tor Project.
>
>
https://forums.whonix.org/t/workstation-15-dropped-both-noscript-and-https/7733

Thanks, duly noted. Is there any chance to get them to add a setting for
this? Or re-think their decision?

<3
/panina

-- 
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/7e5ed1da-15bc-4431-9f6d-d4edfaa83106%40nonbinary.me.


signature.asc
Description: OpenPGP digital signature

[qubes-users] whonix tor browser customization

[panina]

Hello.


I've been looking for how to fix some bad default settings in the whonix
tor browser. Namely, they removed NoScript from the toolbar, so that the
NoScript cannot be used as intended.

Since it's not adviced (and not easily possible) to start the browser in
the template, I have to do this manually each time I start a whonix dvm.
Since this is cumbersome, I'm not using the NoScript plugin as intended.

Does anyone know how to get this plugin into the toolbar for each dvm? I
realize that this is a Whonix issue, but all of the affected users are
on this list...


<3

/panina

-- 
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/5d8da716-2d18-6cf5-6cfb-12f1fe348be5%40kontrapunktmalmo.net.


0x6648B5C5E394CC24.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] R4 system requirements; AMD compatibility?

[panina]

edora/X11 issue. The display does
>>>> turn off when the lid is closed and lid-switch is set to "do
>>>> nothing," though.
>>>
>>> I usually have to switch to KDE with sddm to get this working.
>>
>> I think I had it working temporarily on my current machine by directly
>> using X11 commands, it was just XFCE not using them correctly or
>> something. It must happen to a lot of people, if you ran into it as
>> well. That's something I can worry about later too. I'll keep sddm in
>> mind and see if that fixes it.
>>

This one works for me, but I also run KDE. Don't remember it from XFCE
though, I think that worked for me there.

>>>
>>>>
>>>> 5) ...plus a few other minor issues probably not hardware related.
>>>>
>>>>
>>>>
>>>> Right now I'm trying to decide if I can live without suspend. But,
>>>> this is such a common problem that I'm afraid the next one I trade
>>>> it in for would have the same problem, and the next one after that.
>>>> Then I spent twice the money and got nowhere. This issue is
>>>> all-too-common on laptops running Linux. It could be fixed (or
>>>> broken) on any machine at any time in a random kernel update, too,
>>>> but who knows.
>>>>
>>>> This is especially a problem because Xen doesn't support hibernation
>>>> at all (not to mention whether it would actually work), and Qubes
>>>> doesn't support Xen's "save VM state" feature, either of which I
>>>> could live with instead. So my only choices are "on" and "off."
>>>
>>> This is an excellent point, and I think there is a Qubes issue about
>>> VM hibernation...
>>
>> #2414, which hasn't had any activity in two years.
>>
>>>
>>>>
>>>> Besides suspend being broken, I actually really like it, and you
>>>> can't go wrong for the price.
>>>>
>>>> I think I'm going to try installing Ubuntu and testing suspend from
>>>> there, and also trying to update the firmware from fwupd, but I'm
>>>> not holding my breath.
>>>
>>> That's what I would also try first. Qubes 2.0 used to make my
>>> ethernet NIC go dead, but booting temporarily with an Ubuntu live cd
>>> would get it working again and I could use it in Qubes after that
>>> until I did a Qubes-to-Qubes reboot. Problem stopped around Qubes
>>> 4.0. :)
>>>
>>>>
>>>> So, any advice on troubleshooting suspend... or advice on what to do
>>>> next, I guess... would be appreciated. Ugh, this is totally
>>>> frustrating.
>>>
>>> You should try these:
>>>
>>> * Find which wifi modules are being used in sys-net (i.e. do "sudo
>>> lsmod") then add them to /rw/config/suspend-module-blacklist. I find
>>> this is usually required to get suspend working right. For an Intel
>>> wifi card, you would add both 'iwldvm' and 'iwlwifi' in that order.
>>
>> I didn't think of wifi modules preventing suspend. I'll definitely
>> give it a try, but I'm not sure it could cause the kind of problem I'm
>> having. It doesn't seem like it's even trying to wake up when I press
>> a key or the power button. It just stays sleeping. The only observable
>> difference between sleep and off is that in sleep pressing the power
>> button doesn't turn the machine on until I power cycle. Also, I tried
>> enabling "USB Wake Support" in BIOS, but it didn't seem to make a
>> difference.

This looks interesting, I'll give this a try. I just shelved my
suspension issues, since I thought it wasn't qubes-specific, was going
to nag lenovo about it...

>>
>>>
>>> * Upgrade the dom0 and vm kernels to 4.19 or later. The 4.19 versions
>>> from qubes*testing have been very stable for me. OTOH, there are also
>>> 5.x versions available.
>>>
>>
>> I did `qubes-dom0-upgrade --enablerepo=qubes-dom0-unstable kernel` and
>> I still couldn't get a newer kernel. 4.14.199-2 popped up and it said
>> "nothing to do." What am I doing wrong?
> 
> Got it. current-testing, not -unstable. Sometimes I don't know how to
> read, haha. I guess I just assumed unstable was newer than testing.
> 

Confused me as well... But yeah, 4.19 seems really important for ryzen,
a lot apparently happened there.

>>
>> It doesn't seem like VM kernels would make a difference with suspend,
>> but I can try upgrading them anyways.
>>
>> Thanks again
> 
> 
> -
> This free account was provided by VFEmail.net - report spam to
> ab...@vfemail.net
> 
> ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of
> the NSA's hands!
> $24.95 ONETIME Lifetime accounts with Privacy Features!  15GB disk! No
> bandwidth quotas!
> Commercial and Bulk Mail Options! 

So yeah, a lot of this looks like it's ryzen-specific, and not due to
consumer-grade hardware. Mine isn't the most expensive thinkpad around,
I guess, but I can't really call it cheapish.

<3
/panina

-- 
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/97da8240-54be-4086-a22f-45b595065868%40nonbinary.me.


0x6648B5C5E394CC24.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] The PGP Encryption Problem

[panina]

On 7/17/19 1:11 PM, Chris Laprise wrote:
> On 7/17/19 5:40 AM, ronpunz wrote:
>> Reading this article,
>> https://latacora.micro.blog/2019/07/16/the-pgp-problem.html, it's clear
>> the authors have little to no confidence in the security or capabilities
>> of PGP encryption.
>>
>> Is this article a scare mongering propaganda exercise or do they have
>> valid concerns about why we should not be using PGP? The seem to
>> advocate using OPENBSD's Signify - do we move to this?
> 
> I worry when I read articles like this, because they make some good
> points (along with some bad ones) against PGP but their recommendations
> often demonstrate a blindness to the things they're criticizing.
> 
> Case in point: 'Use Signal.' While Signal is a pleasure to use for many
> people, its tied to identities in the telephone system, which is a
> problem from the 1890s not 1990s. When I see this slip up, I start
> worrying about the soundness of their other recommendations.
> 
> I also don't necessarily agree with the idea that many different
> encryption tools should be used for many different purposes. This is
> another red flag for me, because it hides deeper UX and compatibility
> issues behind a veneer of simplistic apps.
> 
> Yet another red flag is the way the author treats some of PGP's problems
> as specific to an old design, when really the problem is more
> fundamental. Leaking metadata, for example, is a common problem that
> bedevils even programs like Tor.
> 
> And yet another is arguing from the assumption that Web Of Trust is a
> necessary ingredient in PGP usage. It isn't, and that fact dispels many
> claims that PGP is too complex to use.
> 
> IMO, the reason we're having this bout of "don't use PGP" is the
> keyserver vulnerability that enables the recent spate of DoS attacks.
> This problem is rooted in design, but luckily doesn't run deep and is
> therefore solvable. That's not to say I think PGP is just fine, but if
> we're going to move beyond it and its (admittedly crummy) formats then
> we should have something else to manage identity across a broad range of
> use cases – we should have a proper replacement. Otherwise, I fear that
> information security as a field will have failed.
> 

I think I agree with most of your criticism of the critique...
And to me, I have long felt that PGP is problematic, and not always the
best to use, and should probably be replaced.
But I do not believe that the replacement has arrived yet.

And this article points out, in a lot of places, that to benefit from
security systems, you have to use them correctly. And I think I know my
way around PGP fairly well. I've used it in a few different ways for
quite some years now.
If I'm going to learn a new system, I'll mess up, a lot. And it's likely
I'll find myself the only user of this new, shiny system.

I do test a lot of new systems. But I'm not in any way ready to leave
GPG behind just yet. It's so deeply ingrained in our ecosystem that it'd
be hard to navigate without it. Whatever we replace it with doesn't just
have to be better, or more usable. It has to be used.

-- 
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/96606060-89a9-6c45-1eba-3f500667abe6%40nonbinary.me.


0x6648B5C5E394CC24.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

[qubes-users] HCL - Lenovo A485

[panina]

I had some spf record issues, so re-sending. Apologies if this shows up
double in your mailbox.
So, I decided to get Qubes on a AMD Ryzen machine. It's been
interesting. Fair warning: this is a bit of a novel.

BIOS/uefi
-

Firstly, Qubes installation disk will not start in legacy BIOS mode. I'm
not sure why, but X does not start. I'm not that interested in legacy
BIOS anyway, so I did not investigate much. I simply installed in uefi mode.

Secondly, sys-net crashes on installation. Instructions on how to get it
working follows further down.

Ryzen gpu & linux kernel < 4.17
---

Proper support for AMD Ryzen needs Linux kernel at least 4.17, so for
Qubes 4.0, that means I had to enable dom0 testing repo. With the older,
standard, kernel, the system needs to be booted with "nomodeset" kernel
parameters. This has to be done on first boot. If the system reboots,
after the first boot, without this parameter, it will not boot properly.
So, on first boot, add "nomodeset" to /boot/efi/EFI/qubes/xen.cfg, last
in the very long "kernel=..." line.

To get graphics to work (backlight, gpu etc), we need to enable the
testing repos in /etc/yum.repos.d/qubes-dom0.repo. Find the testing
post, and change the "enabled=0" to "enabled=1".
Then, we need to update and upgrade dom0. Sadly, though, sys-net doesn't
work out of the box.

sys-net
---

Enabling networking is a bit complicated, though, because AMD has rather
bad iommu support. The hardware is grouped in rather large groups, and
the network cards cannot be added to sys-net without some extra pci
hardware.

The network cards on this machine are on pci addresses 1:00:0, 3:00:0
and 4:00:0 . But with only these PCI devices, sys-net cannot boot,
because the 3:00:0 network card is grouped together with USB ports and a
few other devices. These devices cannot be split between several
machines. To get sys-net to boot, we need to edit it's Devices,  and add
everything with 3:00:x, or remove the 3:00:0 network card.
After that, networking works fine (except occasionally the WiFi hangs,
and needs to be dis- & reconnected. Probably about once a day or so).

sys-usb
---

Getting sys-usb to work (this will probably have to be on the sys-net
machine) is something I still haven't managed.
If the system is booted with the rd.qubes.hide_all_usb kernel parameter,
the graphics drivers crash, and the system cannot boot. The only way to
get a stable system is to remove that parameter, and then sys-usb
doesn't work as intended. USB devices get attached straight into dom0.
This isn't terribly acceptable to me. I'm currently using udev to
whitelist USB devices, everything not on the whitelist doesn't get
activated. This gives some protection, but it's not quite good enough.
I think if I dig into the iommu groups, or possibly blacklists some
devices like camera, I might get around this. But so far, sys-usb isn't
working.

However, if the kernel is up to date, and the hide_all_usb parameter is
removed from /boot/efi/EFI/qubes/xen.cfg, we can activate the gpu. I
removed "nomodeset" and added "iommu=1 iommu=pt". I honestly don't
remember if the iommu parts are needed or not.

AEM vs TPM2 TOTP


To my great disappointment, AEM does not work. It needs legacy BIOS
mode. Also, it might not work with this machine's rather splendid TPM2.0
from AMD. It seems it needs Intel's TXT engine, and I'm not sure this
machine could work with it.
I did, however, find an alternate solution that I'm quite happy with.
First, I use secure boot, to sign my kernel. The, once the system is
booted, I use TPM2 TOTP to verify the integrity of the BIOS & firmware.
I'd rather get this done during boot, but I haven't quite figured out
how to get dracut & plymouth to cooperate. But it's no big deal to me -
I will find out if the firmware has been compromised, just a little
later than I'd like.
This solution, however, does not need a USB devices attached to dom0. It
works with my TOTP app in my phone, which does not need to be attached.

It would be fantastic if Qubes could package tpm2-totp and tpm2-tss
(and, preferrably, tpm2-tools) in a good way. To get this to work, I had
to build the packages myself, and then copy them into dom0. I'm not
happy about this, but feel the gains outweigh the cost, security-wise.
Later versions of fedora does have these packages, so it'll sort itself
out later on.


I believe this is all of it. It's taken about a month of tinkering, but
now I have a stable system that I'm happy with. And without the random
never-ending Intel security holes...

If anyone has ideas on the sys-usb things, please do let me know. And if
anyone tries to follow in my wobbly footsteps: I've likely missed some
step somewhere. Get in touch in that case, I'll gladly help others.

<3
/panina

-- 
You received this message because you are subscribed to the Google Groups 

[qubes-users] HCL - Lenovo A485

[panina]

So, I decided to get Qubes on a AMD Ryzen machine. It's been
interesting. Fair warning: this is a bit of a novel.

BIOS/uefi
-

Firstly, Qubes installation disk will not start in legacy BIOS mode. I'm
not sure why, but X does not start. I'm not that interested in legacy
BIOS anyway, so I did not investigate much. I simply installed in uefi mode.

Secondly, sys-net crashes on installation. Instructions on how to get it
working follows further down.

Ryzen gpu & linux kernel < 4.17
---

Proper support for AMD Ryzen needs Linux kernel at least 4.17, so for
Qubes 4.0, that means I had to enable dom0 testing repo. With the older,
standard, kernel, the system needs to be booted with "nomodeset" kernel
parameters. This has to be done on first boot. If the system reboots,
after the first boot, without this parameter, it will not boot properly.
So, on first boot, add "nomodeset" to /boot/efi/EFI/qubes/xen.cfg, last
in the very long "kernel=..." line.

To get graphics to work (backlight, gpu etc), we need to enable the
testing repos in /etc/yum.repos.d/qubes-dom0.repo. Find the testing
post, and change the "enabled=0" to "enabled=1".
Then, we need to update and upgrade dom0. Sadly, though, sys-net doesn't
work out of the box.

sys-net
---

Enabling networking is a bit complicated, though, because AMD has rather
bad iommu support. The hardware is grouped in rather large groups, and
the network cards cannot be added to sys-net without some extra pci
hardware.

The network cards on this machine are on pci addresses 1:00:0, 3:00:0
and 4:00:0 . But with only these PCI devices, sys-net cannot boot,
because the 3:00:0 network card is grouped together with USB ports and a
few other devices. These devices cannot be split between several
machines. To get sys-net to boot, we need to edit it's Devices,  and add
everything with 3:00:x, or remove the 3:00:0 network card.
After that, networking works fine (except occasionally the WiFi hangs,
and needs to be dis- & reconnected. Probably about once a day or so).

sys-usb
---

Getting sys-usb to work (this will probably have to be on the sys-net
machine) is something I still haven't managed.
If the system is booted with the rd.qubes.hide_all_usb kernel parameter,
the graphics drivers crash, and the system cannot boot. The only way to
get a stable system is to remove that parameter, and then sys-usb
doesn't work as intended. USB devices get attached straight into dom0.
This isn't terribly acceptable to me. I'm currently using udev to
whitelist USB devices, everything not on the whitelist doesn't get
activated. This gives some protection, but it's not quite good enough.
I think if I dig into the iommu groups, or possibly blacklists some
devices like camera, I might get around this. But so far, sys-usb isn't
working.

However, if the kernel is up to date, and the hide_all_usb parameter is
removed from /boot/efi/EFI/qubes/xen.cfg, we can activate the gpu. I
removed "nomodeset" and added "iommu=1 iommu=pt". I honestly don't
remember if the iommu parts are needed or not.

AEM vs TPM2 TOTP


To my great disappointment, AEM does not work. It needs legacy BIOS
mode. Also, it might not work with this machine's rather splendid TPM2.0
from AMD. It seems it needs Intel's TXT engine, and I'm not sure this
machine could work with it.
I did, however, find an alternate solution that I'm quite happy with.
First, I use secure boot, to sign my kernel. The, once the system is
booted, I use TPM2 TOTP to verify the integrity of the BIOS & firmware.
I'd rather get this done during boot, but I haven't quite figured out
how to get dracut & plymouth to cooperate. But it's no big deal to me -
I will find out if the firmware has been compromised, just a little
later than I'd like.
This solution, however, does not need a USB devices attached to dom0. It
works with my TOTP app in my phone, which does not need to be attached.

It would be fantastic if Qubes could package tpm2-totp and tpm2-tss
(and, preferrably, tpm2-tools) in a good way. To get this to work, I had
to build the packages myself, and then copy them into dom0. I'm not
happy about this, but feel the gains outweigh the cost, security-wise.
Later versions of fedora does have these packages, so it'll sort itself
out later on.


I believe this is all of it. It's taken about a month of tinkering, but
now I have a stable system that I'm happy with. And without the random
never-ending Intel security holes...

If anyone has ideas on the sys-usb things, please do let me know. And if
anyone tries to follow in my wobbly footsteps: I've likely missed some
step somewhere. Get in touch in that case, I'll gladly help others.

<3
/panina

-- 
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 a

Re: [qubes-users] What is the path to the usb drive in sys-usb?

[panina]

If you are looking for the path to a storage USB:
Open a terminal in sys-usb, and run:

lsblk

This command will list all disk drives on the VM, and their path
(mountpoint). It's a generally useful linux command.
Hope it helps you!

/panina

On 7/8/19 5:14 PM, oak2...@gmail.com wrote:
> Easy question, but I'm a noob:  What is the path to the usb drive that is 
> connecting through sys-usb?  I am trying to get the usb to startup with a 
> certain vm.  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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/28ffcb8e-714d-3205-7a72-3a397546f305%40nonbinary.me.
For more options, visit https://groups.google.com/d/optout.


0x6648B5C5E394CC24.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Re: how to reinstall whonix-14 templates

[panina]

On Mon, 2019-07-08 at 22:03 -0700, Claudio Chinicz wrote:
> > On Monday, 8 July 2019 11:37:35 UTC+3, Claudio Chinicz  wrote:
>> > > Hi,
>> > >
>> > > I've broken my whonix-gw-14 when trying to upgrade to whonix-15
>> and> > ended up removing both gw and ws templates for version 14.
>> > >
>> > > I'me trying to reinstall following instructions from > >
>> https://www.qubes-os.org/doc/templates/ but it does not work.
>> > >
>> > > Anyone can help with instructions to download whonix-14 from> >
>> scratch?
>> > >
>> > > Thanks in advance,
>> > > Claudio
Not an answer to the follow-up question, but:
I recently installed whonix-15 from scratch, and did it from
instructions from whonix' webpage. They have qubes-specific
instructions, including instructions referring to upgrading from 14 to 15.
Anyway, I used the qubes salt command to install and set everything up,
`sudo qubesctl state.sls qvm.anon-whonix`. It is quiet, and takes ages,
and says nothing, and may not be aborted. This is annoying. But if it's
allowed to run uninteruppted, it'll do the job.
<3
/panina
> > 
> > Hi Chris,
> > 
> > I tried on dom0 to issue the commands and I got a message "using sys-
> > firewall as UpdateVM to download updates for Dom0; this may take
> some> time..." but nothing happened.
> > 
> > Did I do something wrong? did I miss something?
> > 
> > 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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c974b541-3618-8103-0321-1b3fd24bcfbe%40nonbinary.me.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature