[pull] master from flatpak:master #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Signed-off-by: Simon McVittie <[email protected]>
This MR switches to GitHub forms to improve user experience when opening an issue. It includes a bug template and a feature request template.
Signed-off-by: Simon McVittie <[email protected]>
Signed-off-by: Simon McVittie <[email protected]>
flatpak 1.12.2 Git-EVTag-v0-SHA512: 5e6e119c2d8f39bdbc55735a5819235de430712a049793b1a64a94bcd2a8a7a7ade5dedaf5098c51b25366cf0d3b3029302cc8f8b42821f76b6db493142ac7ea
Switch to GitHub forms
While building on gcc 9.3.0
Fix some warn_unused_result warnings
g_key_file_get_boolean() only accepts lower case "true" and "false", so correct some instances of "False" in key files. This makes no functional difference as long as the error pointer isn't checked since g_key_file_get_boolean() also returns false when it can't parse the value as a boolean. But it still seems good to be correct, and someone could interpret the existence of "IsRuntime=False" as implying that "IsRuntime=True" will work, which it doesn't.
a99b748 introduced an environment variable for changing the flatpak path for exports. On NixOS, we do not have a stable path we could use so we used to patch Flatpak to use `flatpak` program from `PATH`. With the recent change, we drop our downstream patch in favour of setting the environment variable to `flatpak` but the tests do not expect that. This is the test part of our former downstream patch so that tests can pass with exports using `flatpak` instead of an absolute path. It still expects the binary path to end with `flatpak` so arbitrary `$FLATPAK_BINARY` will not work but we do not pass the environment variable to tests so we cannot do much better.
…ster Update Polish translation 211017 for the main branch
…12.x Update Polish translation 211017 for flatpak-1.12.x
tests: Allow FLATPAK_BINARY=flatpak for exports
...instead of the app we're building arch.
Files that are generated manually by a maintainer and committed to git should be in the srcdir, not the builddir. Signed-off-by: Simon McVittie <[email protected]>
Per the documentation, g_assert_null() is meant for unit tests.
This will make the next commit simpler, and in my opinion this makes the code more readable.
It's easier to reason about the tests if they don't leave state behind.
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.
This would have been helpful in my work on #4453
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.
Signed-off-by: Simon McVittie <[email protected]> Co-authored-by: Alexander Larsson <[email protected]>
The new behaviour caused regressions in some situations that previously worked, and will be reverted. This reverts commit 4d11f77. Signed-off-by: Simon McVittie <[email protected]> (cherry picked from commit dfe868d)
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 445bdde. 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 <[email protected]> (cherry picked from commit 917a7f5)
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 #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 <[email protected]> (cherry picked from commit 7bbeed2)
Signed-off-by: Simon McVittie <[email protected]> (cherry picked from commit 813e1f0)
This was added as part of implementing the :reset suffix. Signed-off-by: Simon McVittie <[email protected]> (cherry picked from commit ab0169e)
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 <[email protected]> (cherry picked from commit 5709f1a)
Signed-off-by: Simon McVittie <[email protected]> Co-authored-by: Alexander Larsson <[email protected]> (cherry picked from commit f3d12dc)
Signed-off-by: Simon McVittie <[email protected]> Co-authored-by: Alexander Larsson <[email protected]> (cherry picked from commit fab0f8e)
Signed-off-by: Simon McVittie <[email protected]> Co-authored-by: Alexander Larsson <[email protected]> (cherry picked from commit 4aa70d2)
At the time we wrote the NEWS for 1.12.3, this CVE ID had not yet been issued. Signed-off-by: Simon McVittie <[email protected]>
Signed-off-by: Simon McVittie <[email protected]>
Signed-off-by: Simon McVittie <[email protected]>
Signed-off-by: Simon McVittie <[email protected]>
Signed-off-by: Simon McVittie <[email protected]>
When generating flattened permissions (i.e. for --show-permissions or for the /.flatpak-info file) we're currently flattening the permissions i.e. don't show things that would only affect layering the permissions). However, the code doesn't currently do this for the filesystem key, so implement that. This means we only display the permissions that are in effect, and don't display "negative" permissions like !host which are not meaningful in this context.
This is useful for extensions that apply to specific hardware.
This complements `flatpak_transaction_set_no_interaction()` and allows calling code to see if a given transaction is interactive. Signed-off-by: Philip Withnall <[email protected]>
This bundles up `{get,set}_no_interaction()` in a way which can be bound
or exposed to bindings.
Signed-off-by: Philip Withnall <[email protected]>
Remove a redundant `PROP_0` member and add a type for the property IDs so that the `switch` cases can be checked by `-Wswitch-enum`. Signed-off-by: Philip Withnall <[email protected]>
which(1) is not standardized by POSIX, and has different implementations and behaviour on different distributions. The behaviour and exit status of command -v is standardized by POSIX. Signed-off-by: Simon McVittie <[email protected]>
In the unlikely event that one of these paths contains spaces or other special characters, we don't want to field splitting to take place. Signed-off-by: Simon McVittie <[email protected]>
which(1) is not standardized by POSIX, and has different implementations and behaviour on different distributions. The behaviour and exit status of command -v is standardized by POSIX, and in particular, checking its exit status is an appropriate way to ask: if I called this command, would it be found? Signed-off-by: Simon McVittie <[email protected]>
which(1) is neither standardized by POSIX nor built-in to bash, and has different implementations and behaviour on different distributions. command -v is standardized by POSIX, but it won't return the path to an executable if the same command is available as a shell builtin, so it isn't necessarily suitable here either. The Flatpak test suite uses bash scripts rather than POSIX shell scripts, so we can safely make use of bash-specific options for builtins, and in particular type -P, which has the semantics we want here: search PATH, even if there is a shell builtin of the same name. Signed-off-by: Simon McVittie <[email protected]>
…ewrap Signed-off-by: Simon McVittie <[email protected]>
Trying to run sandboxed GStreamer applications from within jhbuild, for example, would make those applications fail to find their plugins. $ LANG=C flatpak run org.gnome.Totem.Devel ** (totem:2): WARNING **: 19:32:06.406: Element 'gtkglsink' is missing, verify your installation ** (totem:2): WARNING **: 19:32:06.406: Element 'glsinkbin' is missing, verify your installation Don't propagate those GStreamer environment variables to within the sandbox to avoid that problem. See https://gitlab.gnome.org/GNOME/totem/-/issues/504
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )