To avoid the complexities of passing (and chaining) OstreeAsyncProgress
objects around, we only create one just before calling to ostree.
The rest of flatpak only ever uses the new FlatpakProgress object.
Co-authored by: Philip Chimento <philip@endlessm.com>
Instead of having a global config option we scan a directory for
symlinks into the sideload repos. These come from
/var/lib/flatpak/sideload-repos and /run/flatpak/sideload-repos (for
default system installation).
This is much easier to update atomically, and the two different
options are useful for persistant (the first) or dynamic (the second)
usescase.
Fixes https://github.com/flatpak/flatpak/issues/3494
This is a new version of --deploy-collection-id that only applies
the collection id update for new (1.7.x+) version of flatpak clients.
This allows you to enable collection ids for sideload use but not
affect older clients where the p2p codepaths are not as tested.
New users who jump directly into this command might think this command is to init a project or application dictionary but it actually creates somehow a directory for *built* app to run inside.
plus, fix not working example
Sorry for such minor and boring commit.
These are subsets of the host keyword, which provide access to operating
system files but not to users' personal files.
In particular, the experimental support for namespace-based sandboxes
in the Steam Runtime[1] uses the graphics stack from the host system,
which requires access to the host /usr/libQUAL, /libQUAL (even if the
host OS has undergone the /usr merge, the canonical paths of ELF
interpreters start with /lib), /etc/ld.so.cache, and for some libraries
on Debian-based systems, /etc/alternatives. It will not be possible to
do similar things in Flatpak without either allowing full host
filesystem access (which exposes personal files, and in any case cannot
be done by the Steam app because it is incompatible with --persist=.),
or adding the ability to expose /usr and related directories without
including the rest of the host filesystem.
To the best of my knowledge, host-etc is not necessary for anything;
I've mainly provided it for symmetry, since it's the other significant
thing that we mount in /run/host and cannot get via --filesystem=/path.
Some notes on the security/privacy implications of the new keywords:
- Neither new keyword allows anything that was not already allowed
by "host".
- Neither new keyword can allow anything that was not already allowed
to the user outside the sandbox.
- "host-os" allows enumeration of the installed packages on the host
system, and often their version numbers too. A malicious app could
use this to look for exploitable security vulnerabilities on the
host system. An app could also use this for fingerprinting, although
this is not a regression, because the systemd/D-Bus machine ID,
MAC addresses, hostname, kernel boot UUID, DMI product ID and many
other unique or relatively unique properties are already available
inside the sandbox.
- "host-os" allows read access, and possibly write access (if the user
has it outside the sandbox, for example members of group 'staff' in
older Debian installations), to /usr/local.
- "host-etc" allows reading configuration files whose contents might
be considered sensitive, such as /etc/passwd.
[1] https://steamcommunity.com/app/221410/discussions/0/1638675549018366706/
Signed-off-by: Simon McVittie <smcv@collabora.com>
This new permission exposes the host /dev, which is normally not visible
even with --device=all, as it is not really a device node but rather
a bunch of shared memory blocks available on the host.
This access is needed by jack, as explained at:
https://github.com/flatpak/flatpak/issues/1509
Long term I think a better solution for pro audio (like pipewire) is
a better solution, but for now we should at least allow jack apps to work.
Also update the tests to use the same format, and make sure to include
coverage of all forms of locale (language-only, with locale, with
codeset, and with modifier).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In order to configure gnome-software to show specific apps in one region
without showing to all language speakers, we allow the storage of full
locales on the extra-languages key. However, these locales are ignored when
calling flatpak_installation_get_default_languages, so locales will be reduced
to their language identifier (eg. en_IN locale will be returned as 'en', and
az_Latn_AZ will be returned as 'az'). In order to get the full locales, we can
call flatpak_installation_get_default_locales instead, which can return languages
and locales.
