WAYLAND_DISPLAY can be other than "wayland-0" for various reasons, such
as using a custom Wayland display server or the session display server
using a custom display name.
Note that for xdg-desktop-portal to support showing portal windows, the
xdg-desktop-portal service MUST use the same WAYLAND_DISPLAY.
* Use ostree's BARE_USER_ONLY flag
Now that Ostree has a 'bare user only' mode for repositories, we should
use it.
This allows installing Flatpak run times inside different Docker layers.
Original patch by: Alexander Larsson <alexl@redhat.com>
Tested-by: Emmanuele Bassi <ebassi@gmail.com>
* Use the parent mode when creating a child repo
Instead of hard coding the repository mode, query the parent's mode.
* Gate bare-user-only repo creation behind an environment variable
We keep the default of bare-user repositories, but with an environment
variable we change new repositories to bare-user-only.
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.
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.
The export g_autoptr changes in ostree will be in the release 2017.4,
but the gnome CI is currently failing due to them also being in current
git master which is called 2017.3 atm. We fix this by checking against
2017.3 instead, which is safe, because the actual OSTREE_CHECK_VERSION
macro was added after the 2017.3 release too.
This means we verify the exact data we use, which is
what was signed. In particular, this means in the
system-helper we don't open us up to the user
manipulating the file while it is being applied.
This ensures the actual manifest ref matches what was specified
in the index. This is required as the goal is to sign/trust
the manifest, but not necessarily the index.
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
In ostree I maintain what I consider a "baseline" set of compiler
warnings that should *always* be fatal for a modern C project.
I noticed while working on a previous patch that a `-Werror=format`
warning wasn't fatal.
There are a few that are really, really important like
`-Werror=missing-prototypes`. I also take some like `-Werror=misleading-indentation`
which already caught some bugs. See also https://lwn.net/Articles/678019/
One benefit here becomes immediately obvious - `flatpak_fail()` was lacking
`G_GNUC_PRINTF` which meant we missed a lot of type checking. Fix up the
callers.
If you do something like:
flatpak build --talk-name=org.foo.Bar appdir
Then we now spawn a dbus proxy for the app.
However, we don't do this by default, even if the
runtime or the app metadata allows this, because
we want builds to normally be disconnected from
the build host.
This is a major change in the OCI support, as the format of the OCI image
registries changed. Instead of now having a "ref" file for each image
in the repo it has a single index json file, where the ref name is now
a per-image annotation.
This allows us to support OCI much better, as we can now use the actual
flatpak ref as the OCI ref name, and we can find all the flatpak refs
in a remote.
So, with this you can just use:
flatpak remote-add --oci remote-name URL
and then you can use the regular flatpak operations on the remote.
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.
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.
Alexander Larsson