Support a list of versions that are supported. This will be useful
for e.g. the extra_data for extensions once that is backported to
1.2, because that will require it to say that it is supported for
> 1.2.5 in the 1.2 series and > 1.4.2 otherwise.
Closes: #3112
Approved by: alexlarsson
(cherry picked from commit 5026f01153)
(cherry picked from commit 9bbe6fbb48)
Closes: #3115
Approved by: alexlarsson
Currently if you have a remote configured with the URL
"https://dl.flathub.org/repo/" (as you would if you use the flatpakrepo
file) and you use a flatpakref file which specifies the URL
"https://dl.flathub.org/repo", Flatpak tries to add a duplicate remote
because it doesn't see those URLs as equal. So ignore the trailing slash
when comparing remote URLs. OSTree works equally well with both kinds
(it uses g_build_filename()).
Flathub served flatpakref files with URLs missing a trailing slash until
this commit:
https://github.com/flathub/ansible-playbook/commit/b20694f09
Also, add a unit test that fails without this patch.
Fixes https://github.com/flatpak/flatpak/issues/2979Closes: #3065
Approved by: alexlarsson
(cherry picked from commit 866ba643d2)
Closes: #3115
Approved by: alexlarsson
We were only handling the old single-value 'version' key, even though
we handled the 'versions' key when finding remote related refs.
The result of this was that some extensions, such as the 19.08 opengl
default one was installed by default (as it was found as remote related)
yet still removed with --unused (as it was not locally related).
Fixes https://github.com/flatpak/flatpak/issues/3004Closes: #3093
Approved by: mwleed
(manually cherry-picked from commit aa7b62a0bf)
Closes: #3115
Approved by: alexlarsson
This prevents a crash in flatpak_installation_list_remotes_by_type() if
the `FlatpakDir` can’t ensure it has a repo configured.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #3028
Approved by: alexlarsson
(cherry picked from commit 791f31898b)
(cherry picked from commit 12cecc852c)
Closes: #3115
Approved by: alexlarsson
If the download URL for an icon was already cached locally, the HTTP
code returned FLATPAK_OCI_ERROR_NOT_CHANGED - this was treated as a real
error, and after downloading missing icons, all present icons were
deleted!
See https://bugzilla.redhat.com/show_bug.cgi?id=1683375Closes: #3048
Approved by: alexlarsson
(cherry picked from commit a794c07e18)
(cherry picked from commit 767a9d5a43)
Closes: #3115
Approved by: alexlarsson
It's an error to call g_set_error() on an error that's already set, and
flatpak_dir_get_deploy_data() already sets FLATPAK_ERROR_NOT_INSTALLED
for us when necessary, so just pass on any errors to the caller of
flatpak_dir_get_origin(). In the case that the error is something else,
that should be treated as an error, because we never expect the deploy
directory to exist but not have a deploy file (see the implementations
of flatpak_dir_deploy() and flatpak_dir_undeploy()).
Closes: #3032
Approved by: alexlarsson
(cherry picked from commit b44c1a5799)
(cherry picked from commit 8ed03ef61e)
Closes: #3115
Approved by: alexlarsson
I spotted this line in the output from `flatpak history`:
Jun 4 16:17:20 deploy install com.discordapp.Discord x86_64 stable system flathub 8a0fc700c701 Installed %s from %s root (test) flatpak-system-helper (gnome-software) 1.3.3
This is because the format string is passed as the 'url' parameter, the
first format parameter (the ref) is passed as the 'format' parameter,
and 'origin' is ignored because (fortunately) as far as I know, no
character significant to printf (like '%') is permitted in ref names.
Fix this by passing a NULL 'url', like the neighbouring call in
flatpak_dir_deploy_update().
(cherry picked from commit dbc90df513)
(cherry picked from commit 5a16666bdc)
Closes: #3115
Approved by: alexlarsson
We need to check whether the remote is gpg verified after handling
the oci case, because OCI is fine to update systemwide without gpg
verification (in fact it doesn't support verification).
This just reorders the code, matching what is done in the install
case already.
Closes: #2891
Approved by: alexlarsson
(cherry picked from commit 4c4c80b85d)
Closes: #3115
Approved by: alexlarsson
When an appstream update is cancelled while downloading
icons, properly fail. Otherwise, the next update attempt
will see an up-to-date timestamp, think everyhing is ok
and not download the missing icons.
Closes: https://github.com/flatpak/flatpak/issues/2835Closes: #2836
Approved by: alexlarsson
(cherry picked from commit f28e62add1)
Closes: #3115
Approved by: alexlarsson
Commit b20ee7e26 introduced a bug where flatpak_load_deploy_data()
returns NULL without setting @error in the case that there's a problem
reading the deploy file. I think this is causing a seg fault in
flatpak_installation_list_installed_refs() which tries to print the
error message after calling get_ref() (which indirectly loads the deploy
file).
I didn't personally verify that this fixes the GNOME Builder seg fault
that was reported, but it seems almost certain looking at the provided
stack trace, since get_ref() only returns NULL if
flatpak_dir_get_deploy_data() returns NULL, and that function clearly
sets the error pointer on failure except in flatpak_load_deploy_data().
I'm not sure why the deploy file doesn't exist (or is unreadable) for
the user who reported this seg fault.
Fixes https://github.com/flatpak/flatpak/issues/2717Closes: #2733
Approved by: matthiasclasen
(cherry picked from commit 7a5c024695)
Whenever we use $XDG_RUNTIME_DIR and expose it somehow in the sandbox
we fully resolve the path, because if (as happens on gentoo for instance)
it contains /var/run -> ../run, then flatpak thinks we need to
add the /var/run symlink in the runtime even though we already
exposed that.
Closes: #2710
Approved by: matthiasclasen
(cherry picked from commit 28e96288c4)
As shown by CVE-2019-5736, it is sometimes possible for the sandbox
app to access outside files using /proc/self/exe. This is not
typically an issue for flatpak as the sandbox runs as the user which
has no permissions to e.g. modify the host files.
However, when installing apps using extra-data into the system repo
we *do* actually run a sandbox as root. So, in this case we disable mounting
/proc in the sandbox, which will neuter attacks like this.
(cherry picked from commit 468858c1cbcdbcb27266deb5c7347b37adf3a9e4)
For whatever reason, in the buildbot environment the TIOCGWINSZ
ioctl returns a 0x0 size, which causes a divide by zero. We
handle this by returning a default 80x24 size.
Closes: #2685
Approved by: alexlarsson
(cherry picked from commit 7c9368d100)
We only interested in a few of the attributes of some
tags, but we shouldn't fail if other valid attributes
are present.
Add some of the allowed attributes to the <release> element
in the appdata test and verify that we can still parse it.
The appstream spec is here:
https://www.freedesktop.org/software/appstream/docs/Closes: #2674
Approved by: matthiasclasen
This file lists the directories that are remapped in the sandbox,
allowing fontconfig to use the correct cache identifier for the
host-side caches.
As an example, this generates:
```
$ ./flatpak run --command=sh org.gnome.gedit
[📦 org.gnome.gedit flatpak]$ cat /run/host/font-dirs.xml
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<remap-dir as-path="/usr/share/fonts">/run/host/fonts</remap-dir>
<remap-dir as-path="/home/alex/.fonts">/run/host/user-fonts</remap-dir>
</fontconfig>
```
Closes: #2635
Approved by: alexlarsson
The spec allowed either timestamp or date to
be specified for a release, so we should support
both.
Closes: #2614Closes: #2619
Approved by: alexlarsson
This lets us export D-Bus service files for
names like org.foo.Bar.Application.Tracker.service
when the app-id is org.foo.Bar.
Closes: #2615Closes: #2616
Approved by: alexlarsson
If the user (erroneously) runs as root while modifying their user
installation, e.g. with "sudo flatpak --user install ...", this can
cause "permission denied" errors later on when they try to operate on
the installation as their own user. So refuse to execute a transaction
on a user-owned installation as root. Root can still operate on their
own per-user installation.
This approach does have a weakness: if flatpak is running as root when the user
installation is first created, it will be owned by root and therefore
avoid this check. I'm not sure what could be done about that.
Fixes https://github.com/flatpak/flatpak/issues/2565Closes: #2575
Approved by: alexlarsson
We want to move away from using dconf inside the sandbox,
and instead use the keyfile backend for GSettings, which
has gained the capability to read defaults and locks.
This change makes the dconf database contents and locks
available in a suitable format. The files appear inside
the sandbox in the /etc/glib-2.0/settings directory.
We only export the default values for keys in the dconf
subtree whose path matches the app id, as well as prefixes
listed in paths key from the X-DConf group in metadata.
This commit adds a new dependency, since we're now linking
against libdconf.
Closes: #2295
Approved by: alexlarsson
We no longer use it here. flatpak itself still links
against it. This avoids problems with consumers who
might also link against libappstream.
Closes: #2580
Approved by: alexlarsson
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
Document the values returned by flatpak_installation_get_id()
and by flatpak_installation_get_display_name() for standard
installations.
Closes: #2583
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
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
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
