https://forums.whonix.org/t/focus-on-whonix-core-development/5036

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

Does this work in https://forums.whonix.org/t/whonix-virtualbox-15-0-0-3-3-debian-buster-based-testers-wanted/7604? @HulaHoop

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?

In T869#18656, @madaidan wrote:

Xpra is only used for GUI isolation.

The problem is, xpra (actually xpra | xserver-xephyr | xvfb) isn't in the list of Recommends: of the firejail package by accident. We don't really know the rationale of that. Could be an optional dependency and without it, some things someone who knows firejail who is happy to find it installed would wonder why it actually does not work.

runit-sysv is incompatible with Whonix and Qubes Debian template. Even sudo apt install runit-sysv --no-install-recommends would uninstall some Whonix or Qubes packages.

git-all also breaks Qubes Debian buster template. @marmarek

Another workaround with full git-all functionality that does not break Whonix:

Another workaround:

Workaround:
While this should be fixed, note, meanwhile the following works perfectly well for general use of git (I did not ever had any situation where I was missing any features):

Does it work after you comment ProtectSystem=strict and ReadWriteDirectories=? I think on Qubes-Whonix it is trying to write to a directory in /var/run (probably /var/run/qubes-service). I can't test as I don't use Qubes.

Unfortunately not. On Qubes-Whonix. Could be Non-Qubes-Whonix vs
Qubes-Whonix?

Does it work using this? It looks like it needs the openat syscall which it now allows.

How have you created sys-whonix? Default applications list is copied from template only at VM creation time. If you modify it (using VM settings for example), or just switch template, it isn't re-copied from template (it would break user's changes).

sudo journalctl -f in dom0 does not show anything when running qvm-sync-appmenus whonix-gw-15 in dom0.

QVMM applications tab looks good btw. Just the default applications listed in Qubes start menu (without ever using QVMM applications tab) is not properly populated.

Does not work yet. @madaidan

https://forums.whonix.org/t/splitting-whonix-documentation-into-a-short-and-long-edition-for-better-usability/1861/53?u=patrick

https://github.com/Whonix/tb-updater/commit/36561b7f8b54605ea33f4842930f2cdabcd17365

It works for me (checked with qubes-template-whonix-gw-15-4.0.1-201906201340).

I cannot reproduce. I've installed qubes-template-whonix-15-4.0.1-201905241112, updated it with qubes testing repository enabled and I see all the actions available in thunar.
But I do see some warnings on thunar's stderr, like this:

(Thunar:27375): Gtk-WARNING **: 01:41:41.317: Refusing to add non-unique action 'uca-action-1507455450991127-4' to action group 'ThunarActions'

Looks like actions are added multiple times to /etc/xdg/Thunar/uca.xml, which is later copied to /home/user/.cnfig/Thunar/uca.xml. Relevant code in https://github.com/QubesOS/qubes-core-agent-linux/blob/master/debian/qubes-core-agent-thunar.postinst

I don't think anything Debian does would modify any iptables rules nor Whonix ships any code to disable the firewall. So "disables the firewall for a minute" is non-existing. Would be bad if that happened.

sys-whonix shows sdwdate-gui.desktop by default but not

Any idea why these are missing? @marmarek

anon-whonix / sys-whonix lacks a lot entries.

• Copy to VM
• Move to VM
• Create Archive...

The problem is, xpra (actually xpra | xserver-xephyr | xvfb) isn't in the list of Recommends: of the firejail package by accident. We don't really know the rationale of that. Could be an optional dependency and without it, some things someone who knows firejail who is happy to find it installed would wonder why it actually does not work.

In T875#18470, @madaidan wrote:

Seems quite hacky. What's the root cause for failing?

Probably, when the package is getting updated, it disables the firewall for a minute so it can apply the updates and the fail closed mechanism kicks in.