This is going to be a controversial one, so hold on tight.
Flatpak has been in development now for a few years and it’s really gaining more momentum. We have made progress, and it’s cool that I’ve been able to contribute to this endeavour. But as it is, we’re at risk of tripping over our own feet.
Let’s wind the clock back a few months. I distributed an important update for Lollypop, which reworks the filesystem access. As such, Lollypop is now mostly sandboxed and this really helps with the goal of Flatpakking. In the days that followed, I received numerous reports of people who could no longer access their music on a secondary harddrive or NAS. It turned out that they were running Flatpak 1.6.x.
This shined a light on a far bigger issue: The majority of Flatpak versions out there is outdated and about half the people that download packages from Flathub is doing so with 1.6 or lower.
This creates a security conundrum for two reasons:
- Users don’t have all available security patches (CVE)
- Flatpakking stagnates because clients miss newer features
I don’t think that we should let this run its cause. The statistics show a lot of trailing users that make up about 20% of our downloads, that will likely never update to a secure version. This should prompt us to take action.
There are many things that can be done to improve this situation. First, we should encourage distribution maintainers to update their Flatpak packages. Only last month was there another famous Linux distribution that shipped with 1.6.x. A shame, that could have been prevented.
But there is something else that can be done, something that can be done here at Flathub, and that will have a stronger long term effect: We could over time block outdated clients.
As every Android and Back-end developer will attest… it’s not a popular move. But, it’s the only thing that we can realistically do in the long term. How we do it though, can vary:
- We can leave it up to individual package maintainers
- We can slowly phase out old clients
- We can be crass and block all old clients
Now, the first option is already the case. Maintainers can already define a minimum version, although it is almost never used. As a maintainer, you don’t one to be the only one pulling the trigger on such a sensitive issue. The third option is also not really desirable, because we don’t want to victimise individual users.
So, that’s what brings me to the Post’s title. Let’s discuss the issue about slowly blocking outdated clients so that they don’t become a millstone around our necks.
- Where to start? Everything < 1.2?
- How to announce? How long ahead?
- What do we discuss with (commercial) maintainers? Opt-out options?