This works around an old polkit client library bug which would cause
a segfault in this situation. The bug was fixed long ago in upstream
polkit, but is still present in Debian 10 'buster', Ubuntu 19.04 'disco'
and all older releases, due to Debian/Ubuntu using a branch of polkit
to avoid the mozjs dependency. It should finally get fixed in Debian 11
and Ubuntu 19.10.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug-Debian: https://bugs.debian.org/923046Closes: #2997
Approved by: matthiasclasen
This restores the ABI to the pre-1.4.0 version. This moves the new signal to
the *end* of the struct and also correctly decrements the padding.
Fixes https://github.com/flatpak/flatpak/issues/2957, although we probably need
a 1.4.1 release with this included pretty quickly to avoid chaos.
Closes: #2958
Approved by: alexlarsson
There are a few cases where -origin remotes don't get removed when
their refs are uninstalled, most notably when xa.noenumerate is set, or
somehow the uninstall gets interrupted at the wrong time. Regardless
of the reason, the remote could never be removed after this, unless a
new ref is installed from it and then removed, or noenumerate is set.
Closes: #2920Closes: #2953
Approved by: alexlarsson
Now that validate-icon uses execvpe(), status and error were never set,
so rerun_in_sandbox() would have crashed while dereferencing a NULL
error if execvpe() failed. This is reproducible with, for example:
FLATPAK_BWRAP=/bin/nope flatpak-validate-icon --sandbox 48 48 /path/to/icon
execvpe() does not return on success (the process image is replaced),
and sets errno on failure, so behave accordingly.
Also print the error message to stderr, even if G_MESSAGES_DEBUG is not
set, since it's our only opportunity to indicate to a caller what has
gone wrong.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2950
Approved by: alexlarsson
Without this, extensions cannot use extra-data, as there is no
indication of what runtime to run apply_extra in.
Closes: #2954
Approved by: alexlarsson
When using OpenBSD ksh `flatpak.sh` gives the following error:
/etc/profile.d/flatpak.sh[16]: syntax error: `;;' unexpected
By adding in the POSIX compliant optional opening parentheses for the
case statement branches the profile can be made more portable. This
still works with them more common shells such as bash and zsh and also
still passes `shellcheck` checks.
Aware that using OpenBSD ksh on Linux might be an edge case but there
are probably BSD users who need to use Linux for work such as myself but
still want to use the OBSD shell which has been ported to Linux:
https://github.com/dimkr/loksh
Many thanks to @gumnos for pointing out the fix here via Twitter.
Closes: #2947
Approved by: mwleeds
I spotted this line in the output from `flatpak history`:
Jun 4 16:17:20 deploy install com.discordapp.Discord x86_64 stable system flathub 8a0fc700c701 Installed %s from %s root (test) flatpak-system-helper (gnome-software) 1.3.3
This is because the format string is passed as the 'url' parameter, the
first format parameter (the ref) is passed as the 'format' parameter,
and 'origin' is ignored because (fortunately) as far as I know, no
character significant to printf (like '%') is permitted in ref names.
Fix this by passing a NULL 'url', like the neighbouring call in
flatpak_dir_deploy_update().
Flatpak already doesn't show the architecture column in the output of
"flatpak list" if every flatpak has the same architecture. This commit
does the same for the table printed for install/update/uninstall
operations, except if the user specifies an arch on the command line.
Fixes https://github.com/flatpak/flatpak/issues/2794Closes: #2930
Approved by: matthiasclasen
Download size of object depends on the compression used in the ostree
repository. When a different source repository is specified, download
size might change. So this metadata needs to be recalculated.
This issue happens with Freedesktop SDK which for build time
optimization reason run an intermediate build-export on a bare
repository.
See issue https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/787Closes: #2925
Approved by: alexlarsson
Toolbox [1] containers, like Flatpak containers, need to keep some
configuration files synchronized with the host. eg., /etc/localtime,
/etc/resolv.conf, etc.. The easiest way to keep them updated is to bind
mount the entire /etc from the host at some location inside the
container, and then replace the container's copy of the files with
symbolic links to the bind mounted copies.
However, this doesn't work when the host's copy of a configuration file
is itself a symbolic link to a location outside /etc. eg.,
/etc/localtime, which points somewhere inside /usr/share/zoneinfo. In
that case the host needs to be actively monitored via inotify(7) and
an updated copy of the file needs to maintained in a separate
directory, which can be bind mounted into the container.
This monitoring infrastructure is already present in Flatpak and it
makes sense to leverage it for Toolbox containers too.
However, Flatpak containers have only one user, the current one logged
into the host, whereas Toolbox containers have a longer list of users
like the host itself. Therefore, if the directory getting bind mounted
(ie., $XDG_RUNTIME_DIR/.flatpak-helper/monitor) isn't world readable,
then some users inside the container won't be able to read the
configuration file. eg., this will fail:
$ sudo -u operator cat /run/host/monitor/localtime
Relaxing the directory permissions on the host shouldn't pose a
security risk. They are copies of originals that are world readable
anyway.
[1] https://github.com/debarshiray/toolboxCloses: #2916
Approved by: alexlarsson
This fixes a warning pointed out by lgtm.com. I checked that the following
still works:
$ PAGER=more flatpak-bisect -b stable org.gnome.Builder log
Closes: #2894
Approved by: matthiasclasen
This sets FLATPAK_FANCY_OUTPUT=0 in most tests and then special cases
the test_fancy_output() test in case the installable tests are running
on an actual tty. This was causing failures because the added bold escapes
caused some test cases to not generate the expected output.
Closes: #2907
Approved by: alexlarsson
