Make flatpak_dir_system_helper_call capable of dealing with a GUnixFDList
parameter and subsequently call g_dbus_connection_call_with_unix_fd_list_sync
for those methods.
Closes: #2657
Approved by: alexlarsson
For compatibility with libappstream we create a $origin ("flatpak")
subdirectory with symlinks to the size directories thus matching the
standard merged appstream layout if we assume the appstream has
origin=flatpak, which flatpak-builder creates.
See https://github.com/ximion/appstream/pull/224 for details.
Fixes https://github.com/flatpak/flatpak/pull/2779Closes: #2789
Approved by: alexlarsson
Currently a FlatpakTransaction object only operates on one installation,
but uses others (by default the system installations) for dependencies
such as runtimes. In addition to checking those dependency installations
for runtimes we check their configured remotes when deciding whether to
add a new remote as an origin for a flatpakref or as a runtime remote
for a flatpakref. This commit changes the behavior so that we only check
the installation being operated on to find out if a remote already
exists. This is the correct behavior in both cases: the origin remote
and the runtime remote. Otherwise the installation can error out when it
fails to find the runtime, or it can fail to respect the
SuggestRemoteName key which is supposed to dictate the name for the
origin remote.
One side effect of this is that a remote might be duplicated in the user
installation which already exists in the system installation, even if
the runtime it provides is already installed. But if you don't want
remotes in multiple installations you can just stick to using one
installation consistently.
Also, add a unit test for this in testlibrary.c (which required a bit of
refactoring).
Fixes https://github.com/flatpak/flatpak/issues/2758Closes: #2761
Approved by: alexlarsson
Rather than creating a real temp directory and
then commiting that we generate an in-memory mtree
which mostly refers to pre-existing icon file
objects, and then the newly created appdata xml.
Closes: #2753
Approved by: alexlarsson
It makes more sense to have this in flatpak_create_soup_session() so
every caller of that interprets the env var.
Closes: #2740
Approved by: matthiasclasen
Currently Flatpak has a few different implementations of helper
functions to download a URI using libsoup, but the best one seems to be
in common/flatpak-utils-http.c. So this commit deletes the others and
makes use of flatpak_load_http_uri() in place of download_uri() in a
few places. This has a couple consequences:
1) It means that we're now properly checking HTTP status codes rather
than assuming that the request was successful, in the install command,
remote-add command, and in FlatpakTransaction. This fixes an assertion
failure seen by a user when they tried to use a flatpakref URL that hit
a 404.
2) It means that in the places where we're using flatpak_load_http_uri()
we are only supporting http:// and https:// URLs not, say, file:// ones.
For the install and remote-add commands this was already being enforced.
For the handling of flatpakref files and bundles in FlatpakTransaction,
I believe it's just convention because it doesn't make much sense to
do anything else; this commit enforces that convention.
Also, add a unit test for the case of trying to install a flatpakref at
a URL that hits a 404 error.
Fixes https://github.com/flatpak/flatpak/issues/2727Closes: #2740
Approved by: matthiasclasen
Commit b20ee7e26 introduced a bug where flatpak_load_deploy_data()
returns NULL without setting @error in the case that there's a problem
reading the deploy file. I think this is causing a seg fault in
flatpak_installation_list_installed_refs() which tries to print the
error message after calling get_ref() (which indirectly loads the deploy
file).
I didn't personally verify that this fixes the GNOME Builder seg fault
that was reported, but it seems almost certain looking at the provided
stack trace, since get_ref() only returns NULL if
flatpak_dir_get_deploy_data() returns NULL, and that function clearly
sets the error pointer on failure except in flatpak_load_deploy_data().
I'm not sure why the deploy file doesn't exist (or is unreadable) for
the user who reported this seg fault.
Fixes https://github.com/flatpak/flatpak/issues/2717Closes: #2733
Approved by: matthiasclasen
Uncrustify has an option "nl_func_var_def_blk" which is supposed to
ensure there's a newline character between the block of variable
definitions and the rest of the function body, but it gets confused and
thinks that the first instance of "g_autoptr" or "g_auto" being used on
a variable is the start of the function body. So this commit removes
those extra newline characters and removes that option in uncrustify.cfg
so they don't get re-added the next time uncrustify is run.
Here's the command I used:
perl -0777 -i -pe 's/\n(\n\s*g_auto\()/\1/g' `git ls-tree --name-only
-r HEAD | grep \\\.[ch]$ | grep -v common/valgrind-private.h |
grep -v app/flatpak-polkit-agent-text-listener\\\.[ch]`
I ran it again with "g_autoptr" in place of "g_auto", and made a few
manual edits to add back the newline when the g_auto* was in the middle
of a function body rather than at the top.
Closes: #2715
Approved by: matthiasclasen
Edit uncrustify.cfg to add options to remove extra newlines near opening
and closing braces, and run uncrustify again.
Closes: #2715
Approved by: matthiasclasen
We do a one-time conversion of existing dconf user settings
into a keyfile in the apps XDG_CONFIG_DIR, where the glib
keyfile settingsbackend will look for it.
Closes: #2678
Approved by: alexlarsson
Whenever we use $XDG_RUNTIME_DIR and expose it somehow in the sandbox
we fully resolve the path, because if (as happens on gentoo for instance)
it contains /var/run -> ../run, then flatpak thinks we need to
add the /var/run symlink in the runtime even though we already
exposed that.
Closes: #2710
Approved by: matthiasclasen
As shown by CVE-2019-5736, it is sometimes possible for the sandbox
app to access outside files using /proc/self/exe. This is not
typically an issue for flatpak as the sandbox runs as the user which
has no permissions to e.g. modify the host files.
However, when installing apps using extra-data into the system repo
we *do* actually run a sandbox as root. So, in this case we disable mounting
/proc in the sandbox, which will neuter attacks like this.
For whatever reason, in the buildbot environment the TIOCGWINSZ
ioctl returns a 0x0 size, which causes a divide by zero. We
handle this by returning a default 80x24 size.
Closes: #2685
Approved by: alexlarsson
We only interested in a few of the attributes of some
tags, but we shouldn't fail if other valid attributes
are present.
Add some of the allowed attributes to the <release> element
in the appdata test and verify that we can still parse it.
The appstream spec is here:
https://www.freedesktop.org/software/appstream/docs/Closes: #2674
Approved by: matthiasclasen
This file lists the directories that are remapped in the sandbox,
allowing fontconfig to use the correct cache identifier for the
host-side caches.
As an example, this generates:
```
$ ./flatpak run --command=sh org.gnome.gedit
[📦 org.gnome.gedit flatpak]$ cat /run/host/font-dirs.xml
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<remap-dir as-path="/usr/share/fonts">/run/host/fonts</remap-dir>
<remap-dir as-path="/home/alex/.fonts">/run/host/user-fonts</remap-dir>
</fontconfig>
```
Closes: #2635
Approved by: alexlarsson
The spec allowed either timestamp or date to
be specified for a release, so we should support
both.
Closes: #2614Closes: #2619
Approved by: alexlarsson
This lets us export D-Bus service files for
names like org.foo.Bar.Application.Tracker.service
when the app-id is org.foo.Bar.
Closes: #2615Closes: #2616
Approved by: alexlarsson
If the user (erroneously) runs as root while modifying their user
installation, e.g. with "sudo flatpak --user install ...", this can
cause "permission denied" errors later on when they try to operate on
the installation as their own user. So refuse to execute a transaction
on a user-owned installation as root. Root can still operate on their
own per-user installation.
This approach does have a weakness: if flatpak is running as root when the user
installation is first created, it will be owned by root and therefore
avoid this check. I'm not sure what could be done about that.
Fixes https://github.com/flatpak/flatpak/issues/2565Closes: #2575
Approved by: alexlarsson
We want to move away from using dconf inside the sandbox,
and instead use the keyfile backend for GSettings, which
has gained the capability to read defaults and locks.
This change makes the dconf database contents and locks
available in a suitable format. The files appear inside
the sandbox in the /etc/glib-2.0/settings directory.
We only export the default values for keys in the dconf
subtree whose path matches the app id, as well as prefixes
listed in paths key from the X-DConf group in metadata.
This commit adds a new dependency, since we're now linking
against libdconf.
Closes: #2295
Approved by: alexlarsson
We no longer use it here. flatpak itself still links
against it. This avoids problems with consumers who
might also link against libappstream.
Closes: #2580
Approved by: alexlarsson
This function has libappstream-glib types in the
api, which we want to drop. And it is only used
in app/, so move it there.
Closes: #2580
Approved by: alexlarsson
Document the values returned by flatpak_installation_get_id()
and by flatpak_installation_get_display_name() for standard
installations.
Closes: #2583
Approved by: alexlarsson
Return non-NULL strings from flatpak_dir_get_id()
and flatpak_dir_get_display_name() for user installations,
to save library users the hassle of dealing with NULL
return values.
Closes: #2583
Approved by: alexlarsson
When we deploy e.g. app/org.foo.bar/x86_64/stable, then we
also create a deploy/app/org.foo.bar/x86_64/stable ref pointing to
the latest deployed commit. We also remove it when an app is uninstalled.
This means that a prune operation will not delete objects that are deployed
(which would not save any space anyway). This is nice because this can
happen for instance when you flatpak update --no-deploy.
Fixes https://github.com/flatpak/flatpak/issues/2085Closes: #2563
Approved by: alexlarsson
It's no longer true that it's the pull code's job to resolve a ref to a
specific commit. Ever since commit 66eee3c2c this is the job of the
resolve_ops() function used by FlatpakTransaction (at least, when a
transaction is being used). So update a couple comments to avoid
confusion.
Closes: #2587
Approved by: alexlarsson
