Flatpak 1.0 blockers

[Alexander Larsson]

I'm currently looking at the state of flatpak and considering what it
would take to call flatpak 1.0. By this I mean not minor bugs, there
will always be bugs, but what features we need in flatpak (and the
surrounding areas) for being able to run most apps and support all the
important features.

Here is the list of things I came up with (and i made a "1.0 Blockers"
milestone in the github issue tracker for tracking these):

(Note: Not all of these are necessary changes in flatpak itself, some
just need work in the lower layers of the stack)

* Accessibility support #79

 Currently it is not possible for sandboxed apps to use a11y. I looked
 at this at some point, and due to the accessibility stack using its
 own dbus bus it was tricky to allow access to this without special
 code in flatpak, and the way a11y works menas doing so would open
 up the sandbox in a really bad way. This needs some serious work at
 the a11y stack level to really be fixed.

* ibus (#675)

 IBus (input methods) don't currently work in flatpak for similar
 reasons as a11y. There is some ongoing work to make it work better 
 though.

* Recursive sandboxes - (#953)

 Many apps now want to run parts of themselves in a sandboxed fashion.
 For instance for the gdk-pixbuf loaders, or the chrome
 sandbox. Unfortunately bubblewrap does not work recursively, for
 security reasons, so we will need some form of portal to spawn new
 sandboxes which inherit the settings and then apply even tigher
 permissions.

* update/restart yourself portal (#444)

 Several applications want some kind of integration with updates in 
 the UI. Its currently possible to detect when something outside your 
 sandbox caused  your app to update, but there is no nice way to 
 request to be re-started, nor is there a way to know that there is an 
 update available that you can install. It would be nice to have a 
 story here.

* Expose host-side SSL cert (#677)

 Flatpak runtimes currently ships with their own ca-certificates to 
 make ssl work. This isn't great as it has to be updated, and it does 
 not pick up site-specific certificates. We need a standard way to 
 expose the host certs to the sandbox that is cross-distro and safe. 
 The github issue describes a possible way forward.

* permission requests presentation (#275)

 Each flatpak can request a set of static permissions on installation 
 time. However, currently we never display these to let the user decide
 what to do with them. We need to figure out a nice way to present 
 these in a UI to let the user decide on them and possibly override 
 them.

* Fontconfig cache performance (#589)

 The flatpak sandbox currently exposes the system font, but in a 
 different location than they have outside (they show up in 
 /run/host/fonts). This means the pre-existing caches on the host made 
 by fc-cache will not work, because they hardcode absolute pathnames. 
 There is some initial work upstream to make the caches relocatable,
 we want to get that in and ensure it works.

* Webcam Support (Pipewire) (#83)

 PipeWire (https://github.com/wtay/pipewire) was specifically created 
 to allow nice support of webcams in the flatpak sandbox. We need to 
 make sure it is stabilized and supported by flatpak.

* OCI 1.0 support (#960)

 The OCI spec 1.0 version was recently finalized. We need to make sure 
 that the OCI support in flatpak is up-to-date and is working with 
 other implementations.

* Proxy-less dbus filtering (#962)

 There is work upstream to make dbus natively do the kind of filtering
 and sandbox awareness that is needed for flatpak and portal support. 
 When this is in we need to make flatpak (and xdg-deskopt-portal) be 
 able to use this if available instead of the current proxy.

* Sandboxed DConf support (#78)

 Currently there is no nice way for apps to have DConf access without a
 bunch of magic permissions. There are some upstream plans and code for
 how this should work, but these are currently blocking on the dbus
 filtering feature to land.

* udev (#961)

 libudev is not currently in the runtime because it only partially 
 works in the sandbox. Everything that depends on sysfs parsing will 
 work, but we don't expose the udevd database to the sandbox, because 
 upstream says it is not on-disk compatible between different versions 
 of udev. This has been an issue with some things though, for instance 
 for the steam controller support, so we need to re-check with 
 upstream and see if the status of this has changed or if we can do 
 something about it.

* work with empty /var/lib/flatpak (#113)

 The p11ykit helper for flatpak only works if /var/lib/flatpak has some
 minimal file setup. This is solved in typical packages by running
 a trivial flatpak command as root in a post-install snippet. However
 that doesn't really work in some situtions, such as for instance
 image-based deployments with empty /var. We need a proper fix for
 this.

* Tombstones for app delete/rename (#963)

  Apps sometimes changes name, or gets deprecated. Currently this is
  not supported in flatpak repos. We should support some kind of
  tombstone commit so that the UI could do the right thing when
  the user runs into these situations.

These are the most important larger issues I could think of. Does
anyone have any ideas about important things I've missed?

Many of these issues are large and if anyone is interested in helping
out I would love that.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's a sword-wielding alcoholic firefighter on the hunt for the last 
specimen of a great and near-mythical creature. She's a radical insomniac 
mercenary from a secret island of warrior women. They fight crime!