Needed for stuff like thumbnailers/pixbuf loaders and browser sandboxes if they are to be run inside Flatpak. At present newly added support for sandboxing gnome-desktop thumbnailers is disabled when the app is inside Flatpak, arguably lowering security.

Starting new user namespaces is a privileged operation which is impossible inside a Flatpak sandbox, and other things like Chrome's sandbox setuid helper also fail.

Prototype something based on the Host command but have it start the command in a sandbox with the same r/o /usr and /app as the flatpak.

Filed as https://github.com/flatpak/flatpak/issues/953

• host extension point is already provided (see https://github.com/flatpak/flatpak/blob/master/NEWS#L566)
• works for stuff like nvidia and mali where the driver is already very slim on host dependencies
• some distros like Fedora already build Mesa with static stdc++/boost/etc to lower this problem
• the distro can just put this in the right path for the "host" thing to pick it up
• provide a script for other distros that copy the GL driver in
• is other stuff needed? libcapsule? or is this the responsibility of the system vendor?

• Allison is waiting for smcv's stuff to land before we can move fwd on dconf
• Alex hoping to review sandbox stuff

• not really stable protocol or used in apps at present
• forward/backward compatibility with current PulseAudio using apps is a problem
• client stuff in the runtime can support falling back depending on what the host has, eg gstreamer
• however old apps can still be a problem - maybe we need a host daemon on demand that listens on pulseaudio protocol but talks to pipewire

• maybe we could have a /run/host/ssl-certificates that flatpak binds from the host, which is distro-specific build-time configuration
• however this has serious limitations- different SSL stacks use different file formats
• ultimately we want a d-bus service to verify certificates from the host system
• there's a thing coming (PKCS7 plugin?) ... details needed

• Steam and monodevelop use 32-bit libraries
• we have 32-bit runtimes included in 64-bit apps as an extension, but building against 32-bit stuff isn't possible
• can the 32-bit app build export an extension for the 64-bit app?
• could be useful to allow apps to define extension exports
• kind of bad because it's replicating complexity of locales and stuff
• maybe runtime could just include the 32-bit libc and gcc...?

• default configuration provided inside the runtime, but also grabs host fonts from /run/host for user and system fonts
• the caches don't get re-used because the caches are dependent on the absolute path, kills first startup time
• patches to make the fontconfig caches relative to the base dir are WIP, see https://bugs.freedesktop.org/show_bug.cgi?id=101889
• for config, we could have a helper to parse all the config, patch/filter the paths, return it to the sandbox?
• session helper?

• use cases - new content/extensions/etc available, or notification to user that app is updated and it could/should restart
• could be solved from outside in the app center
• flatpak already has support for adding updated/removed files to deployed apps
• but no notification currently for extensions being added
• useful stuff from session helper
• restart seamlessly
• app can arrange this by re-execing itself
• ask to be restarted
• session helper thing - re-execute with the new deployment?

• matthias has PR for flatpak to have a setting for locales
• system-wide is all at present but could be changed
• eg Endless has image defaults
• ask AccountsService for languages

• alternatives exist like fcitx (?!) but it doesn't stop you from having the same input methods over ibus
• the daemon has a private dbus listener
• the input method is in a different process
• uncontained access to this protocol is probably unsafe unless we do some auditing...
• the idea was to produce a new portal.IBus service/interface which handed out constrained private connections out using FD passing
• further discussion is on https://github.com/flatpak/flatpak/issues/675

• e.g. for removable disks
• gvfs too course-grained at the moment, access to the daemon is access to all
• removable disk / remote mount portal?
• access to optical disks too
• DVD playback
• USB sticks for boxes kinda thing
• block portal?
• joysticks
• wayland protocol is coming, so game input will be sent to current window if requested
• serial devices
• stuff like arduino
• does everything just need it's own portal in the end?

• OpenQA
• would be very cool to run/test/screenshot apps
• we want to do some recipe analysis on the JSON files
• eg cve-scan-tool
• and some post-build analysis on the artefacts (including extra data when unpacked)
• app stream validate
• coverity
• we could do the tracing but not get/require results
• should/could we set global cflags
• hardening options...?
• what can you do to scan for potential issues
• CVE scanner? clamav?
• license scanning?
• who is it protecting?
• for apps: the idea is that the uploader is responsible for the claimed licence(s)
• for runtimes: difficult to be sure - advice needed

• eg mozilla, if they publish their stuff as binaries
• do we have/want a way to point to 3rd party remotes / refs / etc?

• cosimo is updating the base app, will upload it
• electron apps can then be built provided they have their node dependencies flattened with yarn

• gnome runtime definitions can be shared with gnome
• freedesktop?
• based on yocto :/
• not possible to programmatically import the source recipes
• general goal is that we want to move towards buildstream native recipes for all modules
• start by importing the yocto layer as binary
• move modules to the freedesktop layer progressively / make a new buildstream base layer
• apps - json format is easier for now

• lifecycles are currently very undefined
• although Flathub can provide some "peer pressure" for people to update, but part of the point of Flatpak is that people can not update but rely on security updates
• has maintenance cost/effort - just like an LTE distro
• nobody really signed up to give this support yet, but we'll need to see where apps "end up" in terms of runtime use
• we'll need the ability to EOL runtimes eventually
• mark it out of date so that the user can be warned via GNOME Software about installing apps that use it still?