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
If this is passed, we add an extra collection id binding to
the commit, as well as create a separate ref for that particular
collection id.
This weakly depends on:
https://github.com/ostreedev/ostree/pull/1805
In that without that change ostree pull will not respect
multiple collection-id bindings. It will still work for
the main/first collection id though.
Closes: #2634
Approved by: alexlarsson
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
We don't want line editing to interfere with our
formatting, so we turn on raw mode while we do
fancy progress reporting. We use raw mode at the
same times as we hide the cursor.
This should prevent partial Escape sequences from
showing up in the output.
Closes: #2638
Approved by: alexlarsson
This function helpfully does not 0-terminate the buffer,
so we have to do that ourselves. Also make the buffer
as large as possibly required, and handle errors.
Closes: #2630
Approved by: matthiasclasen
