Before 1.8.0 (2016), gpgme used to have two different thread-safe builds,
one for use with POSIX-style pthread and one for use with GNU Portable
Threads (libpth), plus a non-thread-safe version. Since 1.8.0, this
complexity has gone away and there is only libgpgme, which is thread-safe.
In practice this meant that on modern distros since 2016, we would always
fail to detect gpgme via pkg-config and fall back to calling gpgme-config.
Library-specific -config scripts are generally considered problematic
for multiarch, multilib and cross-compiling, and the gpgme-config script
recently disappeared from GPGME's Debian packaging
(see https://bugs.debian.org/1022348 and https://bugs.debian.org/1023601),
so it's better if we can prefer to use pkg-config.
If gpgme >= 1.8.0 is not found, fall back to gpgme-pthread >= 1.1.8,
either discovered via pkg-config or via gpgme-config.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 9b87e4c0d4)
(cherry picked from commit c8f3f0dc1a)
This already happens for installs due to the cleanup path in
`flatpak_dir_deploy_install()`, but it doesn’t happen for other calls to
`flatpak_dir_deploy()`. Notably, during updates of already installed
apps.
Specifically, this means that if an app update is cancelled due to being
blocked by a parental controls policy, the temp deploy dir for that app
(such as
`~/.local/share/flatpak/app/com.corp.App/x86_64/stable/.somehex-XXXXXX`)
will be leaked. It will never be automatically cleaned up, as it’s not
in `/var/tmp` either.
Fix that by using `glnx_mkdtempat()` to create a scoped temporary
directory.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(cherry picked from commit 85a83a06f9 with
minor conflicts)
The history test fails sometimes in the CI due to the remote add
operation being missing from the history command's output:
+ diff history-log -
0a1
> add remote system (history-installation) test-repo
Presumably this is due to that operation happening in the same second
that is passed to --since, so move the sleep statement to make sure a
second passes before we do anything.
(cherry picked from commit 417e3949c0)
There's no need to use polkit in the history command, so don't start the
agent in flatpak-main.c. This means we can avoid a test failure in
test-history.sh which was caused by old versions of valgrind being
unaware of syscall sched_getattr, which is used in g_bus_get_sync(),
itself called by install_polkit_agent().
(cherry picked from commit e6702161da)
Currently we include entries in the output of the history command for
pulls of appstream refs, e.g. "appstream2/x86_64". However since they
don't have an application ID the Application column shows up blank and
it seems like a pull of nothing which is confusing. These are basically
an implementation detail like the temp repo pulls we already exclude, so
I think it makes sense to exclude them from the output.
It would also make sense to exclude pulls of ostree-metadata refs, but
for some reason I don't see those in practice, even with a collection ID
set on the remote.
(cherry picked from commit 72aef63c58)
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
(cherry picked from commit 7b6dba8803)
This checks that the value of the REF field is not an empty string
before calling `flatpak_decomposed_new_from_ref`. Attempting to
decompose an empty string leads to a validation error and prevents
any history from being printed.
Fixes https://github.com/flatpak/flatpak/issues/4121
(cherry picked from commit 0a9253f7d9)
Signed-off-by: Simon McVittie <smcv@collabora.com>
Co-authored-by: Alexander Larsson <alexl@redhat.com>
(cherry picked from commit fab0f8ed7c)
[smcv: Also backport the scaffolding to create this test-case]
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)
This works with newer versions of pyparsing, while producing generated
files common/flatpak-variant{,-impl}-private.h identical to those produced
by the old variant-schema-compiler when using the pyparsing versions in
Debian 10 and Debian 11. Backporting this commit allows older branches
to be CI-tested successfully.
Fixes https://github.com/flatpak/flatpak/issues/4534
(cherry picked from commit 6cb4a2598e)
(cherry picked from commit a0d8a1dcf3)
[smcv: verified that this has no effect with older pyparsing versions]
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)
This was incorrectly looking at errno instead of -r.
Fixes: 0b38b0f0 "run: Handle unknown syscalls as intended"
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 3fc8c67267)
(cherry picked from commit 97e128c2c1)
