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
(cherry picked from commit 7a5c024695)
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
(cherry picked from commit 28e96288c4)
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.
(cherry picked from commit 468858c1cbcdbcb27266deb5c7347b37adf3a9e4)
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
(cherry picked from commit 7c9368d100)
This reverts commit e209ac9e10.
We're counting thee escape sequences as width, until we fix
this we disable this.
Closes: #2686
Approved by: alexlarsson
(cherry picked from commit 2ea428a541)
We don't need a polkit agent for simple things like
flatpak --installations. Only install it for running
actual commands.
Closes: #2679
Approved by: alexlarsson
We don't really need a separate process here, and
doing things this way makes output from the sandbox
appear outside, thereby giving us meaningful error
messages for invalid icons.
Related: #2669Closes: #2677
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
If G_MESSAGES_DEBUG is set in the shell's start-up scripts, then the
"flatpak --installations" output is contaminated with these strings:
(flatpak:4558): flatpak-DEBUG: ...
Fallout from 30c2919624Closes: #2673
Approved by: alexlarsson
In f7a566e2ab, the flatpak_installation_get_display_name()
api was changed to (almost) always return a non-NULL string. Adapt
to this change, in order to use the preferred messages here.
Closes: #2655Closes: #2668
Approved by: alexlarsson
During build-time tests, bwrap doesn't necessarily work. In particular,
official Debian autobuilders can't enter namespaces.
We continue to leave the sandbox enabled in the build-export calls in
tests/test-extensions.sh, tests/test-unsigned-summaries.sh
and tests/test-update-remote-configuration.sh, which are already
skipped if bwrap isn't available. This means we exercise both the
normal and --disable-sandbox code paths.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #2661
Approved by: alexlarsson
In a previous iteration of the work for supporting multiple collection
bindings on a commit[1][2] the key ostree.collections-binding was used,
but it was decided that ostree.collection-refs-binding makes more sense.
So update build-commit-from in one place where the old key was still
being used. This impact of this bug is that we would overwrite the value
of ostree.collection-refs-binding on the new commit with the one on the
source commit (which may not have all the same collection-refs
associated with it). However since the libostree support for that key
hasn't been merged that wouldn't cause any problems yet.
[1] https://github.com/flatpak/flatpak/pull/2634
[2] https://github.com/ostreedev/ostree/pull/1805Closes: #2644
Approved by: matthiasclasen
These don't have AS_BUNDLE_KIND_FLATPAK, but we can just
assume all bundles are flatpak bundles in the appstream data
we get from flatpak.
Closes: #2650
Approved by: alexlarsson
