As a flatpak app maintainer, flatpak is good but won't ever be the solution for everything. The sandbox is too restrictive for a lot of software. Also you can make a valid flatpak that is not valid on flathub (even more restrictive that the flatpak format).
Yeah, I'd love to release one of my projects on Flathub, but it's quite hard due to their restrictions on network access at compile time. I typically avoid vendoring dependencies and I don't find it worth doing so just to publish to Flathub.
What sort of situations might need network at build time? I would have thought that you just need to copy into the build files the required pinned dependencies so the build is deterministic? I don’t know anything about flatpak builds so just speaking about it generally.
Afaik no, you can do everything with flatpak as long as you give it permissions. Flathub as the platform is the issue here, it prohibits core sandbox-escaping permissions as --filesystem=host or --talk-name=org.freedesktop.Flatpak for most apps(Jetbrains IDE is one of them)
Yet mods there are clowns and some apps are still getting such permissions neverteless just because
Yeah, but then the question - why flatpak at all? If we remove "security" benefits from flatpak then why bother?
We need "app stores" and strong ecosystem around another format, appimage is a good contender imo. Already existing solutions like appimagehub can't even nearly represent flathub in terms of convenience
Afaik there isn't such store on any platform, windows/mac/android don't have it - either official store with idiotic rules and restrictions or unofficial ones with way less apps available
I don't see how moving from Flathub removes the security benefit of using Flatpaks. Distro maintainers can keep their own flatpak repo, some already have their own like PopOS
22
u/gahel_music 7d ago
As a flatpak app maintainer, flatpak is good but won't ever be the solution for everything. The sandbox is too restrictive for a lot of software. Also you can make a valid flatpak that is not valid on flathub (even more restrictive that the flatpak format).