gitlab.gnome.org is currently down, so use a mirror.
The specific commit we are using has not changed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit bdfebb44da)
gitlab.gnome.org is currently down, so use a mirror.
The specific commit we are using has not changed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 7cb9eb3ebc)
The project was moved to a new namespace a while ago, and is now using
the main branch rather than master.
The specific commit we are using has not changed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit f9a7d12014)
This should make it a bit clearer when `rm -rf` is being used in the
debug logs.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(cherry picked from commit 6c7eb34dd6)
Before 1.8.0 (2016), gpgme used to have two different thread-safe builds,
one for use with POSIX-style pthread and one for use with GNU Portable
Threads (libpth), plus a non-thread-safe version. Since 1.8.0, this
complexity has gone away and there is only libgpgme, which is thread-safe.
In practice this meant that on modern distros since 2016, we would always
fail to detect gpgme via pkg-config and fall back to calling gpgme-config.
Library-specific -config scripts are generally considered problematic
for multiarch, multilib and cross-compiling, and the gpgme-config script
recently disappeared from GPGME's Debian packaging
(see https://bugs.debian.org/1022348 and https://bugs.debian.org/1023601),
so it's better if we can prefer to use pkg-config.
If gpgme >= 1.8.0 is not found, fall back to gpgme-pthread >= 1.1.8,
either discovered via pkg-config or via gpgme-config.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 9b87e4c0d4)
When filesystem=host access is provided, some root folders are hidden, including /boot.
The bootloader specification now recommends mounting the system EFI filesystem in /efi
(currently visible) instead of /boot/efi (currently hidden). This hides /efi for the same
reasons /boot is already hidden.
(cherry picked from commit 397c97de9f)
This supplements clearing TMPDIR env variable which is only one among variables used for storing temporary files. Any of those leaking from host may confuse flatpak apps which try to save temporary files under non-existing directory in sandbox.
See https://github.com/flathub/com.logseq.Logseq/issues/29 for real world example.
(cherry picked from commit d8695f3071)
When built for i386 with Autotools, this would have detected the format
string issue fixed in #5148.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit de4de4dc44)
revokefs already gets the correct include directory from the AM_CPPFLAGS.
This would also break the build with -Werror=missing-include-dirs.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 190bad06d2)
This already happens for installs due to the cleanup path in
`flatpak_dir_deploy_install()`, but it doesn’t happen for other calls to
`flatpak_dir_deploy()`. Notably, during updates of already installed
apps.
Specifically, this means that if an app update is cancelled due to being
blocked by a parental controls policy, the temp deploy dir for that app
(such as
`~/.local/share/flatpak/app/com.corp.App/x86_64/stable/.somehex-XXXXXX`)
will be leaked. It will never be automatically cleaned up, as it’s not
in `/var/tmp` either.
Fix that by using `glnx_mkdtempat()` to create a scoped temporary
directory.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(cherry picked from commit ce1829a703)
This fixes the build on ILP32 architectures such as i386 with the Meson
build system. The Autotools build system accidentally didn't build
revokefs with -Werror=format, because it sets the target-specific CFLAGS
for revokefs but does not include the $(AM_CFLAGS) in them.
Fixes: aeecbb7d "revokefs: Split out the writing part from the fuse implementation"
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 959910f933)
The profile script previously nuked `XDG_DATA_DIRS` and then
“helpfully” re-populated it with FHS paths. This was especially
bad for systems like NixOS, which do not have `/usr`
and rely on `XDG_DATA_DIRS` heavily.
Quoting from https://fishshell.com/docs/current/cmds/set.html
> If a variable is set to zero elements, it will become a list with zero elements.
And indeed, that is what the `set -x --path XDG_DATA_DIRS` command does.
We need to list the value explicitly, if we want to preserve it
while setting variable options.
(cherry picked from commit a0505f52d9)
Exiting the process with a custom exit status (1) after systemctl stop
(SIGTERM) makes systemd treat the flatpak-session-helper service as if
it had failed.
Signed-off-by: Alberto Garcia <berto@igalia.com>
(cherry picked from commit c1f0370958)
`@filename@` expands to the relative or absolute path to the source
file, which varies between build systems and build directories.
`@basename@` expands to the basename of the file, which stays constant
across more build configurations.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 3a93ef4842)
This avoids a race condition in versions older than 2.60, while still
verifying that we can compile successfully with GLib 2.56.
Not having GLib 2.60 means we can't compile libmalcontent on Ubuntu 18.04,
so move the libmalcontent dependency to the main build job (on Ubuntu
22.04, which is new enough). This also means we don't have to compile
it from source every time.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 8a52187145)
g_time_zone_new_offset() was new in GLib 2.58, but Ubuntu 18.04 'bionic'
only has GLib 2.56, and in theory we still claim to support versions
all the way back to GLib 2.46. If that function isn't available,
reimplement it in terms of the deprecated g_time_zone_new().
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 3591ba08f6)
Some projects such as GNOME-Software need this information to know
if its safe to build against (libsoup2 vs libsoup3 conflicts).
(cherry picked from commit f1dda39e80)
(flatpak documents:2965757): GLib-CRITICAL **: 11:27:35.128: g_variant_iter_next_value: must not be called again after NULL has already been returned.
This is due to the applications iterator being checked twice even though it is empty.
(cherry picked from commit b204ed2466)
To make indentation work with less effort. The modeline was copied from
libostree with minor modification and the .editorconfig from GLib.
The advantage of having both a modeline and an editorconfig is we can
work out of the box on more editor setups, and the modeline allows us to
specify the style with a lot more fine grained control.
There can happen a race condition between internal libcurl structure
content when two threads set the `data` structure for the callbacks
from two threads, which can cause access of already freed stack-allocated
`data`, resulting in a memory corruption.
Closes https://github.com/flatpak/flatpak/issues/3701
Based on a change contributed by Léo Stefanesco; but instead of
unconditionally using FUSE 3, leave a fallback code path for FUSE 2 for
older distros.
Co-authored-by: Léo Stefanesco <leo.lveb@gmail.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
This helps to figure out what is going on if the expected paths are not
being exported.
The general design principle here is that I've used flatpak_debug2()
(which appears in `flatpak -v -v` but not `flatpak -v`) for situations
which occur under normal circumstances, and g_debug() (which appears
in `flatpak -v` or higher) for situations which are expected to be
uncommon.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Save folks a few keystrokes. There is a command which already has a '-u'
option, document-export, but it doesn't support --user so there should
be no conflict. However '-s' is used by the info command among others,
so we can't use that for --system.
We already allow normal apps to own MPRIS names but subsandboxes could not.
This allows them with the same dbus restrictions that they must be
prefixed by $app_id.Sandboxed.
This will be used by WebKitGTK.
Now that we're using the same display number in the sandbox as on the
host, we can forget about overwriting it with :99.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Suppose the user's "real" X11 display on the host is Xorg or Xwayland
listening on :42, but they also have an Xvfb server listening on :99.
If we change the X11 display number to the arbitrary value :99, and
the Flatpak sandbox shares its network namespace with the host, then
clients inside the Flatpak sandbox will prefer to connect to the
abstract socket @/tmp/.X11-unix/X99 (which is Xvfb), rather than the
filesystem-backed socket /tmp/.X11-unix/X99 in the sandbox (which is
really /tmp/.X11-unix/X42 on the host, i.e. Xorg or Xwayland).
If they're relying on Xauthority (MIT-MAGIC-COOKIE-1) for access
control (as many display managers do), then this will fail, because
we gave the sandboxed app access to the cookies for Xorg/Xwayland
(rewriting their display number from 42 to 99 as we did so), but
Xvfb does not accept those cookies.
If we're relying on `xhost +"si:localuser:$(id -nu)"` for access control
(as gdm does), then the Flatpak app will successfully (!) connect to
whatever is on :99, for example Xvfb or Xephyr, which is rarely what
anyone wants either.
Resolves: https://github.com/flatpak/flatpak/issues/3357
Signed-off-by: Simon McVittie <smcv@collabora.com>
The Desktop Entry spec says that Exec= is only required if
DBusActivatable= is not set to true, so don't emit a warning when Exec=
is missing but not required.
