This miniminzes the soup implementation by moving it out of the
highlevel multiple-retry entry points and simplifying the
lower level part to use only one shared helper.
This will also make it easier to replace the soup specific
parts.
This copies and simplifies some helpers from soup:
* Encoding url queries
* Parsing simple http header parameter lists
The goal is to use mostly GUri and a few extra helpers for the flatpak
internals, and then pass raw string uris to the http functions which
could then be backed by any kind of http implementation.
This allows:
* getting http status
* getting www-authenticate header
* Doing HEAD instead of get
This is needed by the OCI registry code for authentication
As discussed in https://github.com/flatpak/flatpak/pull/4582 we
want ot use GUri for soup3, and if we want to use libcurl we might
as well also use it to avoid complex ifdefs, as we're linking to it
already via glib.
This imports a subset of GUri for older versions of glib.
This will be useful in gnome-software's flatpak plugin, which currently
iterates over the operations a few times, and it will be useful
internally as well.
We don't support extensions of extensions, as evidenced by add_related()
only being called once in flatpak_transaction_real_run(), so there's no
need to read the metadata file of an extension in
flatpak_dir_find_local_related(), only to find that it doesn't have any
extensions of its own.
Since we switched to libappstream we really have an implicit dependency
on this, as there are no versions of it building with glib earlier
than 2.46.
This isn't dropping a lot of old code, but at least it is more truthful
about our actual dependencies.
Of the 19 instances where g_mkdir_with_parents() is used, these are
the only ones where the return value is ignored. This triggers
Coverity.
It might not be strictly necessary to handle the errors, but doing so
can only help with debugging.
Of the 16 instances where g_file_delete() is used, these are the only
ones where the return value is ignored. This triggers Coverity.
It might not be strictly necessary to handle the errors, but doing so
can only help with debugging.
This makes it a lot easier to give guidance on using `flatpak run -d` or
`flatpak-coredumpctl`, because there's an easy way to install the
relevant refs.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
We support the "summary-arches" variable to limit which arches goes
into the compat summary file. However, its currently always adding in
the compat arches of whatever arches you list. This means we can't
e.g. keep compat summary support for aarch64, but not for armv7, which
is a problem as we're nearing the 10MB summary size limit of ostree
for old clients.
So, just keep the exact arches listed. If you want to keep compat
arches, you need to explicitly list them.
As with commit de9fe1cb "common: Work around new glib codegen
autogenerating g_autoptr support", this avoids colliding with newer
versions of gdbus-codegen generating their own autocleanups. This is
helpful when using Meson, in which the gdbus-codegen integration
generates more autocleanups by default.
Signed-off-by: Simon McVittie <smcv@collabora.com>
As discussed in #4848, this disables fuzzy matching entirely if stdin or
stdout is not a tty, meaning that something like "flatpak install
firefox" would be treated as incorrect syntax, since this syntax is
intended for interactive CLI use. Even before this commit, "flatpak
install firefox" would error out if run without a tty, since we don't
automatically choose a matching app ID even if there is only one match.
However "flatpak install -y firefox" could work before, but won't any
more. People should be specifying the full app ID in any context other
than a tty.
This commit also introduces a new env var so the unit tests can continue
to check the fuzzy matching behavior, despite them being run without a
tty.
If we're using a system copy of xdg-dbus-proxy, it's not really correct
to include a header from our subproject (which we are otherwise not
going to be compiling), and Meson is stricter about this than Autotools.
Instead, duplicate the FlatpakPolicy enum, which is the only part we
actually need.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Recent Meson versions have warnings if you add the subprojects
directory as an include path, because the way Meson wants to consume
subprojects is by the subproject's build system producing a Meson
dependency object that encapsulates its include directory. Flatpak
doesn't have a Meson build system yet, but I'm working on that.
libglnx seems to be set up to have the libglnx directory be its include
path instead: for example, ostree (by the author of libglnx) already
uses "libglnx.h" or <libglnx.h> everywhere. Do the same here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Currently, when using the sideloading support for offline updates, there
are two types of directories that are interesting: an ostree repo
directory on a directory that was passed to `flatpak create-usb`. By
default the latter has a repo at the subpath ".ostree/repo", and if a
custom destination was specified with "--destination-repo", a symlink is
created pointing to it in ".ostree/repos.d".
Currently Flatpak supports either repos or create-usb dirs in the
`sideload-repos` directory in either the Flatpak installation or
`/run/flatpak` (see flatpak(1)), but only supports repo directories
being passed to "--sideload-repo" for the install and update commands.
This is pretty confusing and actually made me think the sideload support
was broken because I forgot about this limitation. So change things so
we can accept either type of directory specified either way: via option
or via the "sideload-repos" directories.
I've tested all of the following cases:
- pointing to a repo with --sideload-repo
- pointing to a create-usb dir with --sideload-repo
- linking to a repo in ~/.local/share/flatpak/sideload-repos
- linking to a create-usb dir in ~/.local/share/flatpak/sideload-repos
- pulling from a sideload repo when online as a performance improvement
The subpath is resolved relative to the root of the commit, so we can
use either an absolute or a relative path interchangeably. When using
libostree < 2021.6 with GLib >= 2.71, absolute paths cause an assertion
failure here; that was a libostree bug and was fixed in 2021.6, but we
can interoperate with more versions by sticking to relative paths, and
there's no real reason to prefer absolute.
Resolves: https://github.com/flatpak/flatpak/issues/4805
Co-authored-by: Corentin Noël <corentin.noel@collabora.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
All the details of the bug are in:
https://github.com/ostreedev/ostree/pull/2549https://github.com/flatpak/flatpak/issues/3479
This patch works around it by marking the commit we're about to pull
partial, so that if the .commit object exists in a staging directory
from a previous failed pull, it will not be erroneously considered a
complete commit, even by affected versions of libostree that don't have
the above patch. If for some reason the commit in the staging dir is
complete, libostree should harmlessly verify that and pull it in.
Usually the commit we are pulling does not already exist in the local
repo, but add a check anyway so we don't risk marking a complete commit
as partial, and so this works on the code path from
"flatpak install --reinstall ..."
Fixes#3479
Just as we already call flatpak_disable_fancy_output() in
flatpak_option_context_parse() in case verbose output is enabled via CLI
options, disable fancy output in case verbose output was enabled via the
G_MESSAGES_DEBUG env var. Without this change, the result of doing e.g.
$ G_MESSAGES_DEBUG=OSTree flatpak install ...
is pretty useless and ugly, when the output isn't being redirected to a
file, since the debug messages are overwritten when we redraw to show
progress updates.
This makes the output of "flatpak list" a bit ugly when G_MESSAGES_DEBUG
is set, but it seems like a small price to pay.
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)
Older versions of bubblewrap would create a --file with mode 0666
(world-writeable), which is unexpected. Since bubblewrap 0.5.0, the
default is still 0666 for backwards-compatibility, but we can change it
with the new --perms argument. Switch to mode 0600 (private to user)
which is consistent with the mode of the --ro-bind-data version of
that file.
This is not a security issue: from outside the sandbox, this file can
only be accessed via /proc/$pid/root, which the kernel restricts to be
accessed by processes that could trace the sandboxed process (the same
uid or a privileged process), leading to a practical effect similar to
0600 permissions. Inside the sandbox, all processes have the same uid,
so 0600 and 0666 permissions are equivalent.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In older versions of bubblewrap, the --dir argument could only create
directories with mode 0755 (world-readable). The default mode is
still 0755, but since bubblewrap 0.5.0, we can change this to the mode
recommended by the basedirs spec (0700, private to user).
Since version 1.11.1, the --dir used here is normally redundant, because
each app-ID gets its own XDG_RUNTIME_DIR imported from the host
(it's actually $XDG_RUNTIME_DIR/.flatpak/$FLATPAK_ID/xdg-run on the host)
and those are correctly created with mode 0700. The one case where this
change makes a difference is that a sub-sandbox, created by
flatpak-spawn --sandbox or equivalent, does not share the common
XDG_RUNTIME_DIR and instead received an XDG_RUNTIME_DIR private to that
instance, with its permissions coming from this --dir argument.
This is not a security issue, because processes outside the sandbox can
only access this directory via /proc/$pid/root, which is only accessible
by processes that would be allowed to trace the sandboxed process
(either the same uid or a privileged process), resulting in behaviour
similar to the canonical 0700 mode. Inside the sandbox, all processes
have the same uid, so 0700, 0755 and even 0777 permissions would be
essentially equivalent.
However, some libraries that interact with XDG_RUNTIME_DIR, most notably
Qt, verify that its mode is 0700 as a hardening mechanism, and these
libraries did not work inside a Flatpak sandbox without being patched
to be more permissive.
Resolves: https://github.com/flatpak/flatpak/issues/3397
Signed-off-by: Simon McVittie <smcv@collabora.com>
libostree makes heavy use of fd-based I/O, which has the disadvantage
that it is rarely obvious what path an error message is referring to.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we are running a CLI command in the background, then EnsureRepo
might require authorization. Silently skip it if allow_empty was true,
as it is for commands that iterate through all repositories.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, if /var/lib/flatpak didn't exist then we would use the
system helper to create and populate it, but if it existed and was empty,
we could only populate it if we had privileges. This led to errors from
libostree:
Creating repo: mkdirat: Permission denied
The EnsureRepo method call is allowed by default for active local users,
so do this even if allow_empty is true: this will incorporate
/etc/flatpak/remotes.d into the repository, whether it is newly-created
or not. This makes a `flatpak search` work immediately, without having
to fetch metadata explicitly.
Signed-off-by: Simon McVittie <smcv@collabora.com>
