Instead of FLATPAK_ERROR_ABORTED, return G_IO_ERROR_CANCELLED when the
passed in GCancellable gets cancelled. This makes it possible to cancel
updates in gnome-software without getting a generic "Aborted due to
failure" error popup.
Closes: #2178
Approved by: alexlarsson
--device=all really means the device nodes, we should not expose the host
shared memory objects.
This change incidentally fixes issues with --device=all on debian (#2136)
where /dev/shm is a symlink to /run/shm, which doesn't exist in the sandbox.
Closes: #2160
Approved by: alexlarsson
It is not really nice to have g_warnings pop out of
the library left and right, they should be replaced
by proper errors as far as possible. This is a small
start.
Closes: #2150
Approved by: alexlarsson
Add FLATPAK_ERROR_INVALID_DATA and use if for cases where
the incoming data for an update or install is faulty, and
add FLATPAK_ERROR_UNTRUSTED, FLATPAK_ERROR_SETUP_FAILED and
FLATPAK_ERROR_EXPORT_FAILED to cover more error conditions.
Closes: #2150
Approved by: alexlarsson
flatpak_fail is a convenient shortcut, but falls short
for actual error reporting. Use proper G_OPTION_ERROR
error codes here.
Closes: #2150
Approved by: alexlarsson
flatpak_find_deploy_for_ref_in is a variation of
flatpak_find_deploy_for_ref that allows to restrict
what installations to search in.
Closes: #2158
Approved by: alexlarsson
We were exporting files in subdirectories of all the common
directories. This only really makes sense for icons. For
desktop files, D-Bus service files and mime types, we should
only export from the exact directory itself.
Note that this makes us no longer support the obsolescent
vendor-prefix convention of the desktop entry spec, which was
only relevant for KDE4 and breaks app-id matching.
Closes: #2142Closes: #2152
Approved by: alexlarsson
This fixes the “bwrap: Can't mkdir parents for /var/run/user/1000/.dbus-proxy/: No such file or directory” error. This error occurs on systems where the path in the XDG_RUNTIME_DIR variable contains a symlink under var, for example /var/run → /run.
The reason for the error is that bubblewrap was called both with “--bind /var /var” and “--bind /var/run/user/1000/.dbus-proxy/ /var/run/user/1000/.dbus-proxy/”. This leads to the destination path already existing but with “/var/run” being a symlink. Bubblewrap then tries to make sure the mount point is present in the sandbox and creates all the dirs with its parents, which fails for “/var/run/user” because its parent is a symlink.
This fix simply resolves the path used for the runtime dir before it adds it to the bind parameter.
Closes: #2137
Approved by: alexlarsson
Based on my understanding of the matter, we claim
that FlatpakInstallation api is threadsafe.
This commit rewords things a bit, to more strongly
recommend FlatpakTransaction as the preferred API
for the tasks that it covers.
Closes: #2141
Approved by: alexlarsson
Currently Flatpak reads a repo metadata key called "xa.collection-id" to
decide whether to configure a collection ID on a remote. This commit
drops support for xa.collection-id and replaces it with
ostree.deploy-collection-id, which is a key defined by OSTree but so far
only implemented here.
The reason for the change is so that collection IDs can only be deployed
to users running recent versions of Flatpak and OSTree. The current
situation is that Endless wants to deploy collection IDs (and therefore
support for doing USB updates) to users, but servers such as Flathub
can't safely set xa.collection-id in their metadata, because many users
are still using old versions of Flatpak and OSTree[1] which would hit
various bugs[2][3][4] on the P2P code paths that are enabled by
collection IDs. Defining a new key means that only users running
recent (as-yet-unreleased) versions of Flatpak and OSTree will pay
attention to it and deploy the collection ID, leaving the users on old
versions unaffected.
The reason this metadata key is being defined at the level of OSTree
instead of Flatpak, is that OSTree may want to implement it in the
future.
The functionality of deploying a collection ID by setting the
"deploy-collection-id" key in the config on the server side (which in
turn causes ostree.deploy-collection-id to be set) is already covered by
the unit tests in test-update-remote-configuration.sh; this commit just
tweaks them to use the new key.
Another solution I proposed to this problem was to have a key
"eos.collection-id" which would only be understood by the Endless fork
of Flatpak, and use that temporarily until enough people are running
recent versions of Flatpak, at which point "xa.collection-id" can be
used. But this solution (abandoning xa.collection-id upstream) allows us
to avoid that migration step and leave users on old versions of Flatpak
completely unaffected.
[1] https://ahayzen.com/direct/flathub.html#downloadsbyflatpakstacked
[2] https://github.com/ostreedev/ostree/commit/e4e6d85ea
[3] https://github.com/flatpak/flatpak/commit/5813639f
[4] https://github.com/flatpak/flatpak/commit/5b21a5b7
The collection id check that was added leaks if we were able
to read the collection-id, but then it was ignored.
Closes: #2093
Approved by: alexlarsson
Currently if you install from a flatpak bundle that doesn't have a
collection ID set or from a flatpakref file that has the CollectionID
key set to the empty sting, you end up with an invalid configuration on
the origin remote created. This is because the collection_id parameter
of flatpak_dir_create_origin_remote() is set to the empty string, not
NULL, and create_origin_remote_config() then only checks for NULL when
deciding whether to set gpg-verify-summary to true or false. Then
because there's no collection ID configured but gpg-verify-summary is
set to false, you get the error "Can't pull from untrusted non-gpg
verified remote" when trying to pull related refs or update the app.
This commit fixes the bug by checking for the empty string when the
collection ID is read from a bundle or ref file, and collapsing that
into NULL.
Closes: #2081
Approved by: alexlarsson
This is made to let gnome-software enumerate all
running instances and get the same information
about them that flatpak ps provides.
For now, we keep it private. It will become library
api once we open new development
Whenever we forward some error from a lower level dbus call to the
caller of the library we strip the extra gdbus error info via a call
to g_dbus_error_strip_remote_error(). We do this, because callers of
libflatpak has no idea that there were remote calls involved, so they
will not do this themselves.
Closes: #2070
Approved by: alexlarsson
Create a bwrapinfo.json file and tell bubblewrap
to write its 'info' there. For now, this just contains
the child-pid. More may appear over time.
Closes: #2039
Approved by: alexlarsson
Flatpak has API called flatpak_installation_list_remotes_by_type() which
can list dynamic (LAN/USB) remotes that mirror configured remotes in an
installation. It does this by searching them for the appstream/<arch>
ref, such as appstream/x86_64. But Flatpak now supports
appstream2/<arch> as a way to provide the appstream data as uncompressed
XML, and it's possible that a USB created with `flatpak create-usb` (or
a LAN peer) only has the appstream2 ref available for a certain
collection ID. So this commit changes
list_remotes_for_configured_remote() so that it looks for both
appstream/<arch> and appstream2/<arch>, which makes
flatpak_installation_list_remotes_by_type() robust to that scenario.
Currently, we only remove stale instance directories
when a new instance ID is allocated. A future 'flatpak ps'
command will want to remove stale instances before
enumerating them, so make this function available.
Closes: #2023
Approved by: alexlarsson
Store the pid of the bwrap process which gets spawned or exec'ed
by flatpak inside the instance directory. This can be useful
for others, such as gnome-software, or a future 'flatpak ps'
command.
We write the pid to a file named 'pid'. It will get cleaned
up together with the instance directory.
Closes: #2023
Approved by: alexlarsson
The information in this file is of interest to other
users outside the sandbox, like gnome-software, or
a possible future 'flatpak ps' command.
We use the already existing instance directory, and
put the file at /run/user/$UID/.flatpak/$INSTANCE/info
The existing logic for cleaning up instance directories
will clean up the file.
Closes: #2023
Approved by: alexlarsson
I've inferred this by walking through the code, which ultimately calls
one of flatpak_build_[app|runtime]_ref() which both implement these
defaults.
Closes: #1995
Approved by: alexlarsson
Without this, it's not safe to use 'pref': if there are no slashes in
'ref', 'pref == 0x1', and any attempt to dereference it later in the
function will crash.
Closes: #1995
Approved by: alexlarsson
Without explicit annotation, all optional parameters are assumed to be
mandatory, and 'const gchar **locales' is assumed to be a scalar string
input parameter (rather than an array or an in/out) for some reason.
Closes: #1995
Approved by: alexlarsson
If no installation path is specified at construct time, or if it doesn't
exist, priv->dir will be NULL even after initable_init() has been
called.
Closes: #1995
Approved by: alexlarsson
