The code to use the pre-generated test platform was buggy so it wasn't
used. Also, generate a "stable" branch of it too as that is used
by test-run.sh.
If accountsservice isn't available on the system bus, then we can't
ask it for the user's parental controls settings, and we also can't
ask it whether it even has the malcontent extension. Since this is
not a real security boundary, fail open.
This can be dropped if we depend on a version of libmalcontent that maps
these errors to MCT_APP_FILTER_ERROR_DISABLED.
Resolves: https://github.com/flatpak/flatpak/issues/3902
Bug-Debian: https://bugs.debian.org/972138
Signed-off-by: Simon McVittie <smcv@collabora.com>
Sometimes a server might return a HTTP error 500 (this seems to happen
sometimes with Microsoft’s VSCode server, for example). Map this to
`G_IO_ERROR_HOST_UNREACHABLE` for now, which is a bit more specific than
returning `G_IO_ERROR_FAILED`, but without the hassle of introducing a
new public error domain which could give more detail.
In particular, this should allow gnome-software to show an error message
to the user for such failed downloads, rather than hiding the error and
logging the following:
```
not handling error failed for action download: While downloading http://packages.microsoft.com/repos/vscode/pool/main/c/code/code_1.45.1-1589445302_amd64.deb: Server returned status 500: Internal Server Error
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We were clearing the error from the anon test, and then not doing any
non-anon auth, so error was NULL, causing a crash when returning an
error message.
If possible, ask for confirmation of the entire transaction before
starting to do the per-ref authentication. We do this by splitting
the current "ready" callback into two parts, one in ready-pre-auth
and the rest in ready.
There is some complexity added because if we do any authentication
between the two signals we can't back-patch the transaction list we
already printed. To handle this we detect this case and re-print the
table if this happens.
flatpak_installation_list_installed_refs_for_update() now uses the
ready-pre-auth signal instead of the ready signal. This means we will
report updates even for refs that require authentication to install.
This is similar to the ready signal, except it is called before
per-ref authentication. Apps can use this if they want to be able
to ask for user input on progress before asking for authentication.
This is nice to be able to do in general, but it is also required for
the implementation of
flatpak_installation_list_installed_refs_for_update(), as it doesn't
install any authentication handler, so it will never report updates
for protected refs if using the ready signal.
Note: In special cases we will require authentication even earlier
if authenticating is needed during the resolve operation. This happens
for instance if you are doing a update to a particular commit (rather
than the lastest commit) where we need to get the commit object directly.
It is very much possible for an invalid ref name to occur, either due to
lack of validation on Flatpak creation like #3887, or just any
manually-written ref name due to skipping Flatpak tooling or malicious
intent. Regardless, this shouldn't crash, so check the names before
creating the transaction ops.
Fixes#3887.
This change makes repair print the current ref number being verified
and the total number, that way the user can observe the repair progress.
In addition, if fancy output is not disabled, the progress will be
cleanly printed on a single line.
On a dry run, this also will still print the delete messages without
actually performing the operations, to show what actions would be
taken on a non-dry-run.
This way we can get the proper eol status for the new to-be-installed
refs, rather than whatever was previously installed. This allows us to
detect when a runtime is updated and the new one is eol, and nothing
uses it, so it can be auto-uninstalled.
Rather than trying to figure out which runtimes are affected byt
the current setup of ops we run flatpak_dir_list_unused_refs() twice,
once with and once without the changes the transaction will cause.
Any unused refs after the transaction that were not unused before are
caused by the transaction and we start uninstall ops for those.
Also rename flatpak_dir_list_unused_refs_with_options() to
flatpak_dir_list_unused_refs() as it need not be so long.
If we're auto-installing dependencies we want to limit them to those
from the same remote. However you can still (manually) install such
dependencies, so when we're looking for things to possibly uninstall
we need to check dependencies from all remotes.
In case a runtime becomes unused and then later becomes End-Of-Life, it
is currently not removed. So this commit removes such runtimes in the
update command, as discussed in #2639. A unit test is included.
I am planning to propose to use the FlatpakTransaction API added here in
gnome-software, so that users don't have to use the CLI at all for
runtimes to be cleaned up. KDE Discover already removes unused runtimes
periodically.
We normally don't remove a runtime when the last app using it is
uninstalled, since runtimes are large and re-downloading it in the
future may be difficult. But if the runtime is end-of-life, there's a
reasonable chance it won't be used again, so uninstall it in that case.
Similarly, if the last app using a runtime is upgraded to a different
runtime, and the runtime is EOL, uninstall it.
A unit test is included, and the subsequent unit test also had to be
modified. Otherwise we get a "Update is older than current version"
error, since the runtime is installed from test-repo but
setup_repo_no_add() calls make_runtime() which uses the one in
runtime-repo instead, which is older than the one in test-repo.
In a few places we are using
flatpak_installation_list_unused_refs() and then only
using the ref strings not the FlatpakInstalledRef objects, so the
resources used to construct those objects are wasted. Add a flatpak_dir_
function to be used internally instead. One day we will figure out how
to make flatpak-dir.c less of a wilderness.
This also adds the flatpak_installation_list_unused_refs_with_options()
verion that has extended features.
commit 6b46d9a0ed that added DConf path
skewering to camelcase conversion only allowed it in one direction
(skewered path1 and camelcase path2).
That turned out to be not enough to allow /org/gnome/sound-juicer/ to
/org/gnome/SoundJuicer/ conversion as the caller had the
flatpak_dconf_path_is_similar() arguments the other way around.
This commit implements it both ways to avoid confusion which way it
should be called.
F: Ignoring D-Conf migrate-path setting /org/gnome/sound-juicer/
I'm not documenting the individual methods here, only the fact that the
interface exists and is private to the Flatpak source tree (it's the
communication between libflatpak and the system helper).
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is based on documentation that I wrote for Steam's pressure-vessel,
which has a Launcher interface based on the API and implementation of
the Flatpak portal.
I haven't renamed exit_status to wait_status like commit 63feb3cc in
flatpak-xdg-utils, just in case the name is significant in someone's
code-generation. However, don't be fooled: it's a wait-status, not
an exit status.
Signed-off-by: Simon McVittie <smcv@collabora.com>
They aren't currently in any installed header file, but that doesn't
mean we can't suggest a name for dependent projects to #define.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Flags are assumed to be critical, similar to the convention for modern
Linux syscalls: if an unknown flag is given, the call will fail.
Callers are expected to guard their use of flags with a version check
or a fallback.
Conversely, options are assumed to be non-critical "hints", similar
to org.freedesktop.Notifications: if an unknown option is given, the
call will succeed as though the option had not been present. Callers
are expected to carry out an explicit version check if they need to
know whether an option is going to be respected or not.
Signed-off-by: Simon McVittie <smcv@collabora.com>
