Recent searches
Search options
Administered by:
Welp, Thursday nights are apparently my “write a big ol' blog post” nights. Idk if this will publish tonight or some time tomorrow (probably the latter so it can get some review), but it’s a good one—and this time, not about feet!
@cassidy@blaede.familyFun fact: if my process and math is correct, Flathub is down to <5% of apps being built from other packaging formats as extra-data sources.
205/4101
Thanks to @wjt's blog post¹ for pointing me in the right direction and gasinvein’s Flatpak Remote Metadata Fetcher² for the handy tool.
¹https://blogs.gnome.org/wjjt/2022/06/14/how-many-flathub-apps-reuse-other-package-formats/
@bbhtt corrected me (there's a bug in the count of desktop apps, oops); it's around 6% of non-EOL desktop apps that use extra-data. Still, down half from ~12% a couple of years ago!
Another fun fact: over half of the (non-EOL, desktop) apps on Flathub are now verified. 
if anyone’s super into this Flatpak and Flathub stuff—especially if you’re knowledgeable about safety protections built into the ecosystem—I could use your review of a decently-long blog post. Let me know and I’ll DM you a link. 
It's live! Feedback still welcome, of course. :)
https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user
@cassidy this is incredibly cool and the human review + portals auditable permissions is really fascinating and not something that can be implemented outside of the flatpak framework. in particular the human review part mostly addresses my primary concern with flatpak in general which is just that there needs to be some human audit layer in between upstream and end users. cc @ada_magicat @cas i'm pretty sure i "get" flatpak now
@cassidy nice roundup! good to have those arguments in one place, easy to link to :)
I have one question about this statement:
> The runtimes provide basic dependencies, are well-maintained by the Linux community.
What does that mean? I was under the impression there was a dedicated set of people (from the flatpak/flathub project) that look after the runtimes. This makes it sound like the maintenance is somehow shared across the wider ecosystem?
@robertgzr people from GNOME maintain the GNOME runtimes, people from KDE maintain the KDE runtimes, and people from the freedesktop-sdk project (which includes people who work on a bunch of other projects, and I think people from CodeThink?) maintain the FreeDesktop SDK. It's always kind of messy with these efforts since they are handled by multiple people, and those people may be involved in multiple projects, but I think it would be safe to say they're maintained by GNOME and KDE.
@cassidy finally got thru this post, its nice and detailed!
Is there any breakdown of what protections are provided specifically by Flathub vs Flatpak? For example if there are other flatpak enabled app store websites, what are they not getting that Flathub has built
@McNeely ooh, good question.
Yeah it’s a bit hard to separate since Flathub leans into the model of Flatpak itself, but a lot of it is enforced by policy of Flathub—and the enforcement of that policy is what makes Flatpak’s safety model actually work. For example if a Flatpak remote did just allow any uploads of any Flatpaks under any namespaces, without review, and allowed any static permissions… well, it wouldn’t really be a security model. 
@McNeely so it will really differ based on the remote for the most part. There are probably some features of Flatpak itself that do help here no matter what, but I'm struggling to think of a case where a malicious/compromised app from a lax remote couldn't bypass a sandbox and cause issues.
So you have to trust both: the Flatpak security model AND the remote to enforce policy to use that model.
@cassidy when you say "the remote" do you mean the flatpak remote? aka the build server where the apps are served from
Like you said before, the app policies of Flatpak aren't worth as much if there's no enforcement mechanism (a generalized "app store" front end). It seems like everyone just sort of builds their own app store front end whether it's a desktop app or website like Flathub. I guess I'm just trying to figure out what all leverage/advantages Flathub has built up.
@McNeely “Remote” in Flatpak parlance is the repository. Technically it can have its own front-end (like flathub.org or appcenter.elementary.io), but it doesn’t necessarily need to—it’s the back-end that hosts the Flatpaks themselves (and thus the policy of the remote is what determines what gets into the remote into the first place). And then an “app store client” is like GNOME Software, KDE Discover, or elementary AppCenter (the app on elementary OS) or I guess technically the flatpak CLI.
@McNeely what gets kind of confusing is that it’s many-to-many between remotes and app store clients, e.g.:
• Fedora has GNOME Software w/both Fedora Flatpaks and Flathub
• elementary OS has AppCenter w/both AppCenter and Flathub
• Steam Deck desktop mode has KDE Discover w/Flathub
Under the hood Flatpak is still enforcing things, but what apps are allowed in each remote is up to that remote, and app store clients are in charge of *how to communicate* things like permissions to the user.
@cassidy totally! A "store client" could have multiple remotes that it interacts with. That's why I was asking about the break downs of what Flathub does bc the policies of the client are a big part of the trust model in the whole ecosystem.
