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>
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>
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>
Following on from commit 85a83a06f9, add some code to clean up old
leaked deploy tmpdirs when we next try to deploy the same app
(successfully or not).
This should free up disk space leaked by failed deploys pre-85a83a06f95.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
In theory we could have ended up linking a non-threadsafe version of
GPGME, since the version without the -pthread suffix has only been
thread-safe since 1.8.0.
In practice we require version 0.53 of Meson (available in Ubuntu 20.04,
Debian 11, etc.) so it seems reasonable to require a contemporary
version of GPGME (1.8.0 is available in Ubuntu 18.04, Debian 10, etc.)
and drop the complexity of handling this in a fully-backwards-compatible
way. Users of older LTS distributions like Ubuntu 16.04 should continue
to build Flatpak with Autotools.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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>
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.
These are the easy places to use the new `deploy_base_dfd` from to make
some more operations relative to an already-open dirfd in
`flatpak_dir_deploy()`.
This should introduce no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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>
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.
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>
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>
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>
This is somewhat faster than Autotools. We still use Autotools for
the alt, clang and valgrind builds, to make sure we cover both.
As a bonus, the use of undefined behaviour and address sanitizers here
actually works (unlike in Autotools, see #4844) so we're getting test
coverage with detection of common issues like use-after-free.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In particular, this version has more gtestutils backports, including a
version of g_test_message() that preserves correct TAP syntax for
multi-line messages.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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.
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>
If this environment variable is set on the host, it's going to mess up
authentication in the sandbox. For example, if the host has:
KRB5CCNAME=KCM:
then the sandboxed process will try to use the host KCM socket, which is
not available in the sandboxed environment, rather than the gssproxy
socket that we want it to use. We need to unset it to ensure that
whatever configuration we ship in the runtime gets used instead. We have
switched the GNOME runtime to use an empty krb5.conf and it works as
long as we don't break it with this environment variable meant for the
host.
We're using a directory rather than binding a socket directly for
increased robustness. In theory, if gssproxy crashes on the host, a new
socket that a new gssproxy process creates should be immediately visible
inside the sandbox. Nifty.
Previously, applications that wanted to use Kerberos authentication
would have to punch a sandbox hole for the host's KCM socket. In
contrast, this gssproxy socket is designed for use by sandboxed apps.
See also: https://github.com/gssapi/gssproxy/issues/45
`@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>
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>
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>
