3 ms·

Every attempt at "solving" this "problem", including Snap, Flatpak, and AppImage, are an absolutely awful regression in the state of Linux. I absolutely hate th

Every attempt at "solving" this "problem", including Snap, Flatpak, and AppImage, are an absolutely awful regression in the state of Linux. I absolutely hate this trend. These tools solve problems for only two kinds of software: proprietary software, and software with suck reckless, runaway complexity that it can only run in one specific environment. I have no interest in either kind and I will give no quarter to "solutions" for their "problems". Criticism specifically regarding Flatpak: https://flatkill.org/ https://flatkill.org/

abjKT26nO8 6y ago
I mostly agree with you and I'm not going to get even near Snaps and Flatpaks. 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? [1]: https://git.sr.ht/~sircmpwn/himitsu https://git.sr.ht/~sircmpwn/himitsu
- ddevault 6y ago
  I agree with you, but the solution would have been Plan 9 namespaces, not Linux containers. What we're working towards today is awful.
ttgo 6y ago
flatkill.org is clickbait, not written in good faith, and doesn't propose any solution. Moreover things like "it's obvious Red Hat developers working on flatpak do not care about security" is just unnecessary and toxic. 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 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

abjKT26nO8 6y ago

I mostly agree with you and I'm not going to get even near Snaps and Flatpaks. 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? [1]: https://git.sr.ht/~sircmpwn/himitsu https://git.sr.ht/~sircmpwn/himitsu

ddevault 6y ago
I agree with you, but the solution would have been Plan 9 namespaces, not Linux containers. What we're working towards today is awful.

ttgo 6y ago

flatkill.org is clickbait, not written in good faith, and doesn't propose any solution. Moreover things like "it's obvious Red Hat developers working on flatpak do not care about security" is just unnecessary and toxic. 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 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