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
Currently the create-usb command reads the subpaths listed in the
flatpak deploy data and just passes those to the ostree pull operation
to copy them to the USB. But this is not the correct way to handle them,
and leads to installs from the USB failing in the case where the locale
is partial (more specifically the install of the main ref succeeds but
the install of the locale extension doesn't).
So this commit changes create-usb to handle subpaths the same way
flatpak_dir_pull() and flatpak_dir_deploy() do, which is to copy the
/metadata path along with a subdirectory of /files for each listed
subpath. So in the case of an English partial locale, /metadata and
/files/en will be copied to the USB drive, and those are the subpaths
that will be pulled during the install (if the installing computer also
uses English).
Closes: #1972
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
In the output of `flatpak build-bundle --help` it's not clear what
LOCATION is, so the least we can do is add an example of its usage to
the man page. At some point it would be nice to also have explanations
of positional arguments in help output.
Closes: #1974
Approved by: alexlarsson
This only fixes the leak when we don't hit an error condition. To fix it
in that case we need an autoptr for deep lists.
Closes: #1966
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.
Add:
* Testing of flatpakrefs and bundles pointing to OCI remotes
* Changing a remote from OCI to non-OCI, including during bundle
installation.
* Pruning origin remotes.
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.
This mirrors ostree commit --disable-fsync and is useful in some cases.
For instance, we'd like to use it when building the temporary import
repositories in flathub.
Closes: #1951
Approved by: alexlarsson
Now that appstream data and icons are retrievded from the index, the OCI
code is expected to be fully usable, and to work with registries as they
will actually be deployed.
Closes: #1910
Approved by: alexlarsson
We previously made a separate request to the registry index to see if
the manifest hash of an image was the hash of the image in the registry.
Since the summary is now downloaded by the system helper and trusted, just
check if the hash matches the hash in the summary data. This is as good,
and in is a lot more efficient if the index is statically generated,
and we can't get the index data for just one image.
Closes: #1910
Approved by: alexlarsson
The OCI index information should be highly compressable (especially if
icons are remote URI's rather than data URI's) so downloading it and
storing it compressed will provide sigificant efficiency gains.
Closes: #1910
Approved by: alexlarsson
Add a new flag for flatpak_cache_http_uri() that adds Accept-Encoding: gzip
to the request, and if the result is returned compressed, stores the data
compressed. If the data result is return uncompressed, it's compressed.
Closes: #1910
Approved by: alexlarsson
Add a new test case to test the OCI remote functionality. The tests talk to
a server that implements good-enough index generation and bits of the
docker registry protocol. Adding and remove remotes, summary and appstream
generation, and image installation are all tested.
Closes: #1910
Approved by: alexlarsson
Checking the registry against a previous etag is now handled inside
flatpak_cache_http_uri(), so remove the etag parameters that were
previously passed around in various places for simplicity.
Closes: #1910
Approved by: alexlarsson
Previously the code assumed that appstream data was stored in a separate
OCI image in the registry. Replace that with storing the appstream data
and icons as image annotations. When we download a new version of the
image index, the appstream data is combined, and icons are downloaded
as necessary.
Since there is no longer a content hash for the appstream data, it's
not practical for the user to download the appstream data and pass it
to the system helper, instead the system helper just downloads the
appstream data directly.
Closes: #1910
Approved by: alexlarsson
