The Future of Flatpak

At the Linux Application Summit (LAS) in April, Sebastian Wick said that, by many metrics, Flatpak is doing great. The Flatpak application-packaging format is popular with upstream developers, and with many users. More and more applications are being published in the Flathub application store, and the format is even being adopted by Linux distributions like Fedora. However, he worried that work on the Flatpak project itself had stagnated, and that there were too few developers able to review and merge code beyond basic maintenance.

I was not able to attend LAS in person or watch it live-streamed, so I watched the YouTube video of the talk. The slides are available from the talk page. Wick is a member of the GNOME Project and a Red Hat employee who works on "all kinds of desktop plumbing", including Flatpak and desktop portals.

Flatpak basics

Flatpak was originally developed by Alexander Larsson, who had been working on similar projects stretching back to 2007. The first release was as XDG-App in 2015. It was renamed to Flatpak in 2016, a nod to IKEA's "flatpacks" for delivering furniture.

The Flatpak project provides command-line tools for managing and running Flatpak applications, tools for building Flatpak bundles, and runtimes that provide components for Flatpak applications. The project uses control groups, namespaces, bind mounts, seccomp, and Bubblewrap to provide application isolation ("sandboxing"). Flatpak content is primarily delivered using OSTree, though support for using Open Container Initiative (OCI) images has been available since 2018 and is used by Fedora for its Flatpak applications. The "Under the Hood" page from Flatpak's documentation provides a good overview of how the pieces fit together.

Slowing development

Wick started his talk by saying that it looks like everything is great with the Flatpak project, but if one looks deeper, "you will notice that it's not being actively developed anymore". There are people who maintain the code base and fix security issues, for example, but "bigger changes are not really happening anymore". He said that there are a bunch of merge requests for new features, but no one feels responsible for reviewing them, and that is kind of problematic.

$ sudo subscribe today

Subscribe today and elevate your LWN privileges. You’ll have access to all of LWN’s high-quality articles as soon as they’re published, and help support LWN in the process. Act now and you can start with a free trial subscription.

The reason for the lack of reviewers is that key people, such as Larsson, have left the project. Every now and then, Wick said, Larsson may get involved if it's necessary, but he is basically not part of the day-to-day development of the project. Wick said that it is hard to get new Flatpak contributors involved because it can take months to get feedback on major changes, and then more months to get another review. "This is really not a great way to get someone up to speed, and it's not a great situation to be in."

"Maybe I'm complaining about something that is actually not that much of an issue", he said. Flatpak works; it does its job, and "we just use it and don't think about it much". In that sense, the project is in a good spot. But he has still been thinking about how the project is "living with constraints" because contributors do not have the opportunity to go in and make bigger changes.

As an example, Wick said that Red Hat has been doing work that would allow Flatpaks to be installed as part of a base installation. The vendor or administrator could specify the applications to be installed, and a program called flatpak-preinstall would take care of the rest. The feature has been implemented and is planned for inclusion in Red Hat Enterprise Linux (RHEL) 10. The work was started by Kalev Lember and Owen Taylor last June, but the original pull request was closed by Lember in February as he was leaving Red Hat and would not be working on it anymore. It was picked up by Wick in February as a new request but wasn't reviewed until early May.

OSTree and OCI

Wick's next topic was OCI support in Flatpak. While OSTree has been a success in some ways, and it is still being maintained, it is not undergoing active development. He noted that developers have a "very narrow set of tools" for working with OSTree, so building Flatpaks that use OSTree requires non-standard and bespoke tools, but there is a whole range of utilities available for working with OCI images. Even better, tools for working with OCI images "are all developed by people other than us, which means we don't actually have to do the work if we just embrace them".

Unfortunately, there are a number of OCI-related improvements that, again, are waiting on review to be merged into Flatpak. For example, Wick mentioned that the OCI container standard has added zstd:chunked support. Instead of the original OCI image format that uses gzipped tarballs, the zstd:chunked images are compressed with zstd and have skippable frames that include additional metadata—such as a table of contents—which allows file-level deduplication. In short, zstd:chunked allows pulling only those files that have changed since the last update, rather than an entire OCI layer, when updating a container image or a Flatpak.

There is a pull request from Taylor, submitted in September 2023, that would add support to Flatpak for zstd-compressed layers. It has received little attention since then and "it's just sitting there, currently".

Narrowing permissions

One of the key functions of Flatpak is to sandbox applications and limit their access to the system. Wick said that the project has added features to "narrow down" the sandboxes and provide more restricted permissions. As an example, Flatpak now has --device=input to allow an application to access input devices without having access to all devices.

One problem with this, he said, is that a system's installation of Flatpak may not support the newer features. A user's Linux distribution may still be providing an older version of Flatpak that does not have support for --device=input, or whatever new feature that a Flatpak developer may wish to use. Wick said there needs to be a way for applications to use the new permissions by default, but fall back to the older permission models if used on a system with an older version of Flatpak.

This isn't an entirely new situation, he said. "We had this before with Wayland and X11", where if a system is running Wayland, then Flatpak should not bind-mount an X11 socket. Now, there is a similar scenario with the xdg-desktop portal for USB access, which was added to the xdg-desktop-project in 2021. Support for that portal was merged into Flatpak in 2024 after several iterations. What is missing is the ability to specify backward-compatible permissions so that a Flatpak application can be given USB access (--device=usb) with newer versions of Flatpak but retain the --device=all permissions if necessary. Once again, there is a pull request (from Hubert Figuière) that implements this, but Wick said that "it's also just sitting there".

Wick would also like to improve the way that Flatpak handles access to audio. Currently, Flatpak still uses PulseAudio even if a host system uses PipeWire. The problem with that is that PulseAudio bundles together access to speakers and microphones—you can have access to both, or neither, but not just one. So if an application has access to play sound, it also has access to capture audio, which Wick said, with a bit of understatement, is "not great". He would like to be able to use PipeWire, which can expose restricted access to speakers only.

One thing that has been a bit of a pain point, Wick said, is that nested sandboxing does not work in Flatpak. For instance, an application cannot use Bubblewrap inside Flatpak. Many applications, such as web browsers, make heavy use of sandboxing.

They really like to put their tabs into their own sandboxes because it turns out that if one of those tabs is running some code that manages to exploit and break out of the process there, at least it's contained and doesn't spread to the rest of the browser.

What Flatpak does instead, currently, is to have a kind of side sandbox that applications can call to and spawn another Flatpak instance that can be restricted even further. "So, in that sense, that is a solution to the problem, but it is also kind of fragile." There have been issues with this approach for quite a while, he said, but no one knows quite how to solve them.

Ideally, Flatpak would simply support nested namespacing and nested sandboxes, but currently it does not. Flatpak uses seccomp to prevent applications in a sandbox from having direct access to user namespaces. There is an API that can be used to create a sub-sandbox, but it is more restrictive. He said that the restrictions to user namespaces are outdated: "for a long time it wasn't really a good idea to expose user namespacing because it exposed a big kernel API to user space that could be exploited". Wick feels that user namespaces are, nowadays, a well-tested and a much-used interface. He does not think that there is much of a good argument against user namespaces anymore.

xdg-dbus-proxy

Flatpak applications do not talk directly to D-Bus. Instead, flatpak-run spawns an xdg-dbus-proxy for every Flatpak instance that is "not exactly in the same sandbox, it's just on the side, basically". The proxy is responsible for setting up filtering according to rules that are processed when flatpak-run is used to start an application. When setting up the proxy, Flatpak starts with a deny-all state and then adds specific connections that are allowed. This is so that applications do not expose things that other applications are not supposed to use.

Wick said that he would like to move filtering from xdg-dbus-proxy directly to the D-Bus message brokers and provide policy based on a cgroups path. This is not something that has been implemented already, but he said he planned to work on a prototype in busd, which is a D-Bus broker implementation in Rust.

That would also allow for a more dynamic policy, which would allow applications to export services to other applications on the fly. Currently, the policy is set when a Flatpak is run, and can't be modified afterward.

As a side note, that means that Flatpak applications cannot talk to one another over D-Bus. They can still communicate with other applications; for example, Wick said that applications can communicate over the host's shared network namespace, "which means you can use HTTP or whatever, there are like thousands of side channels you could use if you wanted to".

Flatpak's network namespacing is "kind of ugly, and I don't really have a good solution here", Wick said, but he wanted to point out that it is something the project should take a look at. "Like, you bind something on localhost and suddenly all applications can just poke at it". He gave the example of AusweisApp, which is an official authentication app for German IDs that can be used to authenticate with government web sites. It exposes a service on the local host, which makes it available to all Flatpak applications on the system.

This is some of the stuff that I feel like we really need to take a look at. I'm not sure if this is like directly exploitable, but at the very least it's kind of scary.

Wick said that the project needs to create a network namespace for Flatpak applications, "but we don't really have any networking experts around, which is kind of awkward, we really have to find a solution here".

Another awkward spot the project finds itself in, he said, is with NVIDIA drivers. The project has to build multiple versions of NVIDIA drivers for multiple runtimes that are supported, and that translates to a great deal of network overhead for users who have to download each of those versions—even if they don't need all of the drivers. (This complaint on the Linux Mint forum illustrates the problem nicely.) It also means that games packaged as Flatpaks need to be continually updated against new runtimes, or they will eventually stop working because their drivers stop being updated and the games will not support current GPUs.

Wick's suggestion is to take a cue from Valve Software. He said that Valve uses a model similar to Flatpak to run its games, but it uses the drivers from the host system and loads all of the driver's dependencies in the sandbox for the game. Valve uses the libcapsule library to do this, which is "kind of fragile" and difficult to make sure that it works well. Instead of using libcapsule, he would like to statically compile drivers and share them between all Flatpak applications. This is just in the idea stage at the moment, but Wick said he would like to solve the driver problem eventually.

Portals

Portals are D-Bus interfaces that provide APIs for things like file access, printing, opening URLs, and more. Flatpak can grant sandboxed applications access to portals to make D-Bus calls. Wick noted that portals are not part of the Flatpak project but they are crucial to it. "Whatever we do with portals just directly improves Flatpak, and there are a bunch of portal things we need to improve".

He gave the example of the Documents portal, which makes files outside the sandbox available to Flatpak applications. The Documents portal is great for sharing single files, but it is too fine-grained and restrictive for other applications, such as Blender, GIMP, or music applications, that may need to access an entire library of files. "You want a more coarse-grained permission model for files at some point". There are some possibilities, he said, such as bind mounting user-selected host locations into the sandbox.

Wick had a number of ideas that he would like to see implemented for portals, such as support for autofilling passwords, Fast Identity Online (FIDO) security keys, speech synthesis, and more. He acknowledged that it's "kind of hard to write" code for portals right now, but there is work to make it easier by using libdex. (See Christian Hergert's blog post on libdex for a short look at this.) It might even make sense to rewrite things in Rust, he said.

Flatpak-next

Assume that it's ten years in the future, Wick said, and no one is working on Flatpak anymore. "What would you do with Flatpak if you could just rewrite it? I think the vision where we should go is OCI for almost everything." Larsson's choices in creating Flatpak were good and sound technical decisions at the time, but they ended up being "not the thing that everyone else has". That is an issue because only a few people understand what Flatpak does, and the project has to do everything itself.

But, he said, if the project did "everything OCI", it would get a lot of things for free, such as OCI registries and tooling. Then it just comes down to what flatpak-run has to do, and that would not be very much. Rethinking Flatpak with modern container tools and aligning with the wider container ecosystem, he said, would make everything easier and is worth exploring. Once again, he floated the idea of using Rust for a rewrite.

Q&A

There was a little time for questions at the end of Wick's session. The first was about what happens to existing Flatpaks if the project moves to OCI tooling. "Would I need to just throw away [applications] and download again, or is that too much in the future, and you haven't thought about that?" Wick said that it would be an issue on the client side, but Flathub (for example) has all of the build instructions for its Flatpaks and could simply rebuild them.

Another audience member was concerned about using container infrastructure. They said that OCI registries that store images are missing indexing and metadata that is consumed by applications like GNOME Software for Flatpaks. What would be the way forward to ensure that they could preserve the same user experience? Wick said that there is now a standard for storing non-images in OCI registries, which would allow storing "the same things we're currently storing" for Flatpak, but writing the code to do it and getting it merged would be the hard part.

The final question was whether there was anything concrete planned about using PipeWire directly with Flatpak rather than the PulseAudio routing. Wick said that he had been talking with Wim Taymans, the creator of PipeWire, about how to add support for it within Flatpak. It is mostly about "adding PipeWire policy to do the right thing when it knows that it is a Flatpak instance", he said.