Depending on OEM will conflict the state IDs because they are the name
of the qubes being created. As not much changes are needed and we
customize much more, stop depending on upstream.
The client should install the agent client packages and not the
opposite. The way it was, it would not be possible to include the agent
client packages to the ssh client, as it would create a recursive loop.
The mixer provided by the program volumeicon is okay, it shows only one
input and one output. Pavucontrol correctly detects the different inputs
and output of each audio client, you can have deeper control of the
client volume.
As it is not easy to get files to dom0 and we don't want to reimplement
a package manager, crude Git is the solution as of know.
With Git we have the following advantages: native fetch format for
source controlled files, cleaner command-line, automatic signature
verification during merge, the disadvantage is that it is not included
by default in Dom0 and filtering it's stdout chars are not possible.
Note that the remote can report messages to the client via stderr, which
is filtered already, and if it tries to send an escape sequence to
stdout, the operation will fail with 'bad line length character: CHAR'
printed to stderr on the client, unfiltered by qrexec, but filtered to
some extent by the git client. If it is an escape character, the char is
transformed to "?", but UTF-8 multibyte characters are not filtered. Up
to 4 bytes can be displayed.
Tar on the other hand is already installed, but it is much ancient and
it's file parsing caused CVEs in the past relatively more drastic than
Git, it also doesn't only include committed files, it can include any
file that is present in the directory, which by far, increases a lot of
the attack surface unless you reset the state to HEAD, clean .git
directory manually and there are possibly other avenues of attack.
If persistent rules are chosen, it can deal with disposable sys-net, but
not with disposable sys-firewall, as the qube ip will change, the rule
won't work. Applying the rule to the disposable template is a "try it
all", but it's usage is discouraged.
The removal was first implemented to get a clean state of the qube, but
there are side effects, it fails if the user created a named disposable
based on the dvm and also removes the (dvm) entry from the appmenu.
The sys-usb case is a workaround in case the user selected a
non-disposable, an appvm sys-usb during system installation.
- Passwordless as it doesn't compromise security;
- Firewall blocks access to the interface in case the pihole is exposed
to the internet;
- setupVars.conf needs to be 644 for non root commands to the pihole
script to work, so the WEB_PASSWORD can be read as normal user,
restricting root on pihole does not make sense, as it can modify the
network setting via pihole web interface.
- Default sys-net and sys-firewall to disposable;
- Set global and per vm preferences by starting the qubes or shutting
down them when necessary; and
- Less manual steps remaining for the user: just rename the net qube, as
it can only be done via Qubes Manager.
