qvm-run-vm cannot make a separate qubes.WaitForSession call for a
DispVM. Instead, pass the new WaitForSession argument to qubes.VMShell,
which will do the equivalent.
GNOME automatically set scaling factor to 2 when HiDPI is detected.
Unfortunately it does it also on not really HiDPI displays, making the
whole UI unusably large. There is no middle ground - scaling factor must
be integer, so 1.5 is not supported. Lets opt on a conservative side and
fallback to scaling factor 1.
Solution by @alyssais, thanks!
FixesQubesOS/qubes-issues#3108
When one use scaling set by gnome tools (gsettings or
gnome-tweak-tool), gsd-xsettings must be running to apply the change
also to other applications.
This include auto scaling on HiDPI screens.
This commit fixes non-uniform behaviour on different VM types.
QubesOS/qubes-issues#3108
There was a bug that interpreted '-' as file type. But convert don't
know how to handle '-' file type, so refused to proceed.
FixesQubesOS/qubes-issues#3085
If fork server is used, proper environment is inherited from the
session. But in other case (like non-default user), it needs to be
created by qrexec-agent itself. PAM provide some variables, but not the
most basic: HOME, SHELL, USER, LOGNAME. Also process should be started
in user home directory (if available).
FixesQubesOS/qubes-issues#3416
I have been using this with a dbus-less Gentoo template since the original
change, and have tested recently on whonix-gw with dbus enabled and running.
(cherry picked from commit bf69335074b45157734b881cc14d54ea43e7902a)
It is more robust, especially handle "# Units below this line will be
re-preset on package upgrade" part of 75-qubes-vm.preset file. This is
needed to fix system configuration without the need to rebuild the whole
template.
QubesOS/qubes-issues#2913
* qubesos/pr/72:
Fix UCA mistake and qvm-actions script
Fix ShellCheck comments
Add debian package support
Disable Thunar thumbnails
Add support for Thunar Qubes VM tools
Chain name in IPv6 cannot be longer than 29 chars, so strip IPv6 prefix
from it.
ICMP on IPv6 is a different protocol than on IPv4 - handle iptables rule
accordingly.
QubesOS/qubes-issues#718
If IPv6 is configured in the VM, and it is providing network to others,
apply IPv6 firewall similar to the IPv4 one (including NAT for outgoing
traffix), instead of blocking everything. Also, enable IP forwarding for
IPv6 in such a case.
FixesQubesOS/qubes-issues#718
If dom0 expose IPv6 address settings, configure it on the interface.
Both backend and frontend side. If no IPv6 configuration is provided,
block IPv6 as it was before.
FixesQubesOS/qubes-issues#718
* qubesos/pr/67:
archlinux fix .service added twice in networking install script
Makefile: install-netvm shouldn't be a dependency of itself.
archlinux: add recently splitted packages as optional dependencies of qubes-vm-core
archlinux: fix incorrect keyring being populated
Makefile: remove invalid reference to network dropins install target
archlinux: fix shellcheck issues
archlinux: create a keyring package to install binary repository automatically
Makefile: add network install targets to install-deb
Makefile: fix typo created when spliting the install targets
Makefile: add basic networking to the new install-corevm target
archlinux: split core-agent from netvm-agent
Makefile: ensure that everything is installed by default for rh based agents
Makefile: split network install target from core agent install target
Start qubes-firewall (which will add "DROP by default" rule) before
enabling IP forwarding, to not leave a time slot where some connection
could go around configured firewall.
QubesOS/qubes-issues#3269
In some cases it may make sense to enfoce outgoing firewall also on
sys-net. If the service is disabled, firewall settings will be
(silently) ignored, so better be on the safe side and enable.
QubesOS/qubes-issues#3290
When qubes-firewall service is started, modify firewall to have "DROP"
policy, so if something goes wrong, no data got leaked.
But keep default action "ACCEPT" in case of legitimate service stop, or
not starting it at all - because one may choose to not use this service
at all.
Achieve this by adding "DROP" rule at the end of QBS-FIREWALL chain and
keep it there while qubes-firewall service is running.
FixesQubesOS/qubes-issues#3269
