This is a variant that allows to enter multiple numbers,
either individually, or as range. Parts can be separated
by space or comma. Examples:
1-3,5
1 2 4
6
Closes: #2559
Approved by: alexlarsson
'flatpak install sdk' offers me 34 choices, so double digits
seem very realistic here. Make the numbers line up in this
case.
Closes: #2476
Approved by: matthiasclasen
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
This prints the common pattern of
Choices:
1) bla
2) bla
with consistent formatting, so we don't have
to worry about matching newlines and spaces
all over the codebase.
Closes: #2371
Approved by: alexlarsson
Add a function to query the window size and cursor position,
and definitions for some more ANSI escape sequences that we
will use in the following commits.
Closes: #2371
Approved by: alexlarsson
It happens sometimes that the first processed total is 1, when this gets
downloaded we have 100% already and then the total changes making this
percentage faulty.
This makes the progress regress sometimes, but I'd say it's better than
a permanent, ficticious number.
Fixes#2428
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
Firstly this changes the "download-if" and "enable-if" properties
to accept a `;` separated list of multiple conditions.
Secondly it adds `on-xdg-desktop-*` which will check against
the XDG_CURRENT_DESKTOP env var (case-insensitively).
This is done entirely for the Qt GNOME Platform so it can do this:
```
"org.kde.PlatformTheme.QGnomePlugin" : {
"download-if": "on-xdg-desktop-GNOME;on-xdg-desktop-GNOME-classic"
}
```
Closes: #1436
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
This commit implements a feature in the multiple choice prompt that
mirrors the behavior in the yes/no prompt where it can default to "yes"
when the user only presses Enter. In the case of the multiple choice
prompt, it only defaults to the first choice on Enter if there's only
one option (e.g. you're asked if you want to install from the "flathub"
remote as opposed to being asked to choose between the "flathub" and
"eos-apps" remotes).
This feature can be turned off on a per-prompt basis if we want explicit
user input for something but I didn't find that necessary for any of the
existing prompts.
Also note that as with the yes/no prompt defaulting to yes on Enter,
this only applies for interactive terminals. If Flatpak is being run by
a script no choice will be made automatically.
This should save users unnecessary keystrokes, such as when they use
"flatpak install devhelp" and are asked to confirm that the Flathub
remote is the one to use (now they can just press Enter).
Closes: #2288
Approved by: matthiasclasen
Currently when the Flatpak command line prompts the user with a yes or
no question, the user must type "y" or "n" to respond. This commit
changes it so that the prompt can assume "yes" if the user just presses
Enter. In that case the prompt ends in "[Y/n]" rather than "[y/n]". If
there are some operations that are considered dangerous, we can still
require explicit user input on those, but as far as I can tell those
criteria don't apply to any existing prompts.
This behavior of allowing the user to just press Enter is consistent
with how apt works for example.
Note that this is distinct from the "--assume-yes" option we have, since
that won't prompt the user at all when a decision needs to be made.
Closes: #2113
Approved by: matthiasclasen
This moves the implementation of the Levenshtein "edit distance"
algorithm from app/ to common/ so it can be used in an upcoming commit.
Closes: #2113
Approved by: matthiasclasen
Neither flatpak_variant_builder_init_from_variant nor
flatpak_gvariant_new_empty_string_dict are used anywhere.
Closes: #2252
Approved by: matthiasclasen
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_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
We were exporting files in subdirectories of all the common
directories. This only really makes sense for icons. For
desktop files, D-Bus service files and mime types, we should
only export from the exact directory itself.
Note that this makes us no longer support the obsolescent
vendor-prefix convention of the desktop entry spec, which was
only relevant for KDE4 and breaks app-id matching.
Closes: #2142Closes: #2152
Approved by: alexlarsson
Currently Flatpak reads a repo metadata key called "xa.collection-id" to
decide whether to configure a collection ID on a remote. This commit
drops support for xa.collection-id and replaces it with
ostree.deploy-collection-id, which is a key defined by OSTree but so far
only implemented here.
The reason for the change is so that collection IDs can only be deployed
to users running recent versions of Flatpak and OSTree. The current
situation is that Endless wants to deploy collection IDs (and therefore
support for doing USB updates) to users, but servers such as Flathub
can't safely set xa.collection-id in their metadata, because many users
are still using old versions of Flatpak and OSTree[1] which would hit
various bugs[2][3][4] on the P2P code paths that are enabled by
collection IDs. Defining a new key means that only users running
recent (as-yet-unreleased) versions of Flatpak and OSTree will pay
attention to it and deploy the collection ID, leaving the users on old
versions unaffected.
The reason this metadata key is being defined at the level of OSTree
instead of Flatpak, is that OSTree may want to implement it in the
future.
The functionality of deploying a collection ID by setting the
"deploy-collection-id" key in the config on the server side (which in
turn causes ostree.deploy-collection-id to be set) is already covered by
the unit tests in test-update-remote-configuration.sh; this commit just
tweaks them to use the new key.
Another solution I proposed to this problem was to have a key
"eos.collection-id" which would only be understood by the Endless fork
of Flatpak, and use that temporarily until enough people are running
recent versions of Flatpak, at which point "xa.collection-id" can be
used. But this solution (abandoning xa.collection-id upstream) allows us
to avoid that migration step and leave users on old versions of Flatpak
completely unaffected.
[1] https://ahayzen.com/direct/flathub.html#downloadsbyflatpakstacked
[2] https://github.com/ostreedev/ostree/commit/e4e6d85ea
[3] https://github.com/flatpak/flatpak/commit/5813639f
[4] https://github.com/flatpak/flatpak/commit/5b21a5b7
The collection id check that was added leaks if we were able
to read the collection-id, but then it was ignored.
Closes: #2093
Approved by: alexlarsson
Currently if you install from a flatpak bundle that doesn't have a
collection ID set or from a flatpakref file that has the CollectionID
key set to the empty sting, you end up with an invalid configuration on
the origin remote created. This is because the collection_id parameter
of flatpak_dir_create_origin_remote() is set to the empty string, not
NULL, and create_origin_remote_config() then only checks for NULL when
deciding whether to set gpg-verify-summary to true or false. Then
because there's no collection ID configured but gpg-verify-summary is
set to false, you get the error "Can't pull from untrusted non-gpg
verified remote" when trying to pull related refs or update the app.
This commit fixes the bug by checking for the empty string when the
collection ID is read from a bundle or ref file, and collapsing that
into NULL.
Closes: #2081
Approved by: alexlarsson
This will allow us to return anything in the FlatpakError domain using
g_dbus_method_invocation_return_gerror().
Closes: #1965
Approved by: alexlarsson
It's a good idea to NULL initialize g_autoptr/g_autofree variables, so
we can be sure uninitialized memory isn't passed to g_free or similar.
Closes: #1968
Approved by: alexlarsson
Checking the registry against a previous etag is now handled inside
flatpak_cache_http_uri(), so remove the etag parameters that were
previously passed around in various places for simplicity.
Closes: #1910
Approved by: alexlarsson
In preparation for extending the HTTP downloading function to include
caching, split HTTP related utilities into a separate file with a
separate header.
Closes: #1910
Approved by: alexlarsson
