This reintroduces the special case that existed in Flatpak 1.12.3, but
under a different name, so that it will be backwards-compatible. With
this change, flatpak-builder will be able to resolve CVE-2022-21682 by
using --filesystem=host:reset.
We want to implement this as a suffix rather than as a new keyword,
because unknown suffixes are ignored with a warning, rather than causing
a fatal error. This means that the new version of flatpak-builder will
be able to run against older versions of flatpak: it will still be
vulnerable to CVE-2022-21682 in that situation, but at least it will run.
Co-authored-by: Alexander Larsson <alexl@redhat.com>
(cherry picked from commit 5709f1aaed)
There are two reasonable interpretations for --nofilesystem=home:
either it revokes a previous --filesystem=home (as in Flatpak 1.12.2 and
older versions), or it completely forbids access to the home directory
(as in Flatpak 1.12.3). Clarify the man pages to indicate that it only
revokes a previous --filesystem=home. This will hopefully reduce
mismatches between the design and what users expect to happen, as
in flatpak#4654.
A subsequent commit will introduce a way to get the Flatpak 1.12.3
behaviour in a way that is more backwards-compatible with Flatpak 1.12.2
and older versions.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 7bbeed2b87)
This caused regressions for some previously-working use cases. For
example, some Flatpak users previously used a global
`flatpak override --nofilesystem=home` or
`flatpak override --nofilesystem=host`, but expected that individual apps
would still be able to have finer-grained filesystem access granted by the
app manifest, such as Zoom's `--filesystem=~/Documents/Zoom:create`. With
the changes in 1.12.3, this no longer has the desired result, because
`--nofilesystem=home` was special-cased to disallow inheriting the
finer-grained `--filesystem`.
This reverts commit 445bddeee6.
This reverts the initial solution to CVE-2022-21682, which we intend to
resolve differently, by introducing a new feature in Flatpak and making
use of it in a new flatpak-builder version.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 917a7f5870)
The new behaviour caused regressions in some situations that previously
worked, and will be reverted.
This reverts commit 4d11f77aa7.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit dfe868d628)
We weren't distinguishing here between overrides that should have been
negated (xdg-documents) and overrides that should not have been negated
(everything else).
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 4e3d1d8b7b)
Previously --nofilesystem=host only removed specifically access to the
`host` permissions, and not necessarily other filesystems (like `home`
or `/some/path`). This isn't very useful to limit access because you
don't know what other filesystems the app may have access too.
We change this to mean that `--nofilesystem=host` removes *all* filesystem
access from the parent layer, and `--nofilesystem=home` removes all
file access to the homedir and paths inside it.
The available layers are, in order:
* app permissions
* overrides
* commandline args
This allows you to start from scratch with the filesystem permissions
in the overrides or the commandline. This is a small change in
behaviour, but not a lot of things use --nofilesystem, and the ones
that do probably expects this behaviour.
(cherry picked from commit e2c8863fb62301cb05c64bbb32b04446e88ce11a)
This tests for invalid metadata, missing xa.metadata and mismatched
values in xa.metadata and the real metadata, including the embedded
null leading to the hidden permissions of CVE-2021-43860.
(cherry picked from commit 2c2ce58c54b3e6c62f9c21c15efa0ba22f4bc09b)
If we have a bundle without metadata we wouldn't properly present
the permissions in the transaction.
(cherry picked from commit b250541302187ff2209b0bb1295e8223d0af860f)
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.
(cherry picked from commit f0f3a35f404b5bd533186095db055f8b3d135576)
If we fail to parse xa.metadata from the summary cache or the commit
xa.metadata we fail the resolve.
If xa.metadata is missing in the commit we fail the resolve (it is
always set in the summary cache, because summary update converts
missing xa.metadata to "", so we either get that, or cache miss which
leads to resolving from the commit.
This means that op->resolved_metadata is always set during install and
updates, which means we will show the app permissions. The transaction
will also always make sure that this data actually matches what gets
deployed.
Before this change an invalid metadata in the summary cache could lead
to a NULL resolved_metadata, which means we wouldn't print the app
permissions, yet we would still deploy some metadata file that could
have permissions. (NOTE: It would fail to deploy unless the
xa.metadata in the commit matched the metadata file, but in this
corner case we would't compare the summary and commit metadata, so
they may differ.)
(cherry picked from commit 5036bca4214d5b77e884dec42e36496a06e74081)
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>
(cherry picked from commit c9c3a667c09a846c0b230cf1cc8ed330028aa03c)
Commits that are found to have missing or invalid objects need to be
marked partial so that when the thing referencing them is reinstalled,
the missing objects will be pulled. libostree treats non-partial commits
as complete even if they're not, since verifying their completeness is
an expensive operation.
This exactly mirrors what the "ostree fsck" command does when it finds
corruption in a commit.
This fix is especially important because corrupt repos have been an
issue lately so we at least need repair to work properly.
Relatedly, delete invalid commit objects to ensure they are
re-downloaded, though it's not clear that code path is almost ever
reachable.
Fixes https://github.com/flatpak/flatpak/issues/4618
(cherry picked from commit 6fac58a9b9)
The man page states that the --all option for the list command includes
runtime extensions (e.g. that end in .Locale or .Debug) and this is the
case. When --all is omitted, we only show such extensions when the thing
they extend is not already in the list. However when you run a command
like "flatpak list --runtime --columns=application,branch", you get a
list that excludes runtime locale extensions but includes app locale
extensions, since the corresponding apps are not in the list despite
presumably being installed. This doesn't seem like the right behavior,
so tweak the logic so that app locale extensions are excluded when --all
is omitted and --runtime is used.
Strictly speaking the "extension-of" information is not guaranteed to be
present in the deploy data (which acquires it from the metadata), but in
practice it seems to be present for all but Sources extensions, and I
think it should be considered required since we are already using it to
implement functionality elsewhere in Flatpak:
https://github.com/flatpak/flatpak/issues/4585
(cherry picked from commit 470b321c63)
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
(cherry picked from commit 6f5bb3597e)
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
(cherry picked from commit 9dbd265cdd)
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
(cherry picked from commit 49d9052d22)
(only merge conflicts in tests/testlibrary.c)
Currently if the user specifies a ref to install that has been renamed
via the end-of-life-rebased mechanism, for example "flatpak install
com.visualstudio.code.oss", Flatpak erroneously tries to install both
the old and new versions of the app. This happens because the code
handling end-of-life-rebase conditions is written assuming the rebased
app is being updated rather than installed for the first time.
Specifically, in FlatpakCliTransaction and FlatpakQuietTransaction, in
end_of_lifed_with_rebase(), we treat a failure of
flatpak_transaction_add_uninstall() as fatal and return FALSE from the
signal handler, which means that the install operation that triggered
the signal will not be skipped (see the docs for
FlatpakTransaction::end-of-lifed-with-rebase).
So, instead check for the FLATPAK_ERROR_NOT_INSTALLED error code and
ignore it, so that the installation of the old version of the renamed
app will be properly cancelled.
Fixes https://github.com/flatpak/flatpak/issues/3754
(cherry picked from commit 3aa9a7f3a1)
The original commit (9865ed8989) disabling
it claimed it fixed OCI downloads. This no longer seems to be a problem.
This has also exposed new bugs as some servers will send
gzip compressed data when the client does not send Accept-Encoding.
If we leave this enabled that issue goes away.
(cherry picked from commit cda4967a9e)
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).
(cherry picked from commit f3214c59d2)
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.
(cherry picked from commit 7f3556d92c)
Currently the output produced when assert_remote_in_installation() or
assert_remote_not_in_installation() fails is not helpful: it doesn't
mention the remote name or where the assertion was called from. Fix
those problems by rewriting it as a #define.
(cherry picked from commit dd48e78652)
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
(cherry picked from commit 6d74eec0a9)
This fixes a few issues with the unit test logs that make them ugly:
1. Currently some lines of output from a command will appear after the
line from xtrace which has the next command, since the command was
printing to stdout and xtrace uses stderr. E.g. "Installation complete."
will appear after "+ flatpak --user install -y ..." but it is from the
previous install command.
2. Lines of output have many spaces after them to pad them to the table
width but this is not needed for non-fancy output.
3. Lines of output are mixed with output from httpd since they don't end
with a newline character, e.g. "Installing… ▊
4%127.0.0.1 - - [16/Nov/2021 00:18:24] "GET /..."
(cherry picked from commit 388c23cfc5)
flatpak_fancy_output() determines whether the output we write is
intended for e.g. a tty or e.g. a log file, the latter being "not
fancy". Currently we write carriage return characters in the not fancy
case, but change that to new lines, which are interpreted correctly by
editors such as vim (whereas a carriage return shows up as ^M since it
is not the correct newline character on Unixy operating systems).
(cherry picked from commit 86d6918a11)
