These environment variables inform the Vulkan loader on where to find driver files.
Since they typically point to locations on the host filesystem, any application that
attempts to load Vulkan within the flatpak sandbox would break with these set.
(cherry picked from commit b8d8d80c61)
The tests/make-test-runtime.sh scripts sets '-e' in lieu of
implementing useful error checking, but doesn't actually check
if the programs it uses exist in the first place; and aborts
silently when they're not available.
It is more useful to warn about them, and stop execution earlier.
This leaves some leftover files, but arguably that's better than
leaving leftover files AND people scratching their heads.
Warn about missing required programs.
Related: https://github.com/flatpak/flatpak/issues/5020
(cherry picked from commit 6a57fa42e4)
Use architecture instead of id in call to
flatpak_dir_load_appstream_store ().
Without this, remote-info does not show AppStream metadata.
Fixes: adb3b61f "decomposed: Return FlatpakDecomposed from flatpak_dir_find_remote_ref()"
(cherry picked from commit 02bef871c0)
There was already a timeout set using `CURLOPT_CONNECTTIMEOUT`, but that
only affects the initial connection. Once a HTTP connection is
established, the timeout is ineffective.
That means that once a HTTP connection is established, there is no bound
on the length of time a download can take. Sometimes, downloads drop to
very low speeds (for Networking Reasons) and we need a way to give up on
a download if that happens.
So, set a low speed limit of 10KB/s for 60s. If a curl download goes
more slowly than this, it will be considered timed out, and the
`CURLE_OPERATION_TIMEDOUT` code path will be taken.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: https://github.com/flatpak/flatpak/issues/5519
(cherry picked from commit d6b10c26ef)
Our only code that is conditional on the libappstream version wants
version 0.14.0, which conveniently is exactly the version that
introduced AS_CHECK_VERSION.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 556984e1c1)
By default, FUSE runs in cached I/O mode[1]. That means some I/O
responses will be taken from the page cache instead of being handled by
the FUSE process. For files opened for reading that's not a problem as
all the requests are just passed through.
However, that is problematic for files opened for writing since those
requests need to be handled by the backend. It's particularly bad for a
file opened `O_RDWR` since `read` responses from the page cache are
likely to be wrong. Instruct FUSE to use `direct-io` for those files so
that the page cache is bypassed.
1. https://docs.kernel.org/filesystems/fuse-io.htmlFixes: #5452
(cherry picked from commit c4738f8005)
As with commit 43085c0e "dir: Consistently initialize g_autofree
variables", this is currently harmless because we never actually
early-return or goto out of the region between declaration and
initialization, but some compiler versions log a warning here anyway.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit cffc3aed5b)
rest_argv_start is initialized whenever rest_argc != 0, so the previous
code was in fact safe; but this wasn't obvious to either a human reader
or the compiler, and some gcc versions warn here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 0e3e646839)
All g_autofree and g_autoptr variables should be initialized, either
with a value or NULL, and some gcc versions warn if they are not.
This particular instance was harmless, because we initialized regexp
to either NULL or a valid non-NULL value as the first statement of the
function, so there was no way to return before regexp was initialized;
but if we introduced an early-return such as a g_return_val_if_fail
before the current first statement, then that early return would have
caused uninitialized stack contents to be freed, likely resulting in a
crash.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 43085c0e2a)
The checksum here can leak if `flatpak_dir_remote_load_cached_summary()`
returns false at least once.
Spotted by asan while running gnome-software:
```
Direct leak of 2925 byte(s) in 45 object(s) allocated from:
#0 0x7f44774ba6af in __interceptor_malloc (/lib64/libasan.so.8+0xba6af)
#1 0x7f44764c941a in g_malloc ../../source/glib/glib/gmem.c:130
#2 0x7f445bc860e7 in ostree_checksum_from_bytes src/libostree/ostree-core.c:1599
#3 0x7f445bdbea82 in flatpak_dir_remote_fetch_indexed_summary /opt/gnome/source/flatpak/common/flatpak-dir.c:12563
#4 0x7f445bd9932e in flatpak_remote_state_ensure_subsummary /opt/gnome/source/flatpak/common/flatpak-dir.c:577
#5 0x7f445bdbfd42 in _flatpak_dir_get_remote_state /opt/gnome/source/flatpak/common/flatpak-dir.c:12872
#6 0x7f445bdc006c in flatpak_dir_get_remote_state_optional /opt/gnome/source/flatpak/common/flatpak-dir.c:12953
#7 0x7f445be07886 in flatpak_transaction_ensure_remote_state /opt/gnome/source/flatpak/common/flatpak-transaction.c:2057
#8 0x7f445be095c7 in flatpak_transaction_add_ref /opt/gnome/source/flatpak/common/flatpak-transaction.c:2732
#9 0x7f445be09c37 in flatpak_transaction_add_update /opt/gnome/source/flatpak/common/flatpak-transaction.c:2940
#10 0x7f445bdd202c in flatpak_installation_list_installed_refs_for_update /opt/gnome/source/flatpak/common/flatpak-installation.c:1103
#11 0x7f445bf07824 in gs_flatpak_add_updates ../../source/gnome-software/plugins/flatpak/gs-flatpak.c:2082
#12 0x7f445bf2e2b9 in gs_plugin_add_updates ../../source/gnome-software/plugins/flatpak/gs-plugin-flatpak.c:484
#13 0x7f44770533b2 in gs_plugin_loader_call_vfunc ../../source/gnome-software/lib/gs-plugin-loader.c:620
#14 0x7f447705430f in gs_plugin_loader_run_results ../../source/gnome-software/lib/gs-plugin-loader.c:748
#15 0x7f447706cb03 in gs_plugin_loader_process_thread_cb ../../source/gnome-software/lib/gs-plugin-loader.c:3110
#16 0x7f44769967ed in g_task_thread_pool_thread ../../source/glib/gio/gtask.c:1531
#17 0x7f447650e760 in g_thread_pool_thread_proxy ../../source/glib/glib/gthreadpool.c:350
#18 0x7f447650dd02 in g_thread_proxy ../../source/glib/glib/gthread.c:831
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(cherry picked from commit ce4bb3d153)
g_test_init() is meant to be called before any other use of GTest APIs,
and isolated_test_dir_global_setup() can call g_test_message(). GLib
2.76 makes this more of a practical problem.
(isolated_test_dir_global_setup() is essentially a reimplementation of
G_TEST_OPTION_ISOLATE_DIRS, since we don't depend on GLib 2.60.)
Alternative to https://github.com/flatpak/flatpak/pull/5355.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit a058d9617f)
We have too many branches and too few maintainers to be able to treat
old-stable branches as fully supported.
Helps: #5352
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 319832190f)
`ostree_raw_file_to_content_stream` will try to read it, causing a
critical warning with GLib 2.76 causing tests to fail.
(cherry picked from commit c9cbdf5179)
The TIOCLINUX ioctl is only available on Linux virtual consoles such as
/dev/tty1. It has several Linux-specific functions, one of which is a
copy/paste operation which can be used for attacks similar to TIOCSTI.
This vulnerability does not affect typical graphical terminal emulators
such as xterm, gnome-terminal and Konsole, and Flatpak is primarily
designed to be run from a Wayland or X11 graphical environment, so this
is relatively unlikely to be a practical problem.
CVE-2023-28100, GHSA-7qpw-3vjv-xrqp
Resolves: https://github.com/flatpak/flatpak/security/advisories/GHSA-7qpw-3vjv-xrqp
Signed-off-by: Simon McVittie <smcv@debian.org>
There isn't much in the way of legit reasons for this, but it's a
potential security footgun when displaying the text.
CVE-2023-28101, GHSA-h43h-fwqx-mpp8
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
Co-authored-by: Simon McVittie <smcv@collabora.com>
This prevents someone from placing special characters in order to
manipulate the appearance of the permissions list.
CVE-2023-28101, GHSA-h43h-fwqx-mpp8
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
If `no_deploy` has been set to `TRUE` in a transaction, then the
intention is that no changes will be made to the installed flatpaks.
Currently that's not the case for explicitly or implicitly added
uninstall operations. That's particularly bad for eol-rebase flatpaks
since they old version will be automatically removed without the new
version being installed. To address this, prevent uninstall operations
from being added for no deploy transactions.
Closes: #5172
(cherry picked from commit fba3a7d35e)
It's unhelpful to say something like "Key file contains line “x” which is
not a key-value pair, group, or comment" without specifying which file
we are talking about.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 3ede5382fa)
Conceptually similar to the previous commit, except it didn't crash
before, just didn't display anything.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 628750d2de)
flatpak_dir_load_deployed() can fail and return NULL. If that happens,
there is a semi-installed but broken app, and we should show a warning
rather than crashing.
Resolves: https://github.com/flatpak/flatpak/issues/5293
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 5e2e771ece)
If the `GDK_BACKEND` environment variable is present and it's value does
not match the Wayland and X11 socket configuration, then a GTK app will
fail to run since it will only consider the display backend from the
environment variable.
This should probably be extended to cover other display environment
variables such as `QT_QPA_PLATFORM` for Qt and `SDL_VIDEODRIVER` for
SDL. However, I've only tested this with GTK applications.
(cherry picked from commit cc122e2972)
Previously, --filesystem=/run would prevent apps from starting by
breaking our ability to set up /run/flatpak and /run/host. Now it is
ignored, with a diagnostic message, resolving #5205 and #5207.
Similarly, --filesystem=/symlink-to-root (or --filesystem=host) would
have prevented apps from starting if a symlink like
`/symlink-to-root -> /` or `/symlink-to-root -> .` exists, and refusing
to export the target of that symlink avoids that failure mode,
resolving #1357.
Resolves: https://github.com/flatpak/flatpak/issues/1357
Resolves: https://github.com/flatpak/flatpak/issues/5205
Resolves: https://github.com/flatpak/flatpak/issues/5207
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit f325564c9a)
If $HOME is below a reserved path (for example `/usr/home/thompson`
for Unix traditionalists) or otherwise cannot be shared, or is a
symbolic link to somewhere that cannot be shared, then we will end
up running the app with $HOME not existing. This is unexpected, so
we should make more noise about it.
There are two situations here, both of which get a warning: if we have
--filesystem=home or --filesystem=host then we are trying to share the
real $HOME with the application, and if we do not, then we are trying
to create a directory at the location of the real $HOME and replicate
the chain of symlinks (if any) leading from $HOME to that location.
Unlike the previous commit, this is not expected to happen during unit
testing, so we do not use a g_warning() for this.
Diagnoses: https://github.com/flatpak/flatpak/issues/5035
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit b85d30365e)
