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
This reverts commit ed1d7eacf4 and fixes
the issue in a different way.
With the introduction of peer (LAN/USB) sources of refs comes a problem:
they may have outdated repository metadata (which is stored as
contentless commits on the branch "ostree-metadata"). Currently Flatpak
allows the older metadata to be pulled into the local repo, but this is
undesirable for a few reasons: it hurts the security properties of the
system because for example the GPG keys might have been rotated and you
don't want to go back to using the old ones, and it's undesirable
because the old metadata might have missing or wrong information about
the apps installed on the system.
So this commit makes Flatpak ignore the downgrade and use the newer
metadata for the offline operation. This is not a perfect solution,
because the newer metadata might have information (such as the download
size or needed runtime) that's not accurate for the old versions of the
refs that are available offline. This issue is significantly mitigated
by the fact that FlatpakTransaction operations use commit metadata to
make decisions, rather than depending on the xa.cache.
Another possible solution would be to read the outdated metadata into
the FlatpakRemoteState object without pulling it into the local repo or
using it to update the remote config, but that's not perfect either
because there's no guarantee you'll pull the metadata from the same
source as the refs (perhaps one comes from a USB drive and the other
from a LAN peer). Longer term, we should figure out how to rely less on
the xa.cache (which is stored in ostree-metadata) or otherwise make
architectural changes to solve those issues. For now, I think this fix
will be enough to make USB updates usable and secure.
Fixes https://github.com/flatpak/flatpak/issues/1473Closes: #1965
Approved by: alexlarsson
This will allow us to return anything in the FlatpakError domain using
g_dbus_method_invocation_return_gerror().
Closes: #1965
Approved by: alexlarsson
This commit fixes the handling of errors from installing/updating
related refs during a transaction, so that they're treated as non-fatal,
and so that the operation is skipped if the primary operation fails. The
current behavior is that a failure to install/update a related ref
causes the whole transaction to fail, and even after a failure to
install/update the primary ref the related ref install/update is
attempted.
I hit this error when doing an offline USB app install, when the USB
repo has an older version of the runtime and the runtime's locale
extension than what's in the local repo. Without this commit, the
failure to update the runtime (due to it being a downgrade) is treated
as a warning, but the failure to update the runtime locale is treated as
an error. With this commit, the runtime update failure is still treated
as a warning, and the locale update is not attempted. This is better
behavior because the locale extension update (or even install) is not
critical to the app install.
Closes: #1979
Approved by: alexlarsson
In https://github.com/flatpak/flatpak/pull/1689 we were meant to
have limited the receiving of broadcasts on portals, but die to a
bug in the proxy we accidentally allowed all broadcasts anyway.
The change which ignores all applied filters < POLICY_TALK fixes that.
However, it also turns out that the desktop portal actually *does*
rely on signals. For example the network portal uses property change
notification.
So, to make sure this works we allow all signal from the portal
names, but only if they are on a object path starting under
/org/freedesktop/portal (which incidentally all portal object are).
This means there is no real change in anything that is currently
deployed, but it does allow portals to opt out of this global signal
visiblity if they want by using a different object path, which we
want to use in dconf.
Closes: #1976
Approved by: alexlarsson
This commit fixes a regression that causes installing from a bundle to
fail if the bundled app's runtime was itself installed from a bundle, or
otherwise has a non-working remote (such as when the user is offline).
The fix is to treat a failure of flatpak_dir_find_latest_rev() as
non-fatal in resolve_ops() if the ref in question is already installed.
In other words, if we don't need to fetch a ref for the transaction to
succeed, errors in fetching remote info about the ref shouldn't be
fatal.
Closes: #1973
Approved by: alexlarsson
When I run `flatpak update` I get messages saying "Warning: No
xa.metadata in commit" which isn't very helpful without knowing what
commit is being referred to. So this commit adds the checksum and ref to
such error messages.
Closes: #1978
Approved by: alexlarsson
It's a good idea to NULL initialize g_autoptr/g_autofree variables, so
we can be sure uninitialized memory isn't passed to g_free or similar.
Closes: #1968
Approved by: alexlarsson
Sometimes (for example in some test-repo-collections.sh test that broke) we
update from a remote with an older ostree-metadata branch, and the
check for downgrades broke in this case.
Its unclear exactly what it the best solution here, maybe to silently
disallow the update. However, this change instead just re-allows the
downgrade for this particular case so we get the old behaviour.
When we switch the remote type, we need to clean up cached files
(appstream, OCI index/summary) because they are stored differently
for the two types of remote.
The old pattern of using a separate 'OCI' flag was very ugly
internally in the code once it was extended to flatpak bundles and
flatpakrefs - using a different URI scheme means that the nature
of the remote can't be accidentally lost in some part of the code.
Probing would be possible as well, but would make it difficult to
add a remote when offline, and also doesn't deal well with the
fact that our data layout is different for the two types of remotes -
the type of remote could change at any point!
As a side effect this change enables flatpakrefs and flatpak bundles for OCI
registries.
* Restrict the queried images to the desired architecture
* Sort query parameters as the spec requests
* Allow a fragment on the remote URI to mean "tag to query for
in the registry"
* Tweak flatpak_oci_index_ensure_cached() not to return the
index URL in the normal error case.
The normal behavior where we only list already installed refs for
a noenumerate remote doesn't work for the case where flatpak-system-helper
verifies a ref on an OCI server during installation - in that case, the
ref being installed to does not *yet* exist locally.
In general Flatpak tries to prevent downgrades of anything: apps,
runtimes, repo metadata, etc. with some exceptions such as when the user
specifies a commit they want. However at the moment the detection of a
downgrade is broken if both of the following are true: (1) a collection
ID is enabled on the relevant remote, and (2) a per-user installation
is being used instead of the system-wide one (or the system-helper is
otherwise being circumvented, such as by running flatpak as root).
This bug is a security vulnerability, but it's one with limited impact
because very few people have collection IDs enabled yet, and the
downgrade attack would require either a MITM on the network connection
(which HTTPS should prevent) or a malicious USB drive or local network
peer.
