Comparing the code in flatpak-utils.c:progress_cb,
we need to set bytes-transferred for the total amount
of data that has been transferred so far. The value
we were setting so far, fetched-delta-part-size, refers
to the size of the objects we already have locally, and
is subtracted from the total, which explains oci progress
running backwards.
Closes: #2392Closes: #2400
Approved by: matthiasclasen
This means we pick up the built services. Also we set
FLATPAK_SYSTEM_HELPER_ON_SESSION so that the system-helper
runs on the session-bus just like in libtest.sh.
Closes: #2397
Approved by: matthiasclasen
GVariant doesn't take it lightly when you are trying to extract
an ay value with an s format. This was causing critical warnings.
Closes: #2393
Approved by: alexlarsson
Currently the update command only checks the default system and user
installations (unless overridden by a command line flag). This commit
makes it check custom installations as well, so they are not left out.
Care is taken so that an empty or broken installation doesn't cause the
whole update operation to fail.
Fixes https://github.com/flatpak/flatpak/issues/2006Closes: #2345
Approved by: matthiasclasen
Some commands depend on the first directory in the list returned by
flatpak_option_context_parse() being the default system directory, which
is true for FLATPAK_BUILTIN_FLAG_STANDARD_DIRS. This commit makes the
system directory first for FLATPAK_BUILTIN_FLAG_ALL_DIRS as well, in
case any code in the future uses that flag in combination with that
assumption.
There is one user of the ALL_DIRS flag that actually wants to keep the
user directory first in the list, the run command. This is so that a
user-installed app will be run even if the same app is installed
system-wide. So this commit modifies the run command to undo this
change after calling flatpak_option_context_parse().
Closes: #2345
Approved by: matthiasclasen
This lets us respect the fancy output setting, and
it lets us do some other things that make it better
integrated.
Closes: #2379
Approved by: alexlarsson
Arrange for progress to be done before we
ask for polkit auth, so we don't end up with
the text prompt mushed into the progress display.
Closes: #2379
Approved by: alexlarsson
Install a polkit text agent that can ask for
authorization when we are on the console.
This brings us closer to best practice for polkit use.
Closes: #2379
Approved by: alexlarsson
There was a bunch of handle methods which forgot to do
this manually, so call the flatpak_dir_set_source_pid()
method right when we create the FlatpakDir object.
Closes: #2384
Approved by: alexlarsson
gtk-doc complains if parameter names don't match between
headers and doc comments, so make them match, for a quieter build.
Closes: #2384
Approved by: alexlarsson
The Deploy method takes an 'update' flag from the caller
and picked the permission to check based on that, which
is not safe. Instead, we can check ourselves if the ref
we are given is already installed (in which case it is
an update, or a reinstall).
After this change, the update flag is ignored by the
system helper.
Closes: #2384
Approved by: alexlarsson
I realized that these messages are a bit confusing, with
keep permissions and implications. We end up asking a
question about one ref, but then use the permission we optained
to operate on other refs. This will get a bit worse with
the new hints, so go back to more generic messages that
don't talk about the details. The ultimate goal here is
less messages, anyway.
Closes: #2384
Approved by: alexlarsson
This is to avoid multiple polkit dialogs, regardless
of transaction ordering.
FlatpakTransaction calculates the 'strongest' op it has,
and passes the hints accordingly. FlatpakInstallation
doesn't pass hints, since it does individual operations.
The system helper uses the hints to determine which PolicyKit
permission to request. Since the policy typically has 'keep'
set, this mean that the following operations in the same
transaction will be able to reuse the permission obtained
for the first one.
Closes: #2384
Approved by: alexlarsson
Add flag that instructs the session-helper to kill
the spawned command when the caller drops off the bus.
Closes: #2326Closes: #2365
Approved by: alexlarsson
Allow to mark a FlatpakInstallation as no-interaction, which
will get passed to the system helper to prevent it from presenting
polkit dialogs.
We make this a property on the object, since not all relevant
methods have flags that would let us pass this information.
Closes: #2367
Approved by: alexlarsson
Allow to mark a FlatpakDir as no-interaction, which will
get passed to the system helper to prevent it from presenting
polkit dialogs.
We make this a property on the object since the alternative
would require plumbing the flag through tons of API all over
the code.
Closes: #2367
Approved by: alexlarsson
Add a new 'no-interaction' flag to all system-helper methods
that have flags, and don't allow polkit user interaction if
it is set. This will let tools like GNOME Software do automatic
updates in the background without interrupting the user with dialogs.
For methods that don't have flags, we always allow user interaction.
Closes: #2367
Approved by: alexlarsson
We were relying on the order of string lists obtained
from a keyfile. But the way the keyfile is constructed
involved iterating of hash tables, which doesn't guarantee
order.
This was causing test failures with GLib master.
Closes: #2375
Approved by: matthiasclasen
Rename permission-list and document-list to
permissions and documents, for consistency with
how we handle remotes. The old command names
are kept as hidden aliases.
Closes: #2131Closes: #2366
Approved by: mwleeds
Some methods were missing a flags argument. This
will be a problem in the future, when we want to
pass a no-interaction flag to all methods. Therefore,
add an empty flags enum for every method that is lacking
one now.
This is an api change for the system-helper interface.
Closes: #2370
Approved by: alexlarsson
Currently if you don't specify a remote to the install command, it might
suggest that you use an origin remote like "org.gnome.Builder-origin"
which doesn't make much sense since those are tightly tied to the app
installed via bundle that created them. So this commit respects the
"xa.noenumerate" flag that is set on such remotes, so they aren't
searched for refs.
Closes: #2376
Approved by: matthiasclasen
The OCI support relies on downloading a json index and converting it
to a ostree-style summary, which we the use in all sorts of operations
in the client code. Currently this happens in the user code, which means
that it will fail (due to permissions) in the system installation case.
We could do the conversion as the user, but when eventually installing
something the system-helper will anyway do this download and
conversion, so that would only double the work and risk things going out
of sync. Also, the OCI index is not gpg signed, so we can't realy on
downloads done as the user.
So, the solution done here is to add a GenerateOciSummary
system-helper call which we use instead of directly generating the
oci summary.
This fixes https://github.com/flatpak/flatpak/issues/2350Closes: #2363
Approved by: matthiasclasen
Make it clear that the command can be used a few different ways, and the
option used determines the needed positional arguments.
Closes: #2361
Approved by: matthiasclasen
Previously, downloaded files were being saved with 0600 permissions,
which prevented OCI icons downloaded by the system helper at appstream
creation time from being read by users.
Closes: #2362
Approved by: matthiasclasen
Currently by an accident of history when the system-helper is asked to
deploy updates to the repo metadata (stored on the ref
"ostree-metadata") it uses the polkit action
org.freedesktop.Flatpak.runtime-install since the ref doesn't start with
"app/" and is therefore assumed to be a runtime. This of course doesn't
make much sense, so this commit redirects such invocations of the
"Deploy" method to the "modify-repo" action, which is a bit of a
catch-all of things the system-helper should be allowed to do. It
doesn't seem necessary to split this out into its own action, since
sysadmins probably don't need the ability to break Flatpak's expected
functionality by disabling it. See the PR for more discussion.
Fixes https://github.com/flatpak/flatpak/issues/2328Closes: #2351
Approved by: matthiasclasen
Originally the modify-repo action was only used by the RemoveLocalRef
method, which has "remote" and "ref" parameters, but now other methods
use it which don't have such parameters. So this commit modifies
flatpak_authorize_method_handler() so that we're not trying to pass
information along to polkit that we might not have, and modifies the
message shown by polkit to be more accurate.
Closes: #2351
Approved by: matthiasclasen
This requires some new mechanisms: now we're skipping individual tests,
not just whole test scripts.
There are two main reasons why autobuilder environments might not be
able to run these tests successfully, both of which apply in Debian.
Tests that rely on bwrap typically can't pass in builds that take place
in a chroot, because bwrap's use of pivot_root() assumes that the root
directory is a mount point, but a chroot will typically have an unpacked
directory somewhere below the mount point as its root.
Some autobuilder environments are also sufficiently restricted that they
can't create new user namespaces at all, as a way to harden the
autobuilder host.
As a result, Debian autobuilders can't run the majority of the Flatpak
tests. We would like to be able to continue to run the subset that don't
need bwrap, to have the best test coverage we can. For the rest we have
to rely on installed-tests (which I've wired up to Debian's autopkgtest)
rather than using build-time tests.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #2339
Approved by: matthiasclasen
This is not a functional change: the default return value is equivalent
to polkit.Result.NOT_HANDLED. However, this makes the behaviour more
obvious.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #2354
Approved by: matthiasclasen
This makes it clearer that we are not assuming that the test is running
on an x86_64.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #2353
Approved by: matthiasclasen
