Updating git submodules are not merges by default, they are a checkout,
therefore no signature verification is done, merge.VerifySignatures=true
is ignored. Unless git-submodule--helper implements a method to verify
signatures before checking out commits, it can't be relied on.
The main README is very large, by placing the documents in a separate
directory, we allow the user to choose explicitly what they read, giving
a better reading experience and allows a deeper understanding of the
project.
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.
