Ideally, it would be a Qrexec socket service, but it doesn't handle DNS,
only accepting IPs. The dev qube is now non-networked and network,
especially to remote git repositories can be acquired via the proxy that
is going to be installed in every netvm.
The wget package can be downloaded from the command-line, but as Salt
does not follow DNF package redirects, the package is installed but the
state fails as Salt cannot find a package with the same name installed.
Passing files to Dom0 is always dangerous:
- Passing a git repository is dangerous as it can have ignored modified
files and signature verification will pass.
- Passing an archive is troublesome for updates.
- Passing an RPM package depends on the RPM verification to be correct,
some times it is not.
- Passing a RPM repository definition is less troublesome for the user,
as it is a small file to verify the contents and update mechanism is
via the package manager. Trust in RPM verification is still required.
Many improvements were made to the build scripts:
- requires-program: Single function to check if program is installed;
- spec-get: Sort project names for the usage message;
- spec-get: Only running commands that are necessary;
- spec-get: Fix empty summary when readme has copyright header;
- spec-gen: Fix grep warning of escaped symbol;
- spec-build: Sign RPM and verify signature;
- spec-build: Only lint the first SPEC for faster runtime;
- yumrepo-gen: Generate a local yum repository with signed metadata;
- qubesbuilder-gen: Generate a .qubesbuilder based on tracked projects;
- release: Build, sign and push all RPMs to repository.
Goal is to be able to build with qubes-builderv2 Qubes Executor.
For: https://github.com/ben-grande/qusal/issues/37
Only deb and rpm where cached and only if used from the Qubes website
and made to individual directories. Now every package from every package
manager Qubes supports will be cached.
Update according to upstream.
If user just installed Qubes, the full templates can have updates
available. If user restored backups of templates and standalones, they
could also have updates available. Available updates can contain fixes
that if not applied, can make the states fail, such as a buggy salt
package and Qrexec service that can make a state fail in case the
full outdated templates and standalones are responsible for the
functionality specially of management_dispvm, updatevm, default_netvm
and qubes.UpdatesProxy service.
- Enforce uninstall in Fedora, it has been too problematic due to zchunk
checksum mismatch errors;
- Skip tagging and installing on unsupported qubes, before it tagged
every template that did not have the tag 'whonix-updatevm', this is
error prone as it would fail the installation on unsupported clients
such as Gentoo, Mirage.
Fixes: https://github.com/ben-grande/qusal/issues/54
Ability to read the program's manual from the terminal is much better
than to ask the user to search the manual page on the internet, we
already trust the installed program and documentation, but we should not
trust every manual page on the internet.
- Maim causes no errors and has region and window capabilities;
- Scrot region capture puts some weird borders when dragging the mouse;
- Spectacle allows editing but is too feature rich (complicated); and
- Xfce4-screenshooter does not allow selecting both region and window.
Fixes: https://github.com/ben-grande/qusal/issues/51
It is not possible to troubleshoot network module loading without
pciutils. Although it is a troubleshooting tools, it is not
troubleshooting the network, but to make the system itself be able to
load kernel modules and reach the network, therefore necessary.
Qubes that have the updates-proxy-service enabled will have the
repository definitions set to work with the proxy, being it a TemplateVM
or another type of qube. Qubes that have that same service disabled and
are based on templates that are being cached, will have the repository
definitions corrected for it to work like normal systems via the
networking instead of caching proxy.
Optimizations were done for a faster runtime, previously it would call
sed 38 times on Fedora-39, now it only calls sed 2 times for Fedora
repositories (one extra for rpmfusion) and some more for PackageKit and
dnf.conf markers. Inexpensive runtime is a must for a script that may
run multiple times, such as when being called by a tool monitoring the
filesystem such as inotify.
Code from /usr/lib/qubes/update-proxy-configs was used for the NetVM use
case of the cacher, thus the license had to be changed.
For: https://github.com/ben-grande/qusal/issues/44
Fixes: https://github.com/ben-grande/qusal/issues/31
Very useful for template based qubes to uninstall the cacher definition
to reach remote repository definitions with direct connection.
https://github.com/ben-grande/qusal/issues/31
Updates happens multiple times, normally 2 to 3, even if we consider a
state without includes. On states with multiple includes, it could
easily get approximately 10 updates being ran. This behavior leads to
unnecessary network bandwidth being spent and more time to run the
installation state. When the connection is slow and not using the
cacher, such as torified connections on Whonix, the installation can
occurs much faster.
Adding external repositories has to be done prior to update to ensure it
is also fetched.
Fixes: https://github.com/ben-grande/qusal/issues/29
Provided in the default Dom0 installation as it brings a much better
usability and small packages.
KDE ships with kdialog but without a screenshot utility.
Xfce ships with xfce4-screenshooter but without a dialog utility.
Scrot and Zenity are minimal tools that works on both DEs and are very
small packages.
Fixes: https://github.com/ben-grande/qusal/issues/22
Git revision is specified in the git module to Salt not fail trying to
verify it is in HEAD when it is in a tag from a previous installation.
Fixes: https://github.com/ben-grande/qusal/issues/27
Comparison to upstream:
- POSIX compliant;
- Add more dialog tools: kdialog;
- Add more screenshot tools: spectacle, xfce4-screenshooter;
- Change work "Nautilus" to "File Manager";
- Fix all shellcheck messages;
- Fix wording of confusing options seen by the user;
- Fix variable names without meaning;
- Remove commented/unused code;
- Remove extraneous messages sent to the user;
- Remove Imgur support; and
- Remove ImageMagic, use tools that support editing: spectacle.
Fixes: https://github.com/ben-grande/qusal/issues/22
A Minimal Fedora template can't be the management qube or the targeted
qube of Salt as it is missing dependencies that are only available in
the full template. The management qube is temporarily changed to the
non-minimal version so the minimal template can be targeted once and
then it takes over the management disposable template.
Fixes: https://github.com/ben-grande/qusal/issues/28
- End qrexec policy with deny rules;
- Move the USB setup from sys-audio to sys-usb; and
- Document the pros and cons of the different types of USB devices
assignment to client qubes or to the server.
The target of qubes.ConnectTCP has 'socat' because it is a dependency of
qubes-core-agent-networking. In case the target has not networking
packages, this needs to be taken care by the formula that creates the
target, not from the client itself.
Split-mail allows to separate the receving, reading/composing and
sending of mails to separate qubes, while having the reading/composing
qube offline and a manual step necessary to authorize mails to be sent
form the sender qube.
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.
