In test_transaction_install_local(), we test that the origin remote
created when installing from a local repo doesn't exist before
flatpak_transaction_run() is executed and does exist afterward. However,
the origin remote is created before the transaction is run; see the
flatpak_dir_create_origin_remote() call in
flatpak_transaction_add_ref(). The only reason this discrepancy has not
caused a test failure is that the FlatpakDir object held by the
FlatpakInstallation object is not reloaded when the origin remote is
added (so it's reading an old copy of the repo config). This issue will
be fixed in the commit following this one.
We rely on broadcast signals for authenticator replies rather than unicast
as these are not filtered by the sandbox (due to them being opt-in by the
receiver).
Actually this already worked fine in the flatpak side as the generated
code already subscribes to the signals, this just switches the internal
authenticators (test and oci) to using the new way to emit signals.
This is a slightly incompatible change, as we now only support
oci images generated with (what was before) build-export --oci-use-labels.
However, there are not a lot of OCI implementations in the wild, and
we can modify the ones in use to ensure there are labels (and
annotations if needed for older flatpak clients).
This also removes the --oci-use-label option from build-bundle --oci as
this is now the default.
This adds the remote uri, and the per-ref commit id, as well
as extensible per-ref and per-request dicts we can add stuff to
as needed.
These will be used for the OCI case.
2ebf672866 introduced special handling to
mark exported GNOME Shell search provider .ini files as disabled by
default. This functionality was not previously tested.
This allows the authenticator to handle each token type differently.
For example, this allows a "purchase" type to run the donation
webflow, but not require login (and then store the fact that this was
run locally).
This makes it very easy to reuse a single authenticator for several
remotes. This is useful for the a default authenticator implementation
that we can ship with flatpak and use for e.g. flathub.
If request-webflow file exists, then the authenticator will listen
to a local socket and start a webflow request with a uri pointing to it.
If anything connects to the uri it will consider the flow ok and continue.
If the client calls close() instead it will silently succeed anyway
if require-webflow doesn't exists, and fail if is exists.
When we need a bearer token, look up the configured authenticator for
the remote and ask it for tokens. Also updates the test-auth test
with to use the new test authenticator instead of the previous
env var hack.
This is a trivial implementation of org.freedesktop.Flatpak.Authenticator
that just reads the contents of the "required-token" file and returns
that as the tokens for all refs.
Unfortunately we lose some error information when we pull multiple
refs, ending with a generic "something failed" error rather than the
401 error so in the p2p case we can't verify that we get the right
errors.
Mark installed apps to be updatable if an installed in missing
its runtime for some reasons. In pre-FlatpakTransaction world,
an app migration from runtime X to runtime Y would have rendered
an app unusable because runtime Y would not be installed
automatically by clients like gnome-software.
The goal here is that clients like gnome-software can show
those installed apps as updatable again, if such a situation
arises. The FlatpakTransaction API can automatically resolve one of
its ops to install the new runtime, provided we can mark the app
as updatable again at the first place.
While updating, if the related extension is missing on
the installation of an installed ref (could be an app or
runtime), FlatpakTransaction tends to "repair" the ref by
automatically downloading the related extension again and
restoring the overall functionality of the ref.
The related extension concerned that are the ones associated with
`should-download` to TRUE only.
Hence, teach the libflatpak API to do that same, so that clients
like gnome-software can mark those refs as updatable, if their
related extensions is missing.
FlatpakTransaction will automatically download the related ref
(.Locale ref in this case). In case of mentioning previous-ids
in the deploy file, the related ref(.Locale) should be also
be requiring an update.
Hence, flatpak_installation_list_installed_refs_for_update now
will return 2 refs (app and related .Locale extension) to be
updated, instead of 1.
Due to bug #3215 some systems have refs in refs/mirrors/ in addition to
the usual refs/remotes/ location. The remote refs are always at least as
new as the mirror ones since the repo_pull() invocation in
flatpak_dir_pull() which does not use OSTREE_PULL_FLAGS_MIRROR happened
after the one that did. Cleaning up these mirror refs is important since
otherwise when the remote ref is either updated or removed (by an
uninstall) disk space will be leaked since the mirror ref will point to
a no longer needed commit.
So, remove (almost) all mirror refs during flatpak repair, uninstall,
or update operations. And for the uninstall and update operations do it
in FlatpakDir so that it happens regardless of if the CLI of libflatpak
are used.
Also, add a unit test for this.
Fixes https://github.com/flatpak/flatpak/issues/3222
This test was intended to verify that updates from remote B can't
interfere with updates from remote A even if remote B maliciously sets
the same collection ID as remote A. However, the commits intended to
protect against this turned out to have nasty side effects and need to
be reverted.[1] A subsequent commit will revert the use of
OSTREE_REPO_PULL_FLAGS_MIRROR which means this attack is not exploitable
(since refs will be resolved using a refspec which includes the remote
name), at the cost of not supporting more than one remote having the
same collection ID configured. Since we don't support that, it doesn't
make sense to keep this unit test.
Also, the test seems to be failing.
[1] https://github.com/flatpak/flatpak/issues/3215
Also update the tests to use the same format, and make sure to include
coverage of all forms of locale (language-only, with locale, with
codeset, and with modifier).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In order to configure gnome-software to show specific apps in one region
without showing to all language speakers, we allow the storage of full
locales on the extra-languages key. However, these locales are ignored when
calling flatpak_installation_get_default_languages, so locales will be reduced
to their language identifier (eg. en_IN locale will be returned as 'en', and
az_Latn_AZ will be returned as 'az'). In order to get the full locales, we can
call flatpak_installation_get_default_locales instead, which can return languages
and locales.
Adding generated files to foo_SOURCES causes them to be distributed,
even if that was not intended. Use nodist_foo_SOURCES instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
There's no need for this file to be executable. If it was executed,
shells would typically try to execute it as a shell script (because it
isn't an ELF executable and doesn't start with #!), which isn't going
to work.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This ensures that when the operation to install the app completes, the
app is ready to run — rather than having to wait for subsequent
operations to install extensions which the app depends on (such as
content, or locales).
This fits in with the current ordering for *un*installing apps, where
the main app is uninstalled first, followed by its extensions.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://github.com/flatpak/flatpak/issues/3017
Files in the srcdir need to be explicitly prefixed as such in rule
commands. This fixes `make install` when installed-tests are enabled.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than this weird shell loop with a timeout and polling we
move the httpd spawning entirely into the python code, and use
a pipe to synchronize the spawning. This way we can also use
the shell job control to properly clean up any running processes
from the test suite.
Additionally, this adds some (lame) support for token handling in the
test webserver, where you for any file foo can create a foo.need_token
containing a token that is needed for that file.
FlatpakTransaction inherently doesn't differentiate between a
autoupdate and a regular update; both are
FLATPAK_TRANSACTION_OPERATION_UPDATE.
This getter can help differentiate between a regular update
and autoupdate in clients like gnome-software. Autoupdates
work in two separate transaction passes; first that runs with
"no-deploy" and the second pass that deploys all the downloaded
update (i.e. with "no-pull").
