Criticism specifically regarding Flatpak: https://flatkill.org/
Criticism specifically regarding Flatpak: https://flatkill.org/
Issues mentioned on flatkill are already fixed, will be fixed or doesn't depend on flatpak itself (like the UI / icon in the software app store).
I don't like Flatpak either but I think we should elevate the debate to deeper architectural issues of flatpak that won't be fixed easily. Personally, I do not like the following in Flatpak :
- no effort on full reproducibility like Nix&Guix
- a big fat flat runtime rather than traditional fine grained dependencies (although OStree avoids duplication, but still very elegant)
- you can't install extra pkg in the sandbox. So the quite overkill solution in RedHat's vision is to separate between Toolbox/Podman for devs vs Flatpak for users, rather than trying to make a single unified sandbox for everything. Of course everything breaks down when you try to code using a Flatpaked IDE, if you follow RedHat's vision you basically need to spawn a toolbox container from an unsandboxed flatpak instance of your IDE : https://github.com/flathub/com.visualstudio.code/issues/44
So personally, I'm still waiting for a packaging system that is :
- compatible with the idea of a declarative/immutable os (like nix, guix, silverblue)
- tries to make everything reproducible (like guix)
- sandboxed with runtime permission API (like Flatpak portals, IOS, Android)
- sandbox can be augmented with packages so that you can code in your sandboxed IDE + add necessary dev packages inside a same sandbox without having to break it
However, ignoring the aspect of software distribution, wouldn't you agree that the approach taken by the Linux desktop today is deficient security-wise? For example, I would like to be able to give mbsync (or Thunderbird or whatever) my IMAP password without giving it to any other program. So I don't want to store it in mbsync's config file in plain text. Neither will I use gnome-keyring (or any other keyring) because it doesn't have any kind of "program authorisation". Any program can just spawn a new "secret-tool" process and get my credentials from gnome-keyring.
I've been thinking for a while about implementing a keyring which runs as a daemon with SUID of a dedicated user and checks which program sends requests to it, using /proc/pid/exe, but I'm not sure if it's a secure source of truth: how e.g. namespaces affect what's visible in /proc/pid/exe. I know you've been developing himitsu[1]. Have you thought about this problem in that context?