About two weeks ago we talked about why Fedora manages its own Flatpak repository, and why that sometimes leads to problems with upstream projects. Most recently, Fedora’s own OBS Flatpak was broken, leading to legal threats from the OBS project, demanding Fedora remove any and all branding from its OBS Flatpak. In response, Fedora’s outgoing project leader Matthew Miller gave an interview on YouTube to Brodie Robertson, in which Miller made some contentious claims about a supposed lack of quality control, security, and safety checks in Flathub.
These claims led to a storm of criticism directed at Miller, and since I follow quite a few people actively involved in the Flatpak and Flathub projects – despite my personal preference for traditional Linux packaging – I knew the criticism was warranted. As a more official response, Cassidy James Blaede penned an overview of all the steps Flathub takes and the processes it has in place to ensure the quality, security, and safety of Flathub and its packages.
With thousands of apps and billions of downloads, Flathub has a responsibility to help ensure the safety of our millions of active users. We take this responsibility very seriously with a layered, in-depth approach including sandboxing, permissions, transparency, policy, human review, automation, reproducibility, auditability, verification, and user interface.
Apps and updates can be fairly quickly published to Flathub, but behind the scenes each one takes a long journey full of safety nets to get from a developer’s source code to being used on someone’s device. While information about this process is available between various documentation pages and the Flathub source code, I thought it could be helpful to share a comprehensive look at that journey all in one place.
↫ Cassidy James Blaede
Flathub implements a fairly rigorous set of tests, both manual and automated, on every submission. There’s too many to mention, but reading through the article, I’m sure most of you will be surprised by just how solid and encompassing the processes are. There are a few applications from major, trusted sources – think applications from someone like Mozilla – who have their own comprehensive infrastructure and testing routines, but other than those few, Flathub performs extensive testing on all submissions.
I’m not a particular fan of Flatpak for a variety of reasons, but I prefer to stick to facts and issues I verifiably experience when dealing with Flatpaks. I was definitely a bit taken aback by the callousness with which such a long-time, successful Fedora project leader like Miller threw Flathub under the bus, but at least one of the outcomes of all this is greater awareness of the steps Flathub takes to ensure the quality, security, and safety of the packages it hosts.
Nothing is and will be perfect, and I’m sure issues will occasionally arise, but it definitely seems like Flathub has its ducks in a row.
Flatpak is a god send for complex applications like gimp and libreoffice, where the complexity of dependencies are going to grind problems, like python 2 dependencies and gtk 2, but even applications like OBS has advantages, at had a bug in a new version and OBS choose to don’t update it to guarantee functionality (ironically that was the problem with fedora flatpaks they updated that dependencie without knowing that it had a bug) the only other way to get that flexibility is with a very complex and radical different distro approach like NixOS
This response misses the mark. Flathub is hosting flatpak apps that have been packaged by people with no affiliation with their official projects that should not ever be packaged by random internet users. Period.
Let’s have a look, shall we?
Tuta mail – unverified package. Why is Flathub putting out an unverified version of an end-to-end encrypted email package that is used for super sensitive data?
Protonmail – unverified package
ProtonMail Import-Export app – unverified package
NordPass Password Manager – unverified package. What in the world?
Polypass, Proton Pass, AuthPass, Revelation Password Manager, Passy, EnPass, PassVault – unverified packages
Why would you ever use a password manager that wasn’t packaged by its developers? Why would Flathub ever host such things?
Wire – “The most secure collaboration platform” – unverified package.
Maurborgne – “2FA OTP Code Generator” – Why is Flathub hosting unverified OTP generators?
Keyring – “Simply beautiful or beautifully simple OTP generator.” – unverified package
What in the world is Flathub thinking? You just really do not do stuff like this, this is horrible that they are hosting these packages. And I’ve hardly even gotten started – I could list packages all day long that are a terrible idea for them to be hosting unless they are directly from the developers.
We live in a world where users are getting destroyed daily by AI-infused malware and ransomeware. Why in the world would you ever host unverified end-to-end encrypted communication apps and password managers?
If they are as trustworthy as Flathub claims, then why are not the original app developers stepping up and saying, “OK, I’ll verify this app that a rando packaged for Flathub”? You want to know why? Because those developers do not fully trust Flathub’s people or processes. And neither should the rest of us.
This same criticism could be made of literally any Linux distro’s package repository, and it seems the same safeguards are in place: you can choose to not install packages that aren’t endorsed by the upstream projects or aren’t built from source in the case of proprietary software. I choose not to install RPM Fusion’s nonfree repo on my Fedora systems, for example, but someone else might be willing to deal with the tradeoffs to have some proprietary software packaged neatly for them. As with a distro’s package management, you can inspect Flathub’s packages and see who contributed to them and what sources were used.
And the absence of an upstream developer’s involvement with a Flathub package doesn’t really say anything one way or another about that package. Developers have their own priorities and limitations, and some may prefer to let others package their software as has been the norm for Linux distros for a long time. Flathub encourages upstream participation, but that doesn’t mean upstream is obligated to participate. Just because a developer publishes a .deb and not a .rpm doesn’t mean they’re condemning RPM-based packaging.
>”This same criticism could be made of literally any Linux distro’s package repository”
Not true – my distro does not package their own version of Nordpass Password Manager. I highly doubt that any distro packages something like that. My distro does not package their own version of Wire or Maurborgne. Why would they? These are end-to-end encrypted communication apps and password managers that are made by specific companies or specific developers. You download the real verified app from their site or their repo, or you log in to their site to use the service online. You don’t just package your own version of someone else’s complex end-to-end encrypted communication app or password manager and toss it around all over the planet as if that’s a completely OK thing to do.
You seem to be confused about some aspects of what’s at play here, but the main thing I want to address is your misguided trust of proprietary software for anything security or privacy related. There’s a good reason NordPass wouldn’t be packaged in the official Fedora repos (as an example), and it’s because it’s proprietary and not for some false sense of security by obscurity. You should not trust software that can’t be built from source, whether you end up building it yourself of not. I wouldn’t trust my passwords for two seconds in a proprietary closed-source password manager, regardless of who packaged it. If NordPass is an example of anything, it’s an example of something no one should trust rather than something that should or shouldn’t be packaged in Flathub. For anything that is truly FOSS, there shouldn’t be any reason to fear someone building it for you as long as there’s a chain of trust and you can verify the sources.
I actually trust unverified packages *more* than verified. Sounds strange? That’s because it is!
A verified package can just be a binary uploaded by the developer. This means you need to not only trust this developer, but also trust they are an expert at build infrastructure and keeping it secure. Needless to say, almost no developer has the necessary skill set. Things such as verified Firefox builds by Mozilla are the notable exception here. But a random developer will probably just build a binary on their workstation and have a bunch of stuff installed on their workstation that would make every security-minded person run around in circles and scream.
Now, an unverified package: This is built on Flathub infrastructure, where there is a dedicated team to keep the build infrastructure secure. Builds are done from checked in instructions and are built as reproducible as is reasonably possible given current Flatpak limitations. Everybody can see how the package is built and trust the results as long as you trust Flathub infrastructure (and I trust it about as much as Fedora infrastructure – both projects really care about their build infrastructure and don’t just rent random VMs). Not every rando can change the build instructions, those are reviewed by Flathub developers.
So, as you can see, you can put a lot more trust in unverified applications than in verified applications (except for a few exceptions such as Firefox), because they actually get *more* checks and are guaranteed to be build on more trustworthy infrastructure.
>”Now, an unverified package: This is built on Flathub infrastructure, where there is a dedicated team to keep the build infrastructure secure.”
And yet, many developers do not trust Flathub’s people and processes enough to sign off on those “Flathub-infrastructure-built” packages enough to sign off on them and call them “verified”. Because they do not fully trust Flathub’s people and processes, as I said above. You aren’t making a novel argument that hasn’t already been considered – you are merely talking about your personal preference regarding ground that has already been covered.
A developer not taking ownership of a Flathub package doesn’t say anything about their trust one way or another. If they decline citing some dislike or distrust for Flathub, fine. But simply not engaging with Flathub doesn’t say anything about Flathub and its policies. Lots of upstream developers have little to nothing to do with Debian or Fedora packages of those projects. That doesn’t mean they disagree with or distrust Debian or Fedora.
What you’re really railing against is the lack of reproducible builds. It doesn’t matter how the software is packaged if the binaries produced can’t be verified to be what is in the repo. There are a lot of ways between point A and point B where code could be slipped in and no one would really know.
Flathub is a host. They aren’t doing anything. People are packaging software they want to run on their computers, just like a normal Linux distro, Homebrew, winget, etc.
It’s the same reason some devs only release in deb or Appimage. The devs can’t be bothered and don’t care. They have their preferred distribution method, and they’re good.
From the “Flathub Safety” article:
No it wasn’t. LOL
This is a revision of history. Security came second, dealing with dependencies, specifically graphics related deps, was the first objective. People figured out later that security could be added to Flatpak, which was great.
Security of the build pipeline and infrastructure might have been designed with security in mind though.
This is good. Reproducible builds should be standard in the industry.
This is a generic packaging squabble. Distros carrying patches for software is well known, Debian is especially know for this, and upstream gets mad about that too. There hasn’t been one this high profile in a while though, so all the newbies are eating up the drama.
Also, OBS is a special unicorn in the Flathub environment, per the article, and they would be especially sensitive if they’ve been given special treatment by the Flathub crew prior. LOL
From the interview with Matt:
Matt talks about the software supply chain….
Yeah, who do trust more: Fedora or Flathub? The supply chain problems exist for both, and upstream should be building and supplying the packages.
Projects also need to produce reproducible builds, because this conversation doesn’t really matter otherwise.
Fedora has a policy of building the software on Fedora on real hardware, and this would shake out some bugs. Flathub doesn’t specify how the builds are built, so I’m guessing via some source forge CI system or cloud VMs. Outsourced resources is kind of a problem.
Matt talking about how Android and iOS can force userspace permissions on to apps, and how Linux doesn’t have the leverage to do that….
As a distro, Fedora does have leverage. Build it and turn it on like Fedora did with SELinux. Flap that switch Matt. LOL
That was a lot of pain for years, but it’s been worked out.
Let’s not say a Linux distro doesn’t have the leverage to implement things, like tightened security. It’s been done before. There are examples to look at how to do it.
Apps asking for perms would be preferable instead of assuming I want them to have access be default. This would also help with weird problems where apps doesn’t work because of perms.