Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
BOF GUADEC 2017
Flatpak BOF GUADEC 2017
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.
- 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?
dconf / sandbox dbus
- 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
SSL certs from host
- 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?
- 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?
- 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
- 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
- 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?