libostree makes heavy use of fd-based I/O, which has the disadvantage
that it is rarely obvious what path an error message is referring to.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we are running a CLI command in the background, then EnsureRepo
might require authorization. Silently skip it if allow_empty was true,
as it is for commands that iterate through all repositories.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, if /var/lib/flatpak didn't exist then we would use the
system helper to create and populate it, but if it existed and was empty,
we could only populate it if we had privileges. This led to errors from
libostree:
Creating repo: mkdirat: Permission denied
The EnsureRepo method call is allowed by default for active local users,
so do this even if allow_empty is true: this will incorporate
/etc/flatpak/remotes.d into the repository, whether it is newly-created
or not. This makes a `flatpak search` work immediately, without having
to fetch metadata explicitly.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Due to previous bugs we were leaving a lot of temp files around
in the appstream deploy dirs, which could add up to using a lot of
space. So, lets find and delete these on updates.
This check only happens on a successful update to a new appstream,
which isn't that often, so the cost of this check is unlikely to be a
problem.
If during appstream deploy there is an error, the temporary files were
not deleted, resulting in leaked files in /var/lib/flatpak/appstream.
Over time these could add up to a significant size. In particular this
happes if several deploys happen in parallel, because then the final
move into place will fail with EEXIST.
This fixes the cleanup of both the temporary directory and the temporary
link on any error.
Fixes https://github.com/flatpak/flatpak/issues/4735
SHA1 hashes are considered weak these days. Some distributions have
static analysis tools to detect the use of such weak hashes, and they
get triggered by flatpak. While this particular use of SHA1 in flatpak
is likely not security sensitive, it's also easy to move to SHA256 to
avoid any debate.
Here, the SHA1 hash of a named remote's filter file is used to generate
the name of the directory where the refs from that remote are cached.
One can reasonably assume that the cache is frequently invalidated
because the list of refs on the remote changes all the time. Hence,
it's not big problem if it gets invalidated once more because of this
change.
This was disables a long time ago because the fedora remotes didn't
contain metadata, but that has been added since then. Requiring fixes
a security concern where an app claims to require no permissions (by
having no metadata in commit) but then actually requires permissions
in the installed app.
In particular, if a null terminator is placed inside the metadata file,
Flatpak will only compare the text *before* it to the value of
xa.metadata, but the full file will be parsed when permissions are set
at runtime. This means that any app can include a null terminator in its
permissions metadata, and Flatpak will only show the user the
permissions *preceding* the terminator during install, but the
permissions *after* the terminator are applied at runtime.
Fixes GHSA-qpjc-vq3c-572j / CVE-2021-43860
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
Previously, the code would rescan the list of refs many, many times.
Now, it only scans once per flatpak_dir_find_local_related_for_metadata
invocation, and it also only parses each refspec once. On my local
system with a large number of refs (>200) installed, this reduces the
time for a `flatpak remove org.freedesktop.Platform//21.08` to start
from ~7s to ~2s.
This does result in dropping an optimization where ostree_repo_list_refs
is already given the ref kind, but IME the overall speed gains are still
worthwhile.
Fixes#4191.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
The history command seems to have been broken since it was changed to
use FlatpakDecomposed, since that type only works for app or runtime
refs, resulting in errors such as:
$ flatpak history
error: appstream2/x86_64 is not application or runtime
Fix this by making the logic a bit smarter, and don't let any one
invalid ref entry prevent the whole command from working.
Fixes#4332
This is another case where commit 4beaa990c seems to have mistakenly
turned an error code path into one where the deploy appears successful
to the caller of flatpak_dir_deploy() but the commit doesn't actually
get deployed.
If an app was created without a files/ directory, which shouldn't happen
with flatpak-builder but could happen if the commit is crafted manually,
currently the install operation exits successfully but the app is not
actually installed. Instead, error out, as we were doing before commit
4beaa990c2.
Currently we verify the checksum of indexed summary files (which have
.sub file names) before writing them to the on-disk cache, so in theory
as long as the disk I/O is successful the data integrity should be
intact when we use it via the flatpak-variant-impl-private.h helpers
generated by variant-schema-compiler. However in practice people
sometimes hit assertion failures which are what you would expect to see
if the data is corrupt, since GVariant stores some metadata such as the
"offset size" toward the end of the data, and if we read this from
serialized user data instead it will obviously be incorrect. In one case
I was able to acquire the flathub.idx, flathub.idx.sig, and
flathub-x86_64-fad08cfb10713e749f02a0e894b5d577b7e9c4931fdf9d2fdc50364c002bc925.sub
files which reproduce one of the assertion failures, and the sub file
appears to be incomplete, like the writing of it was interrupted.
We use g_file_replace_contents() when saving these to the disk, and when
not replacing an existing file that function writes directly to the
final filename, so if interrupted it would be expected to leave an
incomplete file.
This commit changes the summary file handling so that we verify the
checksum of any indexed subsummary again after reading it from disk. If
it doesn't match we delete the on-disk cache and try fetching from the
network.
Fixes#4127
This commit re-works how we automatically "pin" runtimes that are
explicitly installed, to prevent them from being removed automatically.
In this implementation we do the update to the config as part of the
deploy, which has the following advantages:
(1) It ensures that there's never a confusing polkit prompt about
configuring the software installation when the user asked for a runtime
to be installed (https://github.com/flatpak/flatpak/issues/4200)
(2) It means we don't have to rely on the code on the error path of
flatpak_transaction_real_run() to un-pin the runtime in case something
went wrong with the installation, since we pin it almost atomically with
the deploy.
Fixes#4200
On two different code paths we were using the "Title" field in
flatpakref files as the title of a remote, which is incorrect. In most
cases, the remote added via the RuntimeRepo key will be the same as the
remote the app is from, so when the remote is added for the runtime, its
title will be correctly set using the Title value from the flatpakrepo
file and the app will therefore have an origin remote with a title set.
This is not currently true for flatpakref files that use
SuggestRemoteName=, see https://github.com/flatpak/flatpak/pull/4513
For flatpakref files that use a different remote than the RuntimeRepo,
we don't currently have a way for the title to be set automatically;
perhaps we should (https://github.com/flatpak/flatpak/issues/4512).
Fixes https://github.com/flatpak/flatpak/issues/4499
This is similar to what is done for desktop files and allows
applications to use a flatpak's metainfo to retrieve e.g. required
input controllers or the supported screen sizes. Similar to what can be
done for non-flatpak'ed apps by looking at
/usr/share/{metainfo,appdata}.
Since flatpak moves the metadata from metainfo/ to appdata/ during build
we only need to export files from that single directory.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Many of the fields allowed in flatpakrepo files are not allowed in
flatpakref files, e.g. Comment, Description, Homepage, etc. So there is
no straightforward way to ensure those are set correctly when the user
installs something with a flatpakref file. However in most cases the
repo specified by the RuntimeRepo key is also the repo providing the
main ref, so in those cases it makes sense to utilize all the metadata
provided in the flatpakrepo file when creating a remote to provide
updates for the app being installed. We were already doing this when the
SuggestRemoteName key was unset; this commit makes it so that we utilize
that metadata also when SuggestRemoteName is present.
It can happen that a related ref is installed from a different remote
than the thing it's related to. We always want to update things from
their origin remote. However as of now FlatpakTransaction resolves the
commit of a related ref to the one available from the main ref origin,
and later sets the remote for the operation to the installed origin (see
commit 6793d90b8). In case there is a newer commit in the main ref
origin than the installed origin, this leads to an update operation
being erroneously created, only to then error out with an HTTP 404
error, because the commit from the main ref origin is being pulled from
the installed ref origin. For specific steps to reproduce see
https://github.com/flatpak/flatpak/issues/3128#issuecomment-948948040
So, ensure that when a FLATPAK_TRANSACTION_OPERATION_INSTALL_OR_UPDATE
operation is created for something that's installed, whether it's a
related ref or something else, the remote used is always the origin. And
ensure that the remote is set correctly before the stage where the op is
resolved to a commit, to avoid the situation described above. This is
essentially a re-implementation of the fix in commit 6793d90b8.
Also, add a unit test for this behavior.
This commit also makes a few changes to documentation to make it clear
that this related-ref-different-origin situation is possible.
Fixes#3128
This commit is a follow-up to "Fix implementation of xa.noenumerate
remote option" since that turned out to break
flatpak_installation_fetch_remote_ref_sync() in some cases. I didn't see
it at the time, but flatpak_decomposed_get_collection_id() explains that
the collection ID shouldn't be set on FlatpakDecomposed objects, even
when the remote has a collection ID set, unless they are being used to
enumerate refs from a file:// URI rather than a configured remote. So
this commit changes list_remote_refs() and list_all_remote_refs() to
keep the xa.noenumerate implementation working and to get
fetch_remote_ref_sync() working again (since the latter uses
flatpak_decomposed_new_from_parts() and thus doesn't set a collection ID
on the FlatpakDecomposed object used for comparison).
In a recent commit I changed flatpak_dir_list_remote_refs() to make main
refs (xa.main-ref) visible for noenumerate remotes (xa.noenumerate),
meaning that an origin remote created for a flatpakref file can be used
to get information about the ref from the file even before it is
installed. This commit extends that work to include extensions of the
main ref, and updates the unit test to check for this. The reasoning is
that if GNOME Software wants to show the user information about, say,
VLC from a flatpakref file before installing it, Software would want to
also show the available plugins so the user can decide if they want to
install those as well. I haven't checked if Software actually does that;
I'm only focusing on making libflatpak do the right thing.
Currently the xa.noenumerate option on a remote is documented as causing
the remote not to be used when presenting available apps/runtimes or
when searching for dependencies. The idea is that the remote is only
used for providing updates for things installed from it, and this
functionality is used when creating an origin remote for something
installed via a flatpakref file.
However, the implementation of this in flatpak_dir_list_remote_refs() is
buggy. It returns an empty set of refs even if something is both locally
installed and available from the remote. This is because it is using
hash table comparisons of FlatpkDecomposed objects (via
flatpak_decomposed_hash()) which take into account both the ref (or
refspec) and the collection ID, and the local refs' FlatpakDecomposed
objects are created from a refspec whereas the remote refs'
FlatpakDecomposed objects are created from a ref alone. We could fix
this by having them both use refspecs, but it is better to use a
collection-ref tuple for the following reasons:
(1) Changing flatpak_dir_list_all_remote_refs() to use a refspec to
create the FlatpakDecomposed objects would be a breaking change for the
other users of that function.
(2) Both the local and remote refs are from the same remote so we don't
need to use the remote name to disambiguate them, even if no collection
ID is configured.
(3) The whole point of collection IDs is to make refs uniquely
identifiable, so we're using them for the intended purpose.
In addition to fixing this bug, this commit adds a unit test in
testlibrary.c so it stays fixed.
When we create origin remotes for apps installed via .flatpakref files,
we set xa.noenumerate=true and
xa.main-ref=app/com.example.App/arch/branch so that the remote is only
used for the app it was intended for. This is implemented in
flatpak_dir_list_remote_refs() by only listing refs in the remote which
are already installed. This works fine after the ref is installed but in
the short timespan between when the origin remote is created and the app
is installed from it, it means that the remote appears as empty.
The use case where I ran into this is in attempting to use
flatpak_installation_fetch_remote_ref_sync() in the gnome-software
flatpak plugin, in the handling of flatpakref files, which is intended
to just display information to the user and let them decide whether to
install the app. But I was not able to create a FlatpakRemoteRef due to
the behavior described above; see #4453 for more details.
So, change the behavior so that the main ref for an origin remote is
visible even before it is installed. This technically could be a
breaking change for some consumer of libflatpak but that seems very
unlikely, and the new behavior makes more sense.
Also add a unit test for this behavior.
These checks were broken in commit d762a2f, as the commit failed to
consider the fact that `flatpak_dir_check_parental_controls()` is run
both in the `flatpak` CLI process run by the user, but also in the
`flatpak-system-helper` process which always runs as root, and which
handles any installations done on the system repository.
As a result, parental controls were not working for the system
repository.
Fix that by limiting the scope of the check to only pass if running
without the system helper. flatpak calls from root never go through the
system helper.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #4418
g_get_language_names() only returns the language names for the
LC_MESSAGES category, so mixed locale scenarios would result in missing
languages. Now, the languages are listed for each individual category.
Note that this issue was only present with the user installation. For
the system installation, the locales were queried from localed, and all
categories were checked.
In order to work on GLib versions < 2.58, the code to get language
names for a category has been backported.
Fixes#3712.
When flatpak-builder is running under flatpak, its
path will be /app/bin/flatpak. This path must not
be in export scripts or desktop file. This change
makes it possible for flatpak-builder flatpak to
tell flatpak what it should write to generated
files
This allows callers to be checked for mismatches between format string
and arguments, and also means gcc can assume that the format string and
the arguments match up correctly when forwarding them to functions
like g_strdup_vprintf, removing the need to suppress -Wformat-nonliteral
warnings.
Signed-off-by: Simon McVittie <smcv@collabora.com>
It turns out that we can't currently uninstall a ref from a
non-standard arch without specifying the arch even if there is no similar
ref installed for the main arch. (#4264)
The fundamental reason for this that `flatpak_dir_find_installed_ref(s)`
currently only returns refs with standard arches unless you explicitly
specify an arch.
This changes flatpak_dir_find_installed_refs() to always return
all the refs for all installed arches. This is generally what
we want anyway, except in the case of "flatpak run org.some.Platform" where
we don't want to prompt if there are multiple arches installed, so that
is manually changed.
This changes find_matching_ref() to look for refs in all arches, but
always prefer (without prompting) the default arch if that is installed.
This also matches what all current callers want.
Fixes#4264
If looking up the summary for a ref without an arch (for example,
`ostree-metadata`, which the Endless OS version of flatpak uses in some
backwards-compatibility code), avoid passing `NULL` to `strcmp()` and
hence crashing.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
scan-build has a lot of false positives for this codebase because it
doesn't understand __attribute__((__cleanup__)) or GLib's GError
convention, but it seems to have been right about these.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Like $XDG_RUNTIME_DIR/app/$FLATPAK_ID, this is shared between all
instances of the app, except for subsandboxed instances created by
flatpak-spawn --sandbox or equivalent. Unlike
$XDG_RUNTIME_DIR/app/$FLATPAK_ID, it does not exist at an equivalent
path on the host and in the sandboxed app.
Resolves: https://github.com/flatpak/flatpak/issues/4120
Signed-off-by: Simon McVittie <smcv@collabora.com>
If XDG_RUNTIME_DIR is under app control, as it will be with #4120, we
don't want to be mounting pieces of filesystem directly into it, because
that will mean that the app could create a symlink that will cause us
to create a mount point for it at the target of the symlink, potentially
elsewhere in the host filesystem.
Instead, we mount them in /run/flatpak, which is a per-instance
directory entirely controlled by Flatpak; and then create (relative)
symlinks in XDG_RUNTIME_DIR, pointing into /run/flatpak.
In this commit, we still know that the XDG_RUNTIME_DIR is a
per-instance tmpfs, so we can safely create the symlinks using
the --symlink option. In a subsequent commit this will change to
creating them in a shared XDG_RUNTIME_DIR, if any.
Signed-off-by: Simon McVittie <smcv@collabora.com>
