Notices where this attachment appears
-
Today someone pointed out http://flatkill.org/, and I saw some discussions around it today on fedi. As a user of Flatpak for both installing and developing applications I wanted to address it.
A lot of the issues they attribute to flatpak itself are really issues with the consumers of flatpak. Flatpak's sandbox is not useless, but the fact of the matter is many popular applications cannot fully use the sandbox in order to function. Inkscape is a good example. With Inkscape I can drag an icon from anywhere on my system and integrate it into the mockups I am working on. With a full sandbox that would not be possible, and the thing most important to most users is whether or not they can do their work with an application. So, as a trade-off, some apps choose their level of sandboxing.
There is a way to have a functioning app that interacts with the filesystem without turning off the sandbox, and that's through portals. Portals are not something that are automatically used, however. Applications need to be modified to support them - GtkFileChooserDialog becomes GtkFileChooserNative. This takes effort on the part of application developers, and if they aren't targeting flatpak themselves it's an effort they might not put in. This makes it so anyone packaging the flatpak needs to make the app work without portals, and that's through changing their sandboxing level.
Because some apps need to have permissions outside of the basic sandbox level, the author of flatkill states that "the users are misled to believe the apps run sandboxed". Contrarily, the flatpak CLI explicitly tells you what permissions are needed at install time. You can also use `flatpak info --show-permissions` after installation, and override permissions you don't want. The real issue lies once again with the consumers - package management interfaces like GNOME Software. To solve these issues these interfaces could:
• Show each permission the app requests explicitly
• Have a way to deny permissions at install time or post-install.
These are things that need to be worked on,
and likely will be worked on in the near-future as flatpak matures.
Flatpak is a new technology. There are growing pains, but I wouldn't write it off. The issues pointed out will be fixed as applications target the sandbox. There still might be some issues with third-party apps like Steam and Spotify, but those issues would still be present without flatpak. When used as a system for developers to distribute their own apps, flatpak has great potential.
-
Que bien que alguien se haya animado a hacer esta pagina. Explican por que flatpak (aunque es aplicable a cualquier gestor de paquetes con librerias estaticas) es un mierdo muy grande en terminos de seguridad. http://flatkill.org/