2ebf672866 introduced special handling to
mark exported GNOME Shell search provider .ini files as disabled by
default. This functionality was not previously tested.
This allows you to ensure that a particular app/runtime is installed
and with the latest version in a single operation, which is useful
for instance in automatic use, like CI systems.
On some systems we can't make use of FUSE, especially on the same
locked-down systems where distribution packages are typically built.
For example, official Debian autobuilders (buildds) are configured to
disallow module loading after boot has finished as a form of security
hardening, some build chroots don't have a valid /etc/mtab, and Docker
containers give us uid 0 but not CAP_SYS_ADMIN.
These checks are taken from libostree.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2824
Approved by: matthiasclasen
When installing via the child repo we now strip the permissions early
so the import will fail instead of import and then canonicalize.
Either is ok, as nothing should be non-canonical in real life.
Closes: #2657
Approved by: alexlarsson
Currently when the user doesn't specify a branch to the run command, for
apps it will use the current branch and for runtimes it just tries to
use "master" and fails if that doesn't work. Since runtimes don't have
current branches, it would be nice if we could determine the right one
to use rather than just erroring out. So this commit changes the
implementation so that it looks at each installed runtime and if only
one matches it is used. If there's more than one match the user is
prompted to choose. This is the first interactivity added to the run
command but I don't think that's an issue; any time it's run in a
non-interactive shell it will error out upon encountering ambiguity.
Also, add a couple unit tests for the success path and error paths.
Fixes https://github.com/flatpak/flatpak/issues/2780Closes: #2788
Approved by: matthiasclasen
This commit makes it so that a unit test can create the test app and
runtime using a branch other than master, and changes test-run.sh to use
the branch "stable". This will allow the run command to be tested better
in the following commit.
Closes: #2788
Approved by: matthiasclasen
I had a report of (and old version of) flatpak stopping
an entire "flatpak update" because one app had a new required
version. This adds a test of this (and it seems fixed now).
If you run "flatpak update" then we will never update to
a commit that is older than the currently installed one. This
protects against a man-in-the-middle attack that would otherwise
let the attacker downgrade to a previously signed version that
may have some vulnerability.
This makes the ostree trivial-httpd --autoexit feature work better,
because it seems to exit whenever the root directory changes (i.e. not
only when its deleted).
This means the root dir can't be the repo (because then we can't
update the repo), or the base testdir (because we create files there
too), so instead we make the repo $testdir/repos/test and
$testdir/repos as the httpd root.
This test effectively assumed that ${test_builddir} is in /home, /opt,
a non-FHS top level directory, or some other directory that isn't
in dont_mount_in_root[] in flatpak-run.c. In a distro build where
${libexecdir} is below /usr, when running the installed-tests
so ${test_builddir} is ${libexecdir}, this assumption doesn't hold.
We can't just copy the file we're dealing with into a subdirectory
of /tmp or /var/tmp either, because those directories aren't
part of --filesystem=host. Meanwhile, we also don't want to pollute
$HOME with test detritus.
For the best possible coverage given all those constraints, we try
three directories: ${test_builddir}; ${TEST_DATA_DIR}, which is
in /var/tmp; and ~/.flatpak-tests, but only if it already exists.
When testing --[no]filesystem=host overrides, we don't even try
${TEST_DATA_DIR}, because we know it's in /var/tmp which can only
be shared explicitly, but we do try the others.
Signed-off-by: Simon McVittie <smcv@debian.org>
Distribution autobuilders are often more locked-down than the
environment in which the distribution binaries actually run.
Signed-off-by: Simon McVittie <smcv@debian.org>
