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>
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>
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>
Normally, we want to save a process and get better signal handling
by replacing the `flatpak run` process with bubblewrap.
However, when we're doing profiling or measuring coverage, we want to
exit cleanly so that profiling data can be recorded, which is done in
an atexit() hook. In this situation, bypass the execve() optimization;
instead, start bubblewrap in the background, immediately wait for it,
and propagate its exit status.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Caught by @gasinvein on #4575 post-merge: I didn't realize fish has a
separate folder for config files provided by the vendor vs added by the
user. This changes the install directory to match the vendor config dir.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
Technically, Fish users can already make this work using
https://github.com/edc/bass, but it's also nice to have this working on
an out-of-the-box Flatpak installation.
Fixes#3109.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
This takes them out of the directory that is "owned" by the subproject,
which will not be ignoring our Flatpak-specific generated files in
its .gitignore, and puts them in a directory that is "owned" by Flatpak,
which can ignore them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is a step towards being able to build Flatpak using Meson, which
is becoming widely available even in LTS distributions. Meson's
built-in support for subprojects expects to find them in ./subprojects
at top level.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This passes -fsanitize=address in the right place.
Passing it this way instead of CFLAGS allows us to strategically
not add sanitize in specific places as needed.
This reduces the amount of shell in use, and the number of subprocesses
spawned by that, so our system environment generator is as fast as
possible when used in the critical startup path.
It adds a new system environment generator so that the system flatpak
installation can be used outside of a user session. In particular, this
allows enumeration of system-installed flatpaks in gnome-initial-setup
in order to set parental controls on them.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Currently with the sideload implementation of offline updates you have
to manually create a symlink to your USB drive to sideload from it,
which is a regression compared to the previous implementation which
scanned all mounted filesystems in OstreeRepoFinderMount in libostree.
So this commit adds a few systemd units and a bash script so that any
time a USB drive is plugged in and automatically mounted by udisks, a
symlink to it is created in /run/flatpak/sideload-repos. When the drive
is unplugged the symlink is removed.
However this solution still has a lot of moving parts, so we may want to
instead have libflatpak use GVolumeMonitor and find the mounted
filesystems itself; see https://github.com/flatpak/flatpak/issues/3705
Fixes https://github.com/flatpak/flatpak/issues/3490
Given a configuration like:
[remote "oci-remote"]
url=oci+http://some.server.com/api/v1/organization/foo?index=labels
xa.authenticator-name=org.flatpak.Authenticator.Oci
xa.default-token-type=1
xa.authenticator-options={"auth": <"a-token-here">}
I was able to install an app from an OCI remote that required a login
Historycally the system helper has been running in a generic
unconfined_service_t domain. However, this caused problems with the
new revokefs support, because passing the revokefs unix domain socket
over the system bus got it kicked of the bus, because to do this
dbus-daemon needs rw rights to the socket.
So, this module creates a custom domain flatpak_helper_t, which
allows us to add special permissions to dbus-daemon to allow
access to its sockets.
The domain is otherwise uncontained just like before. I did try
to make it contained, but that is a lot of work as the permissions
it needs are very complex.
Note to packagers on selinux systems, for flatpak to work well
you need to install this module and relabel the system-helper
binary.
In my testing on fedora I used something like this:
%post
%selinux_modules_install %{_datadir}/selinux/packages/flatpak.pp.bz2
%postun
if [ $1 -eq 0 ]; then
%selinux_modules_uninstall %{_datadir}/selinux/packages/flatpak.pp.bz2
fi
With these new files:
%{_datadir}/selinux/packages/flatpak.pp.bz2
%{_datadir}/selinux/devel/include/contrib/flatpak.if
Closes: #2657
Approved by: alexlarsson
This adds a new helper method "GetRevokefsFd" which is responsible
for spawning the backend part of the revokefs filesystem. It takes care
of creating a cache location for the backing directory in repo/tmp.
This cache location is transferred over D-Bus to the client with the
other end socket fd.
The client on receiving the socket fd creates a mountpoint directory and
spawns the revokefs-fuse filesystem. It then creates a child repo for the
pull. In any case of failure, it fallbacks on the current code path
(which causes temporary duplication of files on disk).
The backing dir itself and all files written to it by the revokefs-fuse
backend process are owned by the "flatpak" user. After the pull in the
child repo is completed, it's ownership is then canoncalized with owner=root
and permissions as per bare-user-only in Deploy().
Now we have fulfilled all the criteria to hardlink the child repo into
the system one and avoid duplication. See [1].
If there is existing cache directory available in repo/tmp, it will be
mounted using revokefs-fuse for the current pull. Hence, it is possible
to recover the previous partial pull which might have failed due to some
error.
[1] https://github.com/ostreedev/ostree/pull/1776Closes: #2657
Approved by: alexlarsson
This is a script that program that gets run by systemd
before every user service to set up the environment.
See systemd.environment-generator(7) for details.
Closes: #2122
Approved by: matthiasclasen
This adds a --enable-coverage configure option and a
coverage target to generate coverage testing for
the testsuite. The generated html ends up in the
coverage/ directory.
Closes: #2187
Approved by: alexlarsson
This moves all the files from lib into common, and it also adds all the libflatpak
sources into libflatpak-common, making libflatpak just a wrapper around the common
helper library.
This move allows the CLI to use all the code from libflatpak. We were already doing
this with a few things like flatpak-error*.[ch], and we want to do it even more
when sharing FlatpakTransaction. This also allows use to slowly move
the CLI to using the libflatpak apis for some things.
Closes: #1706
Approved by: alexlarsson
This listens to org.freedesktop.portal.Flatpak and lets flatpak
sandboxes do flatpak specific things.
Initially this only allows access to "Spawn", which lets you start a
new copy of the current or latest version of the calling app,
optionally with sandboxing.
This allows the app to re-start itself with the latest version after
an update, and the sandboxing is useful for apps that want to manually
sandbox part of themselves.
You can also expose one or more subdirectories of
~/.var/app/$appid/sandbox/ to the app, read-write or read-only. This is
useful to communicate with the sandbox.
This is now in xdg-desktop-portal. We keep a version of the document
portal dbus XML so that we avoid weird build dependencies.
Flatpak itself is technically not dependent on the document portal,
but it is very much recommended that you use it.
Closes: #1398
Approved by: alexlarsson
Followup to the previous commit to use `O_TMPFILE`, for
the cases here what we really want is to use sealed memfds. This
ensures the container can't mutate the data we pass.
Now, the args fd I was looking at turned out to be a bwrap bug,
but this is a good example of the mitigation:
```
$ flatpak run --command="/bin/sh" org.test.Hello
ls -al /proc/$$/fd
total 0
dr-x------. 2 1000 1000 0 Oct 1 16:43 .
dr-xr-xr-x. 9 1000 1000 0 Oct 1 16:43 ..
lrwx------. 1 1000 1000 64 Oct 1 16:43 0 -> /dev/pts/2
lrwx------. 1 1000 1000 64 Oct 1 16:43 1 -> /dev/pts/2
lrwx------. 1 1000 1000 64 Oct 1 16:43 2 -> /dev/pts/2
lrwx------. 1 1000 1000 64 Oct 1 16:43 255 -> /dev/pts/2
lrwx------. 1 1000 1000 64 Oct 1 16:43 9 -> /memfd:bwrap-args (deleted)
org.test.Hello$ echo foo > /proc/self/fd/9
sh: /proc/self/fd/9: Operation not permitted
```
Closes: #1064
Approved by: alexlarsson
This is the first step in increasing the startup performance for
font use in flatpak. Right now every app has its own cache
for the system font dirs, which means they must be fully regenerated
the first time the app starts.
With this we now expose the host system and per-use fontconfig caches
in the sandbox (read-only). This allows the sandbox to re-use caches
from the host, if the runtime fontconfig configuration is correct.
Unfortunately, this doesn't currently work, because the font caches
are looked up based on absolute paths to the font directories and they
are different in the host and the sandbox. There is some work in
progress to fix this in fontconfig here:
https://bugs.freedesktop.org/show_bug.cgi?id=101889
It uses inline for loop initialisers, which are a C99 feature. Set
-std=gnu99 like ostree.git does for its libglnx submodule.
Based on a patch by Georges Basile Stavracas Neto
<georges.stavracas@gmail.com>.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
For example, add $(AM_CFLAGS) to mumble_CFLAGS. Since $(WARN_CFLAGS) is
only added to $(AM_CFLAGS), this fixes the lack of inclusion of the
compiler warning flags in the compilation of half of flatpak.
Note that $(AM_*) variables are only used by automake if a more specific
(per-target) special variable is not defined instead. So if you define
mumble_CFLAGS, AM_CFLAGS will not be used for that target unless
explicitly included in mumble_CFLAGS.
See
https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html.
Do the same for $(AM_LIBADD), $(AM_LDFLAGS), etc. These are not
currently defined, but it’s good practice to include them in
mumble_LIBADD (etc.) just in case they’re defined in future. Hopefully
their inclusions will be cargo-culted to any new targets which are
added, retaining full coverage of the code base.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This ensures it’s always included in the build, regardless of whether
someone forgets to #include it from a C file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In ostree I maintain what I consider a "baseline" set of compiler
warnings that should *always* be fatal for a modern C project.
I noticed while working on a previous patch that a `-Werror=format`
warning wasn't fatal.
There are a few that are really, really important like
`-Werror=missing-prototypes`. I also take some like `-Werror=misleading-indentation`
which already caught some bugs. See also https://lwn.net/Articles/678019/
