The Flatpak Verification Problem

I remember the days when running Linux as a desktop OS was more of a dream than a reality, simply because the software I needed wasn’t available. I wasn’t alone in this frustration. For years, the biggest hurdle for people wanting to use Linux was the lack of software availability.

Several factors have historically worked against Linux in this regard. First, desktop Linux has always had a relatively small market share, making it difficult to attract the attention of software companies. For decades, Linux barely managed to capture 2% of the desktop OS market. Few companies are willing to invest resources to cater to such a small fraction of users. This creates a classic chicken-and-egg problem: companies don’t want to develop Linux-compatible software for such a small user base, but the user base remains small because the software isn’t available or easy to access.

The situation is further complicated when companies do decide to support Linux. They quickly encounter the fragmentation within the Linux ecosystem. Should they package their software as a .deb, an .rpm, an AppImage, or something else? Linux users are understandably frustrated when something works on Ubuntu but not on Fedora, Arch, or other distributions. This fragmentation means that company X has to put in five times the effort just to satisfy 2% of the market.

The result? Linux has long remained a second-class citizen when it comes to software support.

Flatpak to the rescue

In 2015, Flatpak emerged, bringing with it a renewed sense of hope for the Linux community. The goal of Flatpak was to create a universal packaging format that could work seamlessly across any Linux distribution. As long as a distribution had the Flatpak runtime installed, users could install the same software regardless of their chosen distro. Around the same time, Flathub was established as the de facto standard repository for apps, much like DockerHub serves as the go-to source for Docker images.

For the first time, we had a unified target for packaging apps, making them accessible to everyone. With the exception of Ubuntu and its controversial Snap format, most distributions embraced Flatpak. Many even began shipping with Flatpak and Flathub enabled out of the box. This meant that a user could install a distribution like Linux Mint and, within minutes, have essential applications like Chrome, Zoom, Spotify, Discord, and Telegram up and running.

This wasn’t just a vast improvement over the old days of Linux; it made Windows and macOS seem clunky and difficult to use by comparison. For once, Linux had become the easiest option available to users.

The result? As I write this in 2024, the desktop Linux market share has doubled to 4% and continues to grow. While 4% may still seem modest, the momentum is undeniable.

Why we can’t have nice things

While Flatpak and Flathub have been a tremendous technical and community success, they’ve also attracted some bad actors who have started to undermine the ecosystem.

Despite Flatpak’s popularity on Linux, major companies like Zoom, Google, and Spotify do not publish or maintain their own apps on Flathub. Instead, it’s common for community members to “repackage” these apps to make them available on Flathub. For example, while Google doesn’t release a Flatpak version directly, they do provide a .deb file. Honest and dedicated members of the community will take that .deb, repackage it, and make it accessible on Flathub, allowing everyone to benefit. This collaborative spirit is a cornerstone of the Linux and open-source world.

However, this model also opens the door to potential abuse. There’s nothing stopping someone with malicious intent from adding harmful code to a repackaged program and publishing it as a legitimate app on the store. This issue has plagued Canonical’s Snap store, where crypto scams were hidden in seemingly legitimate apps, leading to financial losses for unsuspecting users. Not good at all.

Enter Verification

Flathub responded to these threats by introducing a verification step, which indicates whether an app is published directly by its author. This allows users to make an informed decision when downloading an app, especially those that handle sensitive data, choosing whether to trust a repackaged version or opt for the one verified by the original author.

Initially, this seemed like a reasonable approach, starting with a simple verified badge on apps, similar to the optional verified badges on platforms like Facebook and Twitter. However, things have escalated. Now, unverified apps don’t just lack the badge; they also come with a red warning label stating “UNVERIFIED.” What was once a subtle endorsement of trust has morphed into a stark warning that seems to imply, “All other apps are unsafe,” which unfairly impacts the many legitimate repackaged apps contributed by honest community members.

The situation worsened with the release of Linux Mint 22, where the app store no longer displays unverified apps by default. This means that new users who install Linux Mint may open the software manager and find that popular apps like Google Chrome, Zoom, or Spotify are nowhere to be found. Even fully open-source games like SuperTuxKart are now flagged as “unsafe.”

While it is possible to disable this filtering by adjusting the settings to re-enable unverified apps, users are met with strong warnings about the potential risks, which are likely to deter most people. This development risks taking us back to the days when users felt they couldn’t run their preferred software on Linux.

Where do we go from here?

I completely agree that we need a safety net to ensure users can trust the apps they’re downloading. However, this overly aggressive stance on verification feels too restrictive and may end up deterring users. While it’s important to protect people from scams, we also don’t want Linux to be perceived as difficult or unusable.

In an ideal world, companies like Google, Zoom, and Spotify would take ownership of their Flatpak versions and manage them directly, making them verified. But we can’t rely solely on this happening, so it’s crucial to establish a more balanced system of trust.

What are your thoughts?