Some remote metadata can cause changes to the local configuration for a
remote, but Flatpak is not properly reloading the new config after
making changes. Specifically in flatpak_transaction_update_metadata() we
call flatpak_dir_update_remote_configuration() for each remote and then
try to reload the configuration by calling flatpak_dir_recreate_repo().
The problem is that while this reloads the config instance stored by the
repo member of the FlatpakDir, the FlatpakTransaction object still has
FlatpakRemoteState objects stored which were initialized from the old
config.
A consequence of this is that if a remote repository has the
"ostree.deploy-collection-id" key set in its metadata, the next
install/update operation from that remote will fail with the error
message "Can't pull from untrusted non-gpg verified remote", and then
subsequent operations will succeed. This is because during the first
operation Flatpak will add the collection ID to the local configuration
in flatpak_transaction_update_metadata() but then in
flatpak_dir_install() the outdated FlatpakRemoteState object will be
used which still has no collection ID.
So this commit frees all the stored FlatpakRemoteState objects on the
transaction, so they will be recreated when they're needed (based on the
new config).
Closes: #2243
Approved by: alexlarsson
(cherry picked from commit ce78f52fcc)
Currently, if flatpak_installed_ref_get_latest_commit() returns NULL
(which means the ref doesn't exist in the local repo) we assume any
remote commit could be an update in
flatpak_installation_list_installed_refs_for_update() when a collection
ID is not configured on the remote. When a collection ID is configured,
if get_latest_commit() returns NULL it causes a crash in
ostree_repo_load_commit(). So this commit prevents the crash and makes
the behavior in the post-collection-id world consistent with the
behavior in the pre-collection-id world.
It's difficult to write a test for this that's not contrived, without
knowing what circumstances led to the disappearance of the ref from the
repo.
Fixes https://github.com/flatpak/flatpak/issues/2216Closes: #2229
Approved by: alexlarsson
(cherry picked from commit 6b4402b60e)
In version 0.99.1 (065053775b) flatpak
stopped inheriting permissions from the runtime, because that made
the story about application permissions way to complicated. What
we want is to have a static set of permissions for the app that
is frozen at install time.
However, inheriting permissions from the runtime makes a lot of sense
as certain permissions are required from the runtime, in particular this
is used by the kde runtime to read the kdeglobals file, etc.
So, to combine the best of the two worlds, we now do inherit permissions,
but at build-time (and you can disable it if you want). This way
kde apps don't have to repeat themselves, but we still get static
application permissions.
Closes: #2230
Approved by: alexlarsson
(cherry picked from commit 99fbbc25c6)
This exposes a /etc/timezone with the current timezone, as per the old
debian spec: https://wiki.debian.org/TimeZoneChanges
In case we're using the session-helper this will be extracted from
the host config and applied whenever that changes.
Normally timezone info is specified by /etc/localtime being a symlink
into the locale data, and you can look at the symlink value itself.
However, in the sandbox we can't update a symlink in /etc at runtime,
nor can we make it of the canonical form as that would point into the
runtime. This is why /etc/timezone is used.
This fixes https://github.com/flatpak/flatpak/issues/2190Closes: #2214
Approved by: alexlarsson
(cherry picked from commit 0b6844f39e)
flatpak_installation_modify_remote was not saving the nodeps
state. Found while writing FlatpakTransaction tests.
Closes: #2198
Approved by: alexlarsson
(cherry picked from commit de56d34104)
This was found while writing transaction tests.
We were passing error, but trying to use the local_error
message.
Closes: #2198
Approved by: alexlarsson
(cherry picked from commit adf896d794)
We were emitting the ::operation-done signal with
different arguments than declared for the signal.
This showed up as test failure when comparing
the result argument.
Closes: #2187
Approved by: alexlarsson
(cherry picked from commit 3f0eb7e481)
Instead of FLATPAK_ERROR_ABORTED, return G_IO_ERROR_CANCELLED when the
passed in GCancellable gets cancelled. This makes it possible to cancel
updates in gnome-software without getting a generic "Aborted due to
failure" error popup.
Closes: #2178
Approved by: alexlarsson
--device=all really means the device nodes, we should not expose the host
shared memory objects.
This change incidentally fixes issues with --device=all on debian (#2136)
where /dev/shm is a symlink to /run/shm, which doesn't exist in the sandbox.
Closes: #2160
Approved by: alexlarsson
These days we don't really need xattrs for the tests to run,
so move the test runs to /tmp, which brings down make check time
from 5 to 3.5 minutes on my machine.
Closes: #2170
Approved by: alexlarsson
Several tests have alternative wrappers that just set some feature
flags. For instance to switch between user and system and with or
without deltas. This change makes those wrappers automatically
generated from a simple description of the features.
For example the test-run.sh test goes from:
- tests/test-run.sh \
- tests/test-run-system.sh \
- tests/test-run-deltas.sh \
- tests/test-run-system-deltas.sh \
to
+ tests/test-run.sh{{user+system},{nodeltas+deltas}} \
There is some complexity here because the TESTS variable in automake
can't be runtime generated, so we rewrite it during "make
update-test-matrix" and commit the result to git.
The way it works is that make update-test-matrix takes the
TEST_MATRIX_SOURCE list, passes it to tests/expand-test-matrix.sh
which generates all the combinations in tests/Makefile-test-matrix.am.inc
where a test like tests/test-foo.sh{user+system} will get
converted to tests/test-foo.sh@user.wrap and tests/test-foo.sh@system.wrap.
We then have a pattern rule matchin tests/*.wrap which will generate
a wrapper that sets the right environment flags based on $0 and then
spawns the wrapper.
Closes: #2170
Approved by: alexlarsson
This commit removes the call to flatpak_dir_update_summary() in the
create-usb implementation. It turns out that libostree does not rely on
a summary being present when a pull is local (meaning it uses a file://
URI). I'm not sure where I got the idea that create-usb depends on a
summary in the source repo. I went back to the first commit that
introduced the "ostree create-usb" command and even using that a summary
isn't required, so it seems unlikely that this changed recently.
One important benefit of removing the summary update is that currently
summary generation takes an exclusive lock, and we've seen on Endless
the attempt to acquire that lock time out (possibly due to a prune
happening in another process).
We could also remove the system-helper method UpdateSummary since it
doesn't have any users after this commit, but maybe someone will need it
in the future, and technically removing it would be an API break.
Closes: #2166
Approved by: alexlarsson
It is not really nice to have g_warnings pop out of
the library left and right, they should be replaced
by proper errors as far as possible. This is a small
start.
Closes: #2150
Approved by: alexlarsson
Add FLATPAK_ERROR_INVALID_DATA and use if for cases where
the incoming data for an update or install is faulty, and
add FLATPAK_ERROR_UNTRUSTED, FLATPAK_ERROR_SETUP_FAILED and
FLATPAK_ERROR_EXPORT_FAILED to cover more error conditions.
Closes: #2150
Approved by: alexlarsson
flatpak_fail is a convenient shortcut, but falls short
for actual error reporting. Use proper G_OPTION_ERROR
error codes here.
Closes: #2150
Approved by: alexlarsson
It may be an unlikely case, but if the same app
is installed in multiple installations, there was
no way to select which one to run, so far.
Closes: #2146Closes: #2158
Approved by: alexlarsson
flatpak_find_deploy_for_ref_in is a variation of
flatpak_find_deploy_for_ref that allows to restrict
what installations to search in.
Closes: #2158
Approved by: alexlarsson
The code was looking for a ref with the name
ostree-metadata, but using an api that falls
back to remote refs with the same name, which
is not desirable here.
Use a different ostree api instead that only
resolves local refs.
Closes: #1805Closes: #2157
Approved by: alexlarsson
