We artificially limit the metadata phase to the first 20 metadata
objects, because otherwise that phase takes too long time, as it
downloads content at the same time.
For the delta case we can get perfect results by just ignoring
the counts and relying on the sizes. However, this needs a
recent ostree that supports the fetched-delta-part-size field.
For the object case we keep using the object average size
to estimate a size which we can compare with the extra data
size.
Now that we have access to the total extra-data download size,
we can have much more precise progress reports by summing up
all the download sizes from OSTree and extra-data.
This patch makes the progress report callback use the extra-data
sizes, as well as calculate the average size (in bytes) of the
content.
flatpak/flatpak#609
There is a race condition in how the portals detects the peer app-id.
If we manager to open /proc/$pid/root, and then openat(fd,
".flatpak-info"), but the process dies inbetween the two, then the
.flatpak-info read-only bind mount (and all other mounts in the
namespace except the root one) is unmounted, so we will find
and empty .flatpakinfo file.
We fix this race by storing the contents in a regular file, but
also as a readonly bind mount on top of it.
For typical dbus portals the pid is the dbus proxy though, and in
that case the app can't modify the file, so we make it just
a file there instead of file + bind-mount.
Flatpak relies on OSTree to report the progress, and
OSTree's progress report frequency fallbacks to 1 second.
Recently, however, OSTree received support for setting
custom update frequencies. Since it relies on GVariant
options, if the user has an older OSTree, it'll simply
be ignored.
This patch, then, makes Flatpak report progress every
100ms rather than the default value of 1 second.
flatpak/flatpak#609
We only allow globs, not magic matches, and we drop the glob
priority to a very low level (weight=5) which means that its
hard for app-installed mimetypes to override the system installed
ones. That should make exporting mimetypes pretty safe.
Installing a search provider is a minor security issue, as it
can see all that you search for in the desktop, so we rewrite
these so that they are always disabled by default. The user
can then chose to enable it if he wants.
Instead of exporting any files we add a whilelist
of directories that get exported:
share/applications
share/icons
share/dbus-1/services
share/gnome-shell/search-providers
share/mime/packages
This avoids potentially installing some kind of file that the
host system reads and interprets in a risky way.
Applications and dbus services are safe because we rewrite them.
Icons are safe as long as the image loaders are, and if they are
not we have worse problems.
Search providers and mime formats are somewhat problematic, and
follow-up commits will rewrite these to be safer.
We may have made decisions based on the permissions listed in the
metadata in the (signed, thus trusted) commit. However, at runtime
we actually look at the metadata file that is deployed. Make sure
these are the same by comparing them when we deploy.
When we're pulling via the system-child repo we don't inherit
the commitpartial state from the parent, so we didn't know a
commit was partial, so the full contents was not downloaded.
This fixes updating a partial install to the same commit, but
with different subsets.
We don't guarantee that the active link is identical to the
checksum anymore. If you really need the checksum you have
to look at the deploy data.
This is mainly changing the names from "checksum" to "active_id"
in the code that touches the active link, except the case where
we're undeploying after an update. We then use the old active
link value rather than the old commit id as the undeploy id.
This will allow us to have partial deploys with different names
than the full or differently partial deploy.
It turns out the underlying call ostree_repo_query_object_storage_size
doesn't work for staged objects, so we work around this by actually
loading the object, walking back to the original unix input stream
and fstat:ing the fd from that.
When clients install/update they will see this property in the
(signed) summary and update the url in the config, making this
essentially a permanent redirect.
We download the summary and send it to the system helper, it verifies
the checksum and applies the changes, with the same polkit permissions
required as for an app update (i.e. typically none).
This allows us to update metadata automatically, without permission
requests.
Whenever you explicitly specify some value (e.g. for
title or default-branch) we set a $KEY-is-set option
to True, and if that is set we never automatically update it.
The system-cache (summaries and temporary repos for downloads) are moved
from ~/.local/share/flatpak/system-cache to
~/.cache/flatpak/system-cache (or wherever XDG_CACHE_HOME is) because
this is the proper location for caches.
Fixes https://github.com/flatpak/flatpak/issues/767
This ensures that no processes from the build lives
past the return of the build itself, which might
accidentally happen.
We still allow apps to stay around after the regular
flatpak run command finished though, as this is sometimes
done on purpose.
If the app explicitly grants access to the host /tmp (for
instance telegram) then when this is being exposed as a symlink
in the sandbox we get an error because /tmp already exists
as a dir, which we create very early on.
It doesn't really make sense to keep /tmp as a symlink in
the sandbox anyway, so we just special case this and mount
the symlink target as /tmp.
This doesn't really change anything but renames a few functions and
introduces a FlatpakExports struct that is uses instead of the caller
open-coding a hashtable
We need to know if we're forwarding uris or files, because
if we're doing uris we need to pass on non-file uris as-is.
So, we enclose uris with "@@u @@" instead.
This also properly (un)escapes the file uris
