When a collection ID is set on a remote configuration,
gpg-verify-summary should be set to FALSE because flatpak uses signed
per-repo and per-commit metadata instead. The flatpak command line
already does this (use flatpak remote-modify --collection-id=... and
notice that gpg-verify-summary is then set to false). This commit
changes libflatpak to have the same behavior. Specifically, with a
collection ID set gpg-verify-summary is set to false and otherwise its
value matches that of gpg-verify. This commit also adds a test for this
in testlibrary.c.
Fixes https://github.com/flatpak/flatpak/issues/1479Closes: #1501
Approved by: pwithnall
As per https://github.com/flatpak/xdg-desktop-portal/pull/166, an access
check to a non-existant file should succeed if the parent directory
exists, and we have write access to it, because we can then just create the
file. This is needed for the "save" file chooser portal.
Closes: #1488
Approved by: alexlarsson
We set the Flatpak-Ref http header to the ref we're pulling, thus
allowing the server to log this for per-ref download statistics, as
otherwise the ref being downloaded is not visible in the log (only
the commit id).
Closes: #1487
Approved by: alexlarsson
The remote-ls command should skip remotes that have "xa.disable" set to
true or have no URL set, which can happen for remotes added for flatpak
bundle files.
Fixes https://github.com/flatpak/flatpak/issues/1427Closes: #1457
Approved by: alexlarsson
If the --show-details option is passed to the remotes command, show the
collection ID for each remote, which the user might need to know if
they're using flatpak's P2P support.
Closes: #1458
Approved by: alexlarsson
repo_pull_one_dir() and repo_pull_one_local_untrusted() used to only
support pulling one directory at a time, but now support more than one,
so rename them so the names are less misleading.
Closes: #1475
Approved by: alexlarsson
This isn't needed for servers and starting the a11y bus on a
fresh session bus takes upwards of 15 seconds.
Fixes#1471Closes: #1486
Approved by: alexlarsson
Similarly to commit 272af0f8c, this commit makes sure the child repo
used by the system helper has an accurate summary file so it can be
pulled from. This time it's for the fetches of the ostree-metadata ref
and the appstream data.
This fixes a bug that occurs if a remote has a collection ID set and
uses the "branches" key as well. Under those conditions, `flatpak
remote-ls -d REMOTE` and `flatpak update --appstream REMOTE` can fail
with "Error pulling from repo: No summary found".
Until recently, the /ostree/repo/config in Endless contained a remote
that was shared between flatpak and ostree, which had "branches" set. So
that's a use case where this helps.
Fixes https://github.com/flatpak/flatpak/issues/1440Closes: #1478
Approved by: pwithnall
After pulling multiple refs into the child repo using P2P code, the
summary file in the child repo will be the one from the last remote
used. Since that remote might be a peer on the network or a USB drive,
it may not have the same set of refs as were pulled into the child repo.
This means that when the system helper tries to pull from the child repo
into the main repo it fails because the summary file is inaccurate.
This commit addresses the issue by regenerating the summary file in the
child repo after the pulls finish. This has to only occur on the P2P
code paths because non-P2P code uses the summary file and its signature
as the security check.
To check that this fixes the bug, I set up another computer on the local
network as an update server and made sure it had an updated
ostree-metadata ref for the remote I'm going to use. Then from this
computer with the patched flatpak I installed an app that's **not**
installed on the update server (all using collection IDs). Flatpak
fetched the app from the Internet, fetched the ostree-metadata ref from
the network peer, and then successfully pulled and deployed the app into
the system repo.
Fixes https://github.com/flatpak/flatpak/issues/1425Closes: #1476
Approved by: pwithnall
Apparently when I rebased https://github.com/flatpak/flatpak/pull/1314
to master, git cleanly applied the patch in a different place than it
was originally. Commit c5ab9e22b moved the find_remotes_async() call to
find_latest_rev(), so all that needs to be done is pass along the
checksum in check_for_update(). This way when you're trying to downgrade
something the specified commit will be searched for instead of the
latest one.
Fixes https://github.com/flatpak/flatpak/issues/1431Closes: #1435
Approved by: barthalion
Now that the search command is attempting to update appstream data for
all supported architectures, error messages get printed when it's
missing, which is often the case for i386. This commit changes
flatpak_dir_check_for_appstream_update() to only print an error if the
the appstream data for the host architecture is missing, but not if it's
a secondary architecture.
Closes: #1430
Approved by: alexlarsson
Currently the search command only searches remotes for apps and runtimes
that match the host architecture. This commit makes flatpak include all
supported architectures so for example you can see a 32-bit app on a
64-bit computer.
Fixes https://github.com/flatpak/flatpak/issues/1353Closes: #1430
Approved by: alexlarsson
Before the 2018.2 release of libostree there was no way to specify
commit IDs when using find_remotes_async(). The latest commit is always
pulled, so flatpak apps can't be downgraded when collection IDs are in
use. Now that an option is provided by libostree this commit uses it,
and updates the minimum required version to 2018.2 when P2P support is
enabled.
The effect is that `flatpak update --commit=HASH APP` will work when APP
comes from a repository that has a collection ID configured.
Fixes https://github.com/flatpak/flatpak/issues/1309Closes: #1314
Approved by: pwithnall
On atomic, /home is a symlink to /var/home, which caused
problems in flatpak build when granting access to the homedir.
Due to a previous workaround (in 1aadc3ee40) we
make /var in the flatpak build sandbox be completely overridden
with $builddir/var so that the above symlink would not cause problems
in the persisted directory.
However, when we actually *want* to give access to that symlink this
causes problem.
In general, exposing /var in the sandbox has two uses:
* Allowing persisting tmpfiles in /var/tmp between individual
flatpak build commands (/tmp is per-build-command).
* Creating flatpaks from packages, such as rpms, where
we want to keep the rpm database (/var/lib/rpm) around during
the entire build so that dependencies can be resolved.
In order to handle these /var/home issues while still allowing
the above issues we instead persist only /var/tmp and /var/lib.
Fixes https://github.com/flatpak/flatpak/issues/1407Closes: #1421
Approved by: alexlarsson
The process was printing a line for every mismatching component id
in the xml for each app, which is starting to get very large log files
on flathub.
Closes: #1426
Approved by: alexlarsson
On atomic /home is a symlink to /var/home, so when we bind-mount
the persistent directories we need to early-resolve the symlinks
to avoid running into issues with /newroot.
In most cases we do this already by calling flatpak_bwrap_add_bind_arg,
but the persistent dir case did not, because that function required
the target to exist, and the persistent directoried might not.
However, these days flatpak_bwrap_add_bind_arg is fine if the base
dir doesn't exists but the target does, which is the case here,
so we can use it now.
This fixes e.g. steam: https://github.com/flatpak/flatpak/issues/1278Closes: #1422
Approved by: cgwalters
This was needed for the document portal, which has been removed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #1417
Approved by: alexlarsson
