1. Apps still use the filesystem=host/home instead of intended portals bypassing the sandbox.
2. Common runtimes have un patched security issues.
Re 1) This is a backwards compatibility option until app developers start explicitly coding for flatpak compatibility. Given the money involved (~0) I can understand why it's taking some time. As a user one can address this with flatseal[1].
RE 2) This is more a problem of the ecosystem rather than a problem of the people developing flatpak. And it's not like this problem is not often encountered in other ecosystems. This just shows that the ecosystem is still in early stages. Still it s something worth pointing out and hopefully people at freedesktop.org look into it.
This is an area where Ubuntu's snap ecosystem does better. Instead of essentially trying to create a meta-distribution, snaps provide a way to run software built for Ubuntu LTS on other distros, at least in theory. They are compiled against Ubuntu LTS runtimes and are built primarily from packages in the Ubuntu LTS repositories. Further, when any Ubuntu based dependencies of snap packages get security updates in the Ubuntu repositories, the owners of said packages are prompted to rebuild their snaps.
In contrast, it's not clear who is assuming responsibility for maintaining flatpak runtimes like org.gnome.Platform, or what is their support lifecycle. It would be better to promote runtimes based on a well-known distribution's packages, since they would get security updates in accordance with that distribution's security policy. For instance, something like https://developers.redhat.com/blog/2020/08/12/introducing-th... looks more promising from a security point of view.
Isnt Snap actually worse by not having a runtime? While its indeed hardwired on the Ubuntu packages and infrastructure, the author still has to actively do something. When the app uses one of the major Flatpak runtimes, the vulnerability will be fixed for all apps using the runtime once the runtime is fixed - no action from app maintainer necessary.
Snaps are built on a "base snap" which in turn is derived from Ubuntu LTS. Further, they can bundle debs from the Ubuntu repositories using the "build-packages" and "stage-packages" manifest keywrods. One bonus of this design is that the people writing the manifest don't have to worry about how the deb dependencies themselves are built. They only need to worry about building any third-party dependencies.
Now, flathub does maintain a collection of "modules" -- basically prewritten manifests for building various common dependencies from source. But that collection is still quite small, and writing a working flatpak manifest can involve duplicating a lot of the hard work of Debian and Ubuntu package maintainers.
Recently, Fedora started something promising from a maintainer's point of view by:
* creating a flatpak runtime based on fedora releases, and
It seems like 2) gets to the heart of what flatpak is and how it works. The argument in favor of traditional packaging over flatpak is that security vulns in dependencies get fixed for all packages at once. The architecture of flatpak allows / encourages package maintainers to update vulnerable dependencies at their leisure. The fact that this is observed in the wild in the linked article seems a natural consequence. What is the mechanism that would cause this behavior to change as the ecosystem matures?
More available resources to update dependencies and hopefully plug in CI/CD pipelines. Curated runtimes by appstore/OS vendors would also help. Also since most if not all the code/images is open source, automated vulnerability scanning. Using approaches from the docker ecosystem that faces the same problem would also help.
All of the above however need resources (ie money) and that's why things are moving forward so slowly.
> Apps still use the filesystem=host/home instead of intended portals bypassing the sandbox.
The main issue seems to be the fact that flatpak still claims these apps to be "sandboxed", which is simply a lie. Properly communicating this situation to the user is all the article really asks for (and this seems very reasonable)
It's not flatpak, its the Gnome software center. Not the same thing. However removing the sandbox picture for apps that use the filesystem=host/home permissions on Gnome Software would be a better representation of reality.
1. Apps still use the filesystem=host/home instead of intended portals bypassing the sandbox.
2. Common runtimes have un patched security issues.
Re 1) This is a backwards compatibility option until app developers start explicitly coding for flatpak compatibility. Given the money involved (~0) I can understand why it's taking some time. As a user one can address this with flatseal[1].
RE 2) This is more a problem of the ecosystem rather than a problem of the people developing flatpak. And it's not like this problem is not often encountered in other ecosystems. This just shows that the ecosystem is still in early stages. Still it s something worth pointing out and hopefully people at freedesktop.org look into it.
[1]: https://flathub.org/apps/details/com.github.tchx84.Flatseal