When trying to extract icons to regenerate the appstream, we are looping
over the entire file every time, instead of only trying to copy icons
for the application ID we're looking at the moment.
This is most likely benign, but it causes a lot of "Error copying icon:
No such file or directory:" spew when calling flatpak build-update-repo.
This lets us find all the "related" refs to a ref in a particular
remote, or locally. These are the things we should automatically
download or delete when installing/updating/uninstalling the ref.
The implementation currently looks at all the extensions handled by the
app/runtime. For debug extensions and extensions marked no-autodownload we
only consider them related if its already locally installed. For locale
extensions we always consider them related, but we only pull the current
locale data for it.
I don't think it makes sense to have to enable this for everything.
It should be safe in the sense that you can't ever do more than
the user can do anyway, and there is no way to use this to communicate
with the rest of the system because you can't read from it.
The worst this could ever cause is to overload the system, but the
sandbox doesn't protect against that in any other way anyway.
This lets distributors share a system copy of bubblewrap (>= 0.1.0)
between Flatpak and any other projects that benefit from it, if they are
careful to keep new versions in sync. The default is still to use the
bundled submodule, ensuring compatibility and simplifying dependencies.
Enable $PATH search everywhere that runs bwrap, so that $BWRAP doesn't
necessarily need to be a fully-qualified path.
Signed-off-by: Simon McVittie <smcv@debian.org>
Due to an issue with ostree (https://github.com/ostreedev/ostree/pull/362)
applying non-from-scratch deltas fail when using parent_repo such as
in the system-helper case. We fix this temporarily by disabling the
use of deltas for that case.
This gives the application full access to the host /dev. Obviously
this is not great in terms of sandboxing, but its nice for applications
that use flatpak mostly as a way to do distribution of the app.
Also, its not like the app has full access to anything, its still
limited to the access right of the user.
In a minimal environment (like the one where we run installed-tests
in Debian), we might not have /usr/share/fonts.
Signed-off-by: Simon McVittie <smcv@debian.org>
This has several improvements:
* Writes to a temporary location and renames at the end, so
we never end up with partial checkouts.
* Don't fsync each file during checkout, instead syncfs() at
the end
* Pre-create the target deployment directory so that we get the right
permissions for it.
For a local (file:// uri) remote, do an (untrusted) direct pull instead
of pulling into the users cached repo first. This way we do less copies,
as well as guaranteeing the source of the data. The later means its
mostly safe to also allow this for non-gpg signed remotes.
