libappstream-glib is mostly unmaintained, and libappstream is more
actively developed (and up to date with the AppStream specification).
Port from libappstream-glib to libappstream. Handily, a lot of the APIs
are exactly the same. The main changes are:
* `AsApp` → `AsComponent`
* `AsStore` → `AsMetadata`
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(Mostly done by Philip, then Phaedrus finished this)
which(1) is neither standardized by POSIX nor built-in to bash, and has
different implementations and behaviour on different distributions.
command -v is standardized by POSIX, but it won't return the path to an
executable if the same command is available as a shell builtin, so it
isn't necessarily suitable here either.
The Flatpak test suite uses bash scripts rather than POSIX shell scripts,
so we can safely make use of bash-specific options for builtins, and
in particular type -P, which has the semantics we want here: search PATH,
even if there is a shell builtin of the same name.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This reintroduces the special case that existed in Flatpak 1.12.3, but
under a different name, so that it will be backwards-compatible. With
this change, flatpak-builder will be able to resolve CVE-2022-21682 by
using --filesystem=host:reset.
We want to implement this as a suffix rather than as a new keyword,
because unknown suffixes are ignored with a warning, rather than causing
a fatal error. This means that the new version of flatpak-builder will
be able to run against older versions of flatpak: it will still be
vulnerable to CVE-2022-21682 in that situation, but at least it will run.
Co-authored-by: Alexander Larsson <alexl@redhat.com>
We weren't distinguishing here between overrides that should have been
negated (xdg-documents) and overrides that should not have been negated
(everything else).
Signed-off-by: Simon McVittie <smcv@collabora.com>
This tests for invalid metadata, missing xa.metadata and mismatched
values in xa.metadata and the real metadata, including the embedded
null leading to the hidden permissions of CVE-2021-43860.
The history test fails sometimes in the CI due to the remote add
operation being missing from the history command's output:
+ diff history-log -
0a1
> add remote system (history-installation) test-repo
Presumably this is due to that operation happening in the same second
that is passed to --since, so move the sleep statement to make sure a
second passes before we do anything.
Maybe it's a bit pedantic but we shouldn't be matching
"org.test.Hello.Plugin.fun" when we're trying to match "org.test.Hello",
so add some trailing slashes to prevent that, and change the options on
a few commands so we're only parsing the columns we care about.
This fixes a few issues with the unit test logs that make them ugly:
1. Currently some lines of output from a command will appear after the
line from xtrace which has the next command, since the command was
printing to stdout and xtrace uses stderr. E.g. "Installation complete."
will appear after "+ flatpak --user install -y ..." but it is from the
previous install command.
2. Lines of output have many spaces after them to pad them to the table
width but this is not needed for non-fancy output.
3. Lines of output are mixed with output from httpd since they don't end
with a newline character, e.g. "Installing… ▊
4%127.0.0.1 - - [16/Nov/2021 00:18:24] "GET /..."
On two different code paths we were using the "Title" field in
flatpakref files as the title of a remote, which is incorrect. In most
cases, the remote added via the RuntimeRepo key will be the same as the
remote the app is from, so when the remote is added for the runtime, its
title will be correctly set using the Title value from the flatpakrepo
file and the app will therefore have an origin remote with a title set.
This is not currently true for flatpakref files that use
SuggestRemoteName=, see https://github.com/flatpak/flatpak/pull/4513
For flatpakref files that use a different remote than the RuntimeRepo,
we don't currently have a way for the title to be set automatically;
perhaps we should (https://github.com/flatpak/flatpak/issues/4512).
Fixes https://github.com/flatpak/flatpak/issues/4499
Many of the fields allowed in flatpakrepo files are not allowed in
flatpakref files, e.g. Comment, Description, Homepage, etc. So there is
no straightforward way to ensure those are set correctly when the user
installs something with a flatpakref file. However in most cases the
repo specified by the RuntimeRepo key is also the repo providing the
main ref, so in those cases it makes sense to utilize all the metadata
provided in the flatpakrepo file when creating a remote to provide
updates for the app being installed. We were already doing this when the
SuggestRemoteName key was unset; this commit makes it so that we utilize
that metadata also when SuggestRemoteName is present.
It can happen that a related ref is installed from a different remote
than the thing it's related to. We always want to update things from
their origin remote. However as of now FlatpakTransaction resolves the
commit of a related ref to the one available from the main ref origin,
and later sets the remote for the operation to the installed origin (see
commit 6793d90b8). In case there is a newer commit in the main ref
origin than the installed origin, this leads to an update operation
being erroneously created, only to then error out with an HTTP 404
error, because the commit from the main ref origin is being pulled from
the installed ref origin. For specific steps to reproduce see
https://github.com/flatpak/flatpak/issues/3128#issuecomment-948948040
So, ensure that when a FLATPAK_TRANSACTION_OPERATION_INSTALL_OR_UPDATE
operation is created for something that's installed, whether it's a
related ref or something else, the remote used is always the origin. And
ensure that the remote is set correctly before the stage where the op is
resolved to a commit, to avoid the situation described above. This is
essentially a re-implementation of the fix in commit 6793d90b8.
Also, add a unit test for this behavior.
This commit also makes a few changes to documentation to make it clear
that this related-ref-different-origin situation is possible.
Fixes#3128
This gives new support for the new XDG_STATE_HOME addition to XDG_BASE_DIRS
which allows applications to use this without breaking because they would
assume $HOME/.local/state which may be unavailable to the flatpak
This adds it as .local/state as to make --persist=.local/state the same behaviour
as in new flatpak. This in turn means that the transition should be seamless between
old and new flatpak.
This also has the benefit of working if the application doesn't follow XDG spec thanks
to --persist=.local/state.
This fixes https://github.com/flatpak/flatpak/issues/4477
[smcv: Don't call nonexistent g_get_user_state_dir(); fix a reference
to XDG_STATE_DIR]
In particular, this checks that CVE-2017-5226, CVE-2019-10063 and
CVE-2021-41133 are still prevented.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This exercises various syscalls. It's heavily based on the one from
<https://github.com/containers/bubblewrap/pull/459>, but with the
addition of a mode to output the numeric values of various expected
errno codes, which are not otherwise available to shell scripts.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In a recent commit I changed flatpak_dir_list_remote_refs() to make main
refs (xa.main-ref) visible for noenumerate remotes (xa.noenumerate),
meaning that an origin remote created for a flatpakref file can be used
to get information about the ref from the file even before it is
installed. This commit extends that work to include extensions of the
main ref, and updates the unit test to check for this. The reasoning is
that if GNOME Software wants to show the user information about, say,
VLC from a flatpakref file before installing it, Software would want to
also show the available plugins so the user can decide if they want to
install those as well. I haven't checked if Software actually does that;
I'm only focusing on making libflatpak do the right thing.
Currently the xa.noenumerate option on a remote is documented as causing
the remote not to be used when presenting available apps/runtimes or
when searching for dependencies. The idea is that the remote is only
used for providing updates for things installed from it, and this
functionality is used when creating an origin remote for something
installed via a flatpakref file.
However, the implementation of this in flatpak_dir_list_remote_refs() is
buggy. It returns an empty set of refs even if something is both locally
installed and available from the remote. This is because it is using
hash table comparisons of FlatpkDecomposed objects (via
flatpak_decomposed_hash()) which take into account both the ref (or
refspec) and the collection ID, and the local refs' FlatpakDecomposed
objects are created from a refspec whereas the remote refs'
FlatpakDecomposed objects are created from a ref alone. We could fix
this by having them both use refspecs, but it is better to use a
collection-ref tuple for the following reasons:
(1) Changing flatpak_dir_list_all_remote_refs() to use a refspec to
create the FlatpakDecomposed objects would be a breaking change for the
other users of that function.
(2) Both the local and remote refs are from the same remote so we don't
need to use the remote name to disambiguate them, even if no collection
ID is configured.
(3) The whole point of collection IDs is to make refs uniquely
identifiable, so we're using them for the intended purpose.
In addition to fixing this bug, this commit adds a unit test in
testlibrary.c so it stays fixed.
When we create origin remotes for apps installed via .flatpakref files,
we set xa.noenumerate=true and
xa.main-ref=app/com.example.App/arch/branch so that the remote is only
used for the app it was intended for. This is implemented in
flatpak_dir_list_remote_refs() by only listing refs in the remote which
are already installed. This works fine after the ref is installed but in
the short timespan between when the origin remote is created and the app
is installed from it, it means that the remote appears as empty.
The use case where I ran into this is in attempting to use
flatpak_installation_fetch_remote_ref_sync() in the gnome-software
flatpak plugin, in the handling of flatpakref files, which is intended
to just display information to the user and let them decide whether to
install the app. But I was not able to create a FlatpakRemoteRef due to
the behavior described above; see #4453 for more details.
So, change the behavior so that the main ref for an origin remote is
visible even before it is installed. This technically could be a
breaking change for some consumer of libflatpak but that seems very
unlikely, and the new behavior makes more sense.
Also add a unit test for this behavior.
Currently the output produced when assert_remote_in_installation() or
assert_remote_not_in_installation() fails is not helpful: it doesn't
mention the remote name or where the assertion was called from. Fix
those problems by rewriting it as a #define.
Files that are generated manually by a maintainer and committed to git
should be in the srcdir, not the builddir.
Signed-off-by: Simon McVittie <smcv@collabora.com>
a99b748931 introduced an environment variable for changing the flatpak path for exports.
On NixOS, we do not have a stable path we could use so we used to patch Flatpak to use `flatpak` program from `PATH`.
With the recent change, we drop our downstream patch in favour of setting the environment variable to `flatpak` but the tests do not expect that.
This is the test part of our former downstream patch so that tests can pass with exports using `flatpak` instead of an absolute path.
It still expects the binary path to end with `flatpak` so arbitrary `$FLATPAK_BINARY` will not work but we do not pass the environment variable to tests so we cannot do much better.
g_key_file_get_boolean() only accepts lower case "true" and "false", so
correct some instances of "False" in key files. This makes no functional
difference as long as the error pointer isn't checked since
g_key_file_get_boolean() also returns false when it can't parse the
value as a boolean. But it still seems good to be correct, and someone
could interpret the existence of "IsRuntime=False" as implying that
"IsRuntime=True" will work, which it doesn't.
