This function has libappstream-glib types in the
api, which we want to drop. And it is only used
in app/, so move it there.
Closes: #2580
Approved by: alexlarsson
Return non-NULL strings from flatpak_dir_get_id()
and flatpak_dir_get_display_name() for user installations,
to save library users the hassle of dealing with NULL
return values.
Closes: #2583
Approved by: alexlarsson
When we deploy e.g. app/org.foo.bar/x86_64/stable, then we
also create a deploy/app/org.foo.bar/x86_64/stable ref pointing to
the latest deployed commit. We also remove it when an app is uninstalled.
This means that a prune operation will not delete objects that are deployed
(which would not save any space anyway). This is nice because this can
happen for instance when you flatpak update --no-deploy.
Fixes https://github.com/flatpak/flatpak/issues/2085Closes: #2563
Approved by: alexlarsson
It's no longer true that it's the pull code's job to resolve a ref to a
specific commit. Ever since commit 66eee3c2c this is the job of the
resolve_ops() function used by FlatpakTransaction (at least, when a
transaction is being used). So update a couple comments to avoid
confusion.
Closes: #2587
Approved by: alexlarsson
It is possible for self->repo to be NULL, therefore
call flatpak_dir_ensure_repo() in a bunch more places,
before accessing self->repo.
Closes: #2483Closes: #2484
Approved by: matthiasclasen
In some cases, when NULL was passed for an OstreeProgress,
the library code would instantate its own progress object
and write progress information out to the console. That
is not a good thing for a library to do - it has the
potential to mess up the cli tools output.
Stop doing this, and require that all callers pass
a non-NULL progress.
Closes: #2468
Approved by: alexlarsson
Ostree just gives us a generic G_IO_ERROR_FAILED (boo!),
so we need to scrape the message to infer that this was
out-of-space. Translate this to an explicit error code
that we handle in the UI.
Closes: #2477
Approved by: alexlarsson
Avoid unnecessary complications from accepting installation
IDs which won't work well on the commandline or in filenames.
Closes: #2514
Approved by: mwleeds
When pulling the ostree-metadata branch for p2p remotes we passed
NULL for progress which caused it to report with the default console
progress, which doesn't make any sense for the (small) ostree-metadata
branch.
Closes: #2456
Approved by: alexlarsson
Use only the last section in the id for origin remotes, to avoid
the origin column being really wide when listing stuff.
Closes: #2448
Approved by: alexlarsson
We load the per-app appstream xml.gz during deploy and inject name,
summary and version from it into the deploy data. For older deploys
that don't have this data we re-create it when needed (with the hope
that updates to app eventually makes this unnecessary due to new deploys).
Additionally this removes the support for generating deploy files where
they don't exist, as support for this predates xdg-app 0.6, so should not
exist in real life.
Closes: #2409
Approved by: alexlarsson
This adds a version to the deply data format, assuming that if
there is no version then it is 0. Also extends all loaders so that
it can specify a required version, with the goal that most users
are fine with old versions, but if you need more recent we have
a (costly) conversion process to upgrade (will be added later).
The library and the flatpak list/info commands require the most
current version for full info, all other users can use any version.
Also, as part of this we now pass the ref to flatpak_load_deploy_data()
as this will be needed later for the backwards compat support.
Closes: #2409
Approved by: alexlarsson
Make flatpak_dir_resolve_p2p_refs return the
download and installed sizes as well. This is
useful information to present to the user before
doing an install or update.
Closes: #2371
Approved by: alexlarsson
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 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
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
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
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
This adds support for fuzzy matching ref names (AKA "typo helper") to
the uninstall command to mirror what the install command has. In short,
this means you can do "flatpak uninstall gedit" instead of "flatpak
uninstall org.gnome.gedit". Flatpak will prompt you to choose between
similarly named installed refs, and will only make the choice for you if
--assumeyes was used and there's only one match.
Note that this commit does have the side effect that if there are
multiple matching refs with the same ID (e.g. with different branches or
in different installations) you are prompted to choose between them.
Previously you were shown an error message.
Closes: #2330
Approved by: matthiasclasen
When installing a flatpak with extra-data we execute the apply_extra
script from the flatpak to extract the extra data files we
created. This script runs with very little filesystem acces, but it
does have write permissions to the location that will eventually be
/app/extra in the finished flatpak. This is especially problematic for
the systemwide install case, because the script is then run as root,
so it could potentially create a setuid file there.
Such a file would not be usable inside the sandbox (because setuid is
disabled in the sandbox), but it could potentially be a problem if the
user could be tricked into running the file directly on the host. This
is the same behaviour as e.g. rpm or deb which both can install setuid
files, but we want to guarantee that flatpak is better than that.
The fix is to run the script with all capabilities dropped (bwrap
--cap-drop ALL) which removes a bunch of possible attack vectors (for
instance setting file capabilities). However, even without
capabilities, it is possible for a user to make any file setuid to the
same user, so we also need to canonicalize the permissions of all
files generated by running the script.
Additionally, while running the script we set the toplevel directory
only be accessible to the user, meaning we will not temporarily leak
any potential setuid files to other users.
Note, this commit actually goes furthen than that and completely
canonicalizes all the file permissions to be the same as those
otherwise used by flatpak. For example we fix up cases where the
script creates files writable or unreadable by non-root users.
Closes: #2323
Approved by: alexlarsson
If you have a pre-existing remote configured its exact definition
might differ from the one specified in a flatpakrepo file and yet
be the same.
For example, i have:
$ flatpak --user remotes -d
Name Title URL Collection ID Priority Options
flathub Flathub https://dl.flathub.org/repo/ org.flathub.Stable 1
Yet when i install a flatpakref:
$ flatpak --user install http://flathub.org/repo/appstream/org.gnome.gedit.flatpakref
The application org.gnome.gedit depends on runtimes from:
https://dl.flathub.org/repo/
Configure this as new remote 'flathub-1' [y/n]:
Because the flathub flatpakrepo does not yet have the collection id specified.
So, we need to be more lenient when matching the pre-configured remotes.
Closes: #2324
Approved by: alexlarsson
This commit adds a key called DeployCollectionID to the flatpakref and
flatpakrepo file formats, which is intended to replace the CollectionID
key (which is still supported but deprecated). The reason for the change
is the same as for the metadata key change from xa.collection-id to
ostree.deploy-collection-id, which is that old versions of Flatpak
(roughly 0.9.8 through 1.0.1 depending on compile time options) hit
various bugs when collection IDs are in use. Flathub will soon enable
the metadata key to deploy collection IDs, and this change means Flathub
can also deploy the collection ID in flatpakref and flatpakrepo files
without affecting old clients.
Adding DeployCollectionID to the flatpakref and flatpakrepo files will
mean the flathub remote can be automatically configured with a
collection ID without depending on the metadata key to do that.
Closes: #2329
Approved by: alexlarsson
We want to avoid unnecessary confusion and complications,
so we rule out IDs that are problematic because they will
clash with the default installations.
At the same time, make the error messages for parsing
custom installations more informative.
This is currently only used in the ‘search’ built-in command, but will
need to be used in upcoming parental controls filtering changes in
Endless OS (which will go upstream eventually) too.
This introduces no functional changes.
The CFLAGS/LIBADD changes are necessary because of the new
AppStream #includes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #2296
Approved by: matthiasclasen
This commit implements a "typo helper" for the install command, so that
if you don't get the app ID exactly correct you're prompted with
similarly named apps available in the remote that you can choose from.
Essentially this allows you to do "flatpak install flathub devhelp"
instead of "flatpak install flathub org.gnome.Devhelp".
The choice is only made for you in two cases: 1. If it's an exact match
and there's only one match, it is used as before this commit. 2. If the
-y/--assume-yes option was used and there's only one match, it is used.
Presumably scripts would always specify the full app ID, so this should
only affect users on the command line who choose to use that option.
In the future we may want to use the groundwork laid in this commit to
add similar functionality to other commands, like perhaps remote-info
and run.
This is a partial fix for https://github.com/flatpak/flatpak/issues/1258Closes: #2113
Approved by: matthiasclasen
flatpak_dir_find_remote_refs() and flatpak_dir_find_remote_ref() have
support for finding remote refs via P2P means because
flatpak_dir_list_all_remote_refs() uses the list of refs in the xa.cache
in that case. So remove the outdated comments.
Closes: #2113
Approved by: matthiasclasen
Write to the systemd journal for basic operations
that modify installations, such as pull, deploy,
uninstall. Include some useful information as
separate fields, such as OPERATION, INSTALLATION,
REMOTE, REF, COMMIT.
We add the logging in the api layer that is used
by the system-helper as well, so that changes
from that side are logged as well.
All logs we write currently use the same message
ID, defined as FLATPAK_MESSAGE_ID in the headers,
for easy retrieval of messages.
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
