In T913#18744, @Patrick wrote:

Do you see any issues with "create home directory on first login" in Qubes?

In T913#18743, @marmarek wrote:

Can you give some more context here?

Can you give some more context here? Is it the problem that user is created too early (before /etc/skel is fully populated)? Or is it a problem that it's created at all? Should there be a difference between Qubes and non-Qubes case?

Removed a few. Would not start without openat, so kept.

Yay, we have ProtectSystem=strict now.

Yay, we have ProtectSystem=strict now.

Can we exclude ExecStartPre=/usr/lib/onion-grater-merger from systemd hardening?

Error back after reboot.

https://github.com/Whonix/onion-grater/blob/master/lib/systemd/system/onion-grater.service currently works without ReadWritePaths. So let's not add?

It was copied from native setup_ip script, details here:
https://github.com/qubesos/qubes-core-agent-linux/commit/5cbb38a2
https://github.com/qubesos/qubes-issues/issues/700
It definitely was relevant for old stubdomain hosting qemu (which is still possible to use in R4.0). Not sure if applies to new linux-based stubdomain.
It may be not needed anymore. To verify that, try removing those lines and check networking in Windows (or other OS without Xen PV drivers).

https://github.com/Whonix/onion-grater/blob/master/lib/systemd/system/onion-grater.service currently works without ReadWritePaths. So let's not add?

Any update?

Dead upstream.

Any idea? @marmarek

There is none indeed for VMs but it has to be re-checked once/if Whonix-Host becomes a thing.

Dead upstream.

It's a file, not a folder.

https://github.com/Whonix/onion-grater/commit/8480cff304ea019b25dc49d91672e7c3f8599a07

It's a file, not a folder. Nothing in the code of
/usr/lib/onion-grater-merger writes to /usr/lib/onion-grater-merger.

I just re-read the error message. Try adding

I can test it but I doubt lockdown will help at all.

That's weird. Onion-grater is trying to write to somewhere that's being mounted read-only by systemd.

Could you test this please by installing in VM and/or host please? @madaidan

Merged your changes.

In T324#18696, @Patrick wrote:

What is a good way to detect that users are using VM kernel in Qubes? @marmarek If uname -r outputs 4.19.43-1.pvops.qubes.x86_64 i.e. matches *pvops* it means that no VM kernel is being used?

needrestart works good enough for it to be implemented as a test in whonixcheck (--verbose?).

Blocked by Qubes.
Qubes start menu incompatible with DispVMs launching GUI applications into the background
https://github.com/QubesOS/qubes-issues/issues/5129

I see.
BTW it's certainly about fonts. here you can select whonix_firstrun-whonix-14-firstrun-20180915 from the dropdown above the screenshot (click eye icon at the right) and slide vertical bar to see old and new version.

marmarek (Marek Marczykowski-Górecki):

Is there a reason for fixed geometry of those widgets, instead of letting Qt figure it out based on the content?

Maybe different fonts installed? Is there a reason for fixed geometry of those widgets, instead of letting Qt figure it out based on the content? I suppose there may be more problems like this in the future. Especially if proper HiDPI support will come into play...

I have no idea why this started happening without changes. Perhaps due to underlying libraries changes. Anyhow, fixed in git master.

Work for me too in new build https://forums.whonix.org/t/qubes-whonix-15-templatevms-debian-buster-based-4-0-1-201906232114-testers-wanted/7601

Implementation looks good enough for now.

Will keep watching what Tails is doing.

Seems ok after full removal and re-creation.

https://github.com/Whonix/tb-starter/commit/11ed26d14ed308891db5fc366a1002da41bdd3c1

GUI isolation is very important, no?