If you run "flatpak update" then we will never update to
a commit that is older than the currently installed one. This
protects against a man-in-the-middle attack that would otherwise
let the attacker downgrade to a previously signed version that
may have some vulnerability.
(cherry picked from commit 3ff6d312de)
We never want the system-helper to downgrade. If you want to run
not-the-latest version you need to be "real root". However, the
check for this was broken, as it compared the new commit with the
new commit, which was always ok. Instead check the timestamp
on the new commit with the current one.
(cherry picked from commit 266b9cb6f0)
Sometimes we get an EAGAIN error in the due to the socket being
nonblocking. In the setup phase we just allocated the new buffer
and this causes a leak. Free it in this case.
(cherry picked from commit 6a63a905bf)
The header returned from parse_header contains references
to the buffer it was used to parse from, and in some
cases we dereference these headers after freeing the buffer.
For instance this happens when we're filtering a message, and
then we later look at the destination to figure out what
kind of error to send back.
I couldn't find any cases where this would let the client
do anything other than return a different error value, but
this is still possibly a security issue.
(cherry picked from commit 18a45712cc)
We should not terminate the extension search just because
an earlier directory succeeds. Even non-existant directories
succeed, and anyway we should continue searching even if it
wasn't empty, because multiple subdir extensions may match.
Fixes https://github.com/flatpak/flatpak/issues/654
(cherry picked from commit 82aad1ccb1)
This is required for e.g. G_DECLARE_FINAL_TYPE, and most current
distros have this now.
This fixes https://github.com/flatpak/flatpak/issues/622
For distributions that want to build against older glib, see
the issue above, it has patches to make that work.
(cherry picked from commit dcccb3c807)
When calculating the progress of a flatpak installation,
it considers the extra-data and OSTree pull as different
operations and that makes the progress to go back and
forth between 0% and 100%.
Consumers of this API, like GNOME Software, end up having
a bad experience reporting the progress of a Flatpak app
instalation.
Fix that by using a set of heuristics to improve the process,
splitting the operation in parts that can be tracked (or at
least estimated).
(cherry picked from commit d74956c23a)
By splitting the extra-data setup - where we set the number of
extra-data downloads and auxiliary information - and download -
where we actually fetch the extra-data - we can have more precise
progress reports.
(cherry picked from commit d73090cc96)
* Append flatpak data dirs if XDG_DATA_DIRS is already set
Otherwise it will be impossible to run flatpak apps from desktop menus.
This issue can happen if another app (e.g. snapd) wants to add custom
folders to XDG_DATA_DIRS through /etc/profile.d
If XDG_DATA_DIRS is empty or unset, define it as before.
Fixes#606
(cherry picked from commit a9acdc0532)
For a few commands the options aren't fully documented. This commit
makes the manpage documentation (almost) match the options shown
when you run "<command> --help" on the command line.
(cherry picked from commit 2d07f7d455)
This means an extension point can include extensions of multiple
(specified) versions. This is useful for e.g. the GL extensions,
where we want a single extension for all the essentially unversioned
GL extensions (like the nvidia one) that is used by all the
runtimes.
(cherry picked from commit 640a02315b)
We're getting "fuse: copy from pipe: short read" from
libfuse and a broken filesystem with this. See
https://github.com/flatpak/flatpak/issues/570
I've tried to look into if this is fixable, but I can't
really find any way we could do things differently that
may help, so the fix is to disable spice_read.
(cherry picked from commit 4fdac9e5d4)
Otherwise, anytime we fail in ostree_repo_write_metadata() will cause
an invalid free to happen, and flatpak to crash.
(cherry picked from commit d0b5b51076)
In case you happen to have a reference A with a related reference
B (say a runtime and a GL extension), and they come from different
remotes, then updating A should not cause B to update from the same
remote as A, but rather the current remote.
(cherry picked from commit 6793d90b82)
When we update an app and add updates for all the related
operations, such as locates, and it is already installed,
make sure we inherit the current subpaths rather than
use the default ones.
Fixes https://github.com/flatpak/flatpak/issues/587
(cherry picked from commit 51e14fe33b)
At the moment, flatpak applications are only given FamilyLocal family
xauth cookies from the Xauthority file. This is so, the sandboxed
application doesn't inadvertently get access to displays on other
computers.
But FamilyLocal isn't the only xauth family that's local. FamilyWild
entries can be local as well.
Furthermore, FamilyWild entries are preferable to FamilyLocal entries
when found, because they don't break if the system hostname is changed.
This commit makes FamilyWild xauth entries get propagated in the same
way as their FamilyLocal counterparts.
(cherry picked from commit a82708cb10)
