Some Flatpak updates

6 Comments

Flatpak development is not standing still. Here is a quick summary of recent and coming changes.

Better extensions

In 1.4.2, Flatpak gained the ability to use extra-data for extensions. This mechanism has been around for applications for a long time, but it is a new feature for extensions.

The 19.08 version of the freedesktop runtime uses it for its new org.freedesktop.Platform.openh264 extension, which uses the Cisco openh264 builds.

Since we are taking the ‘run everywhere’ aspect of Flatpak seriously, we’ve backported this feature from the 1.4 branch to older stable branches and released 1.2.4 and 1.0.9, so even users on very stable distributions can enjoy this new feature.

Future plans

We’ve quietly started to work on Flatpak 1.6, which should be out before the end of the year.

On the roadmap for the this release, we have

  • Support for masking updates and pinning apps.  This gives users more control about what updates Flatpak installs, without having to answer questions every time.
  • Parental controls. This optional feature uses libmalcontent to implement policies about what applications users can install and run, based on OARS content ratings.
  • Disk space checks. This is an ongoing effort to improve the accuracy of our disk- and download-size handling and to handle low disk space situations more gracefully.
  • Infrastructure for purchases/donations. This is still a bit of a research topic.

You can follow the discussion around these features, the flatpak roadmap and general flatpak topics on the flatpak mailing list.

Coming soon to portals

Things are happening on the portal side too. Some of these have already landed, and will appear in a release soon.

Secrets

We have a secrets portal now.  It works by providing a master secret to the sandboxed app, which is then used to store the applications secrets in an encrypted file inside the sandbox . The master secret is stored in the session keyring.

This is nice in that applications don’t leave their secrets behind in the keyring when they are uninstalled, and the application secrets are safe from others.

The backend for this portal will be provided by gnome-keyring and libsecret will automatically use it inside a sandbox. Backend implementations for other environments are more than welcome.

The secret portal is the work of Daiki Ueno, who gave a talk about it at Guadec.

Self-updates

The Flatpak commandline and tools like Discover or the Elementary app store do a fine job of handling updates for Flatpak apps and runtimes.

But the reality is that self-updating is a popular feature for applications, so we added an update portal that lets them do this in a clean way, with proper integration in the Flatpak machinery.

Backgrounds 1

The background portal monitors applications that are running in the background (without open windows). It gives apps a way to request permission to run in the background, and it notifies users when apps are trying to do so sneakily without permission. The portal also lets applications request to be started automatically when the user logs in.

To implement this, the portal needs information from the compositor about open windows, and which applications they belong to. Currently, this is implemented for gnome-shell, other backends are more than welcome.

Window sharing

The screencast portal now lets you select individual windows, in addition to screens, if the application asks for this.

For now, the portal identifies windows by the application icon and window title. We are looking to improve this by using thumbnails.

Backgrounds 2

We will add a small bit of desktop integration with a portal for setting desktop wallpapers.

A portal library

In the ideal case, portal functionality is used transparently by existing desktop libraries without the need for apps to do anything special. Examples for this are GtkFileChooserNative using the file chooser portal, or libsecret using the new secret portal.

But for some portals, there is no natural library api, and in these cases, doing the portal interaction with D-Bus calls can be a bit cumbersome.

Therefore, we are working on a libportal library that will provide GIO-style async apis for portal requests.

Open for contribution

If you want to get involved with Flatpak development, or are just curious, check out the flatpak project on github, chime in on the Flatpak mailing list, or find us on IRC in #flatpak on freenode.

6 thoughts on “Some Flatpak updates”

  1. Everything you just said is the most beautiful music to my ears, but please define “Self-updates” as I’m a bit concerned and paranoid after seeing how a well known competing technology handled it…

    Please tell autoupdates will always remain optional at the user level (<TLDR). There are situations where autoupdates can be useful, but the forced nature of Snaps was one of the main reasons for me to migrate to all-Flatpak (which I so far love). I think the perfect situation would be if you as a user could pick which apps individually you'd like to keep autoupdated. Like for example for me personally it would be fine if my music player always autoupdated, but some tool I depend on for work to autoupdate would never have been acceptable as I need time to learn what's new with the software first and that it actually still suits my personal workflow or if I have to refine it. Nobody wants a fuckup on a meeting where your software changed 3 minutes before the meeting. The forced and hidden autoupdate as with Snaps is totally insane and is just asking for future trouble, the user must always remain in charge to chose what suits their personal needs. That I feel Flatpak has done a superb job with so far, will it remain being the superb sandboxing technology?

    1. With self-updates, I mean that a running application can find out that there is an update for itself available (from the remote that the app was installed from), and then it can tell flatpak to install this update. Since this is done via a portal, there is a permission that the user can set to prevent an application from doing this. And we are careful to not let applications install updates that require increased privileges in this way.

      Automatic updates are not a concept that flatpak itself has. App stores like GNOME Software can (and do) implement auto-updates, together with a user setting to disable them. Again, GNOME Software is careful not to apply updates automatically if they require increaed privileges.

  2. Hi. Thanks for the amazing work. Flatpak has already changed the way I use Linux because now the first thing that I do in any distro is enable flathub and get almost all my favorite software as flatpaks.
    I’d like to know how are the efforts to automatically convert RPM packages to flatpak. I heard this effort is ongoing on Fedora.
    Can a quantum chemistry package like nwchem, that depends on several libraries and openmpi be packaged as flatpak too?

    1. There is no reason the number of dependencies would prevent an app from being packaged with Flatpak. Just look at the number of dependencies bundled with some of the monster apps in Flathub:

      * Blender: https://github.com/flathub/org.blender.Blender/blob/master/org.blender.Blender.json
      * LibreOffice: https://github.com/flathub/org.libreoffice.LibreOffice/blob/master/org.libreoffice.LibreOffice.json

      Try building nwchem and see how it goes. We’ll be happy to help over in #flatpak on Freenode. 🙂

Comments are closed.