6 ms·

> it works No. It doesn't. You still need to trust the people who package the thing. A working packaging system would give the user ultimate power to manage

> it works No. It doesn't. You still need to trust the people who package the thing. A working packaging system would give the user ultimate power to manage access to resources by each app. Overriding or mocking, if the user so decides, whatever access does the app believe to need. Flatpack does not give you such power, it removes this power from you and assigns it to the packagers. Thus, not only it doesn't work: it works against you! EDIT: The "dependency hell" issue is separate, and is solved more easily by distributing static binaries.

AnonCoward4 5y ago
You can override permissions (there is even a GUI called Flatseal for that). You are also not able to do any of that with distro package managers like apt or dnf. Ultimately you need to trust either.
- enriquto 5y ago
  What I mean is that permissions and accesses concern the operating system, not the software packaging. I don't understand why flatpack needs to deal with those, providing a false (and pernicious) aura of protection. I already run third-party software inside containers or virtual machines. No need for a GUI nor a flatpack-only solution like flatseal. It just looks pointless.
alkonaut 5y ago
Is there any difference in trust between package maintainers and flatpack packagers? If anything, isn't the flatpack situation better in that regard because the end user is more likely to have a sandbox?
- enriquto 5y ago
  > Is there any difference in trust between package maintainers and flatpack packagers? You shouldn't need to trust either. Just the sandboxing system of your OS.
  - gizdan 5y ago
    This is an inherent limitation of the way OSs are built. Linux, Windows, macOS are all like this. macOS is currently the furthest ahead in this since they're sharing code with iOS, but it's still not where it should be. The Linux kernel is not at a point of allowing this kind of fine grained sandboxing or mocking of APIs. I'm guessing because it's a significant undertaking. I'm sure as more features become available in the Kernel w.r.t. sandboxing Snap and Flatpak will definitely utilise them.
    - drran 5y ago
      Yeah, proper use of Flatpack requires antivirus, reverse firewall, hardware isolation (separate CPU core per application), user education, etc.
  - simiones 5y ago
    That's only true for the simplest of apps. The whole point of desktop OSs is that programs can integrate with each other, but that necessarily discards the notion of a sandbox almost entirely.
    - iggldiggl 5y ago
      Yeah, e.g. file sandboxing approaches that work along the lines of "don't let the program access any files outside of its private directory except for those explicitly and lovingly hand-picked by the user" commonly ignore the existence of multi-file file formats.
- drran 5y ago
  Maintainers are not developers, they are users, so the developer cannot push unwelcome changes, such as ads, trackers, trojans, backdoors, keyloggers, etc. directly to users because the maintainer will refuse to accept that.
  - AnIdiotOnTheNet 5y ago
    On the other hand, maintainers can and have inserted (accidentally or not) vulnerabilities in software, and ignore developer wishes (like "please stop distributing this ancient unmaintained software without this warning that says it is ancient and unmaintained"), which reflects poorly on the developer in the mind of the user. I personally see no upside to shoving an unpaid third party between user and developer.
    - southerntofu 5y ago
      > I personally see no upside to shoving an unpaid third party between user and developer. I think F-Droid is a good example of striking a balance between those two extreme models. Their existence enforces community vetting of apps as well as somewhat-reproducible thanks to their standardized build infra, which are two major wins. I personally have much more trust in such schemes (such as guix/nix) because i don't necessarily trust all of the developers of apps i use not to get hacked, and i believe enabling one-click updates to every user of an app without review is a dangerous pattern for security.
    - goohle 5y ago
      > On the other hand, maintainers can and have inserted (accidentally or not) vulnerabilities in software, Such maintainer will be kicked off from distribution. > and ignore developer wishes (like "please stop distributing this ancient unmaintained software without this warning that says it is ancient and unmaintained") Developer wishes are developer wishes. User wishes are more important. If package has a maintainer, then it IS maintained. You can use any distribution developed by developers (do you know any?) if you dislike maintained distributions and share experience with us.
      - 5y ago
- goodpoint 5y ago
  > Is there any difference in trust between package maintainers and flatpack packagers? Yes, and very big: Debian maintainers need to build a reputation for years to gain upload rights, meet in person, sign keys, and the packages are peer reviewed my multiple persons. Plus, packages spend time in release freeze being tested by a large userbase before a distro is released.
gizdan 5y ago
> No. It doesn't. You still need to trust the people who package the thing. Flatpak and Snap have never claimed to solve the trust issue though. Flatpak allows you to add your own repositories and thus developers can package their own applications. So if you trust the developer enough to run their software, you should be able to trust them to package their own app with.
- unsungNovelty 5y ago
  You are right. But with the marketing of them with sandboxing and whatnot, they create the impression and illusion that it is safe. Cos most of them install it from Flathub or Snapcraft. The assumption is that they go through all of it and that it is safe. Just like Play store and App store. I am pretty sure Flatpak folks now this. It is like... we won't lie. But we are not also gonna tell the truth. To make things worse, Flathub changed the way they display "Publisher" field for a flatpak. Which says whether a package was published by Flathub maintainers, Upstream developer or somebody else in Flathub. Now instead of saying who, they just say a "See details" link under Publisher field in flathub.org for a flatpak. That link which in turn directs me to a github page and I am still unsure who the hell uploaded that flatpak. Before, they used to say Upstream developer's name or say "Flathub maintainers" which means Flathub team uploaded the flatpak making it easier verify who uploaded the flatpak. But now it is making it more difficult. This has been the most pissing thing about Flatpak other than the security issues and problems which keeps coming up about Flathub every now and then. Why would you change something that is so crucial when it is working? Cos now, I could package a software which is not in Flathub and it would just say "See details" instead of my name. This provides the illusion of trust. Cos if it were to show my name there, more people would've been like.. who the hell is this guy and do a check on me (I used to do that). But now, If I could slip through Flathub checks and provide malicious flatpak, majority of the folks will still install cos most of them are using Flatpak for convenience. Not security and performance. Want proof? Just scroll up and you will see someone saying he don't care even though agrees to the things in the blog post. He just don't care. :shrug:
  - blntechie 5y ago
    I was thinking about this the other day and a wasteful solution to the packaging problem in open source is the decentralized build solution on a blockchain like platform. Either with PoW or PoS. In PoS, a node builds the code pulled from source control, multiple other nodes validate the build and its hash and add to the blockchain and to the repository. Now the builds are relatively trustable. Of course need to figure out an incentive structure for miners/validators to do this expensive work.
Gigachad 5y ago
There is a tool called flatseal which gives you a bunch of toggles so you can turn on or off any permission for a flatpak app.
curt15 5y ago
Flatseal gives users a GUI to manage the permissions of each app. Would that address your concern?
- southerntofu 5y ago
  I think it's great, but we're still far off from an ideal solution because it's not exactly fine-grained. For example, flatpak portals enable me to grant/block access to my home folder, but don't enable me to allowlist a specific folder in my home. So i'm stuck with the possibility that a vulnerability in the app can take over my entire system (eg. by rewriting ~/.profile), or with my app not accessing my home folder at all. As a user, I'd like to give Krita/Libreoffice permissions for ~/Documents and Tor Browser permissions for ~/Downloads. I don't know yet of a user-friendly method to achieve that.
  - curt15 5y ago
    >As a user, I'd like to give Krita/Libreoffice permissions for ~/Documents and Tor Browser permissions for ~/Downloads. I don't know yet of a user-friendly method to achieve that. The filesystem permissions are a bit more fine-grained than "all of home or nothing". Your two examples are already possible to achieve by granting filesystem access to xdg-documents or xdg-downloads.
    - brnt 5y ago
      So many flatpaks do this incorrectly though. For Browser by default saves in the flatpaks home/Downloads directory (which is 15 layers deep from ~). You just gotta know to navigate up. Signal let's you save attachments anywhere on disk, but only if you manually navigate to ~/Downloads, does it actually save (in a way visible and accessible outside of the app). You just gotta know. I forgot what exactly the problem was with Vscode(/ium), but it also has a catch like that. You just gotta know. Flatpak turns out to be the best compromise between distribution and cross distro compatibility, but there's still some low hanging fruit that could be improved.
      - 5y ago
fullstop 5y ago
> No. It doesn't. You still need to trust the people who package the thing. How is this any different than sudo apt install foo?
- enriquto 5y ago
  apt is not misleadingly advertised as a sandboxing environment. Flatpack is: "Flatpak: Linux application sandboxing and distribution framework " [0] "It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system." [1] The whole point of a sandboxing environment is that you can run applications that do not want to be sandboxed. The flatpack proposition is directly contradictory with this basic requirement, in that it requires the application to be flatpacked to begin with. [0] https://github.com/flatpak/flatpak https://github.com/flatpak/flatpak [1] https://en.wikipedia.org/wiki/Flatpak https://en.wikipedia.org/wiki/Flatpak
  - fullstop 5y ago
    Trust of the packager is still involved, no?
    - silon42 5y ago
      Yes, but only for things you give access to (data files, internet)... sandboxing by default, it should not be able to do anything except consume CPU (memory needs to be limited also, which might be an issue in practice).
    - goohle 5y ago
      When I use something from a distribution, I trust the distribution as organization. When I use something packaged by a developer, I trust the developer. I cannot verify thousands of developers, so I must trust the distribution and I can trust few developers or packagers outside of distribution.

AnonCoward4 5y ago

You can override permissions (there is even a GUI called Flatseal for that). You are also not able to do any of that with distro package managers like apt or dnf. Ultimately you need to trust either.

enriquto 5y ago
What I mean is that permissions and accesses concern the operating system, not the software packaging. I don't understand why flatpack needs to deal with those, providing a false (and pernicious) aura of protection. I already run third-party software inside containers or virtual machines. No need for a GUI nor a flatpack-only solution like flatseal. It just looks pointless.

alkonaut 5y ago

Is there any difference in trust between package maintainers and flatpack packagers? If anything, isn't the flatpack situation better in that regard because the end user is more likely to have a sandbox?

enriquto 5y ago
> Is there any difference in trust between package maintainers and flatpack packagers? You shouldn't need to trust either. Just the sandboxing system of your OS.
- gizdan 5y ago
  This is an inherent limitation of the way OSs are built. Linux, Windows, macOS are all like this. macOS is currently the furthest ahead in this since they're sharing code with iOS, but it's still not where it should be. The Linux kernel is not at a point of allowing this kind of fine grained sandboxing or mocking of APIs. I'm guessing because it's a significant undertaking. I'm sure as more features become available in the Kernel w.r.t. sandboxing Snap and Flatpak will definitely utilise them.
  - drran 5y ago
    Yeah, proper use of Flatpack requires antivirus, reverse firewall, hardware isolation (separate CPU core per application), user education, etc.
- simiones 5y ago
  That's only true for the simplest of apps. The whole point of desktop OSs is that programs can integrate with each other, but that necessarily discards the notion of a sandbox almost entirely.
  - iggldiggl 5y ago
    Yeah, e.g. file sandboxing approaches that work along the lines of "don't let the program access any files outside of its private directory except for those explicitly and lovingly hand-picked by the user" commonly ignore the existence of multi-file file formats.
drran 5y ago
Maintainers are not developers, they are users, so the developer cannot push unwelcome changes, such as ads, trackers, trojans, backdoors, keyloggers, etc. directly to users because the maintainer will refuse to accept that.
- AnIdiotOnTheNet 5y ago
  On the other hand, maintainers can and have inserted (accidentally or not) vulnerabilities in software, and ignore developer wishes (like "please stop distributing this ancient unmaintained software without this warning that says it is ancient and unmaintained"), which reflects poorly on the developer in the mind of the user. I personally see no upside to shoving an unpaid third party between user and developer.
  - southerntofu 5y ago
    > I personally see no upside to shoving an unpaid third party between user and developer. I think F-Droid is a good example of striking a balance between those two extreme models. Their existence enforces community vetting of apps as well as somewhat-reproducible thanks to their standardized build infra, which are two major wins. I personally have much more trust in such schemes (such as guix/nix) because i don't necessarily trust all of the developers of apps i use not to get hacked, and i believe enabling one-click updates to every user of an app without review is a dangerous pattern for security.
  - goohle 5y ago
    > On the other hand, maintainers can and have inserted (accidentally or not) vulnerabilities in software, Such maintainer will be kicked off from distribution. > and ignore developer wishes (like "please stop distributing this ancient unmaintained software without this warning that says it is ancient and unmaintained") Developer wishes are developer wishes. User wishes are more important. If package has a maintainer, then it IS maintained. You can use any distribution developed by developers (do you know any?) if you dislike maintained distributions and share experience with us.
    - 5y ago
goodpoint 5y ago
> Is there any difference in trust between package maintainers and flatpack packagers? Yes, and very big: Debian maintainers need to build a reputation for years to gain upload rights, meet in person, sign keys, and the packages are peer reviewed my multiple persons. Plus, packages spend time in release freeze being tested by a large userbase before a distro is released.

gizdan 5y ago

> No. It doesn't. You still need to trust the people who package the thing. Flatpak and Snap have never claimed to solve the trust issue though. Flatpak allows you to add your own repositories and thus developers can package their own applications. So if you trust the developer enough to run their software, you should be able to trust them to package their own app with.

unsungNovelty 5y ago
You are right. But with the marketing of them with sandboxing and whatnot, they create the impression and illusion that it is safe. Cos most of them install it from Flathub or Snapcraft. The assumption is that they go through all of it and that it is safe. Just like Play store and App store. I am pretty sure Flatpak folks now this. It is like... we won't lie. But we are not also gonna tell the truth. To make things worse, Flathub changed the way they display "Publisher" field for a flatpak. Which says whether a package was published by Flathub maintainers, Upstream developer or somebody else in Flathub. Now instead of saying who, they just say a "See details" link under Publisher field in flathub.org for a flatpak. That link which in turn directs me to a github page and I am still unsure who the hell uploaded that flatpak. Before, they used to say Upstream developer's name or say "Flathub maintainers" which means Flathub team uploaded the flatpak making it easier verify who uploaded the flatpak. But now it is making it more difficult. This has been the most pissing thing about Flatpak other than the security issues and problems which keeps coming up about Flathub every now and then. Why would you change something that is so crucial when it is working? Cos now, I could package a software which is not in Flathub and it would just say "See details" instead of my name. This provides the illusion of trust. Cos if it were to show my name there, more people would've been like.. who the hell is this guy and do a check on me (I used to do that). But now, If I could slip through Flathub checks and provide malicious flatpak, majority of the folks will still install cos most of them are using Flatpak for convenience. Not security and performance. Want proof? Just scroll up and you will see someone saying he don't care even though agrees to the things in the blog post. He just don't care. :shrug:
- blntechie 5y ago
  I was thinking about this the other day and a wasteful solution to the packaging problem in open source is the decentralized build solution on a blockchain like platform. Either with PoW or PoS. In PoS, a node builds the code pulled from source control, multiple other nodes validate the build and its hash and add to the blockchain and to the repository. Now the builds are relatively trustable. Of course need to figure out an incentive structure for miners/validators to do this expensive work.

Gigachad 5y ago

There is a tool called flatseal which gives you a bunch of toggles so you can turn on or off any permission for a flatpak app.

curt15 5y ago

Flatseal gives users a GUI to manage the permissions of each app. Would that address your concern?

southerntofu 5y ago
I think it's great, but we're still far off from an ideal solution because it's not exactly fine-grained. For example, flatpak portals enable me to grant/block access to my home folder, but don't enable me to allowlist a specific folder in my home. So i'm stuck with the possibility that a vulnerability in the app can take over my entire system (eg. by rewriting ~/.profile), or with my app not accessing my home folder at all. As a user, I'd like to give Krita/Libreoffice permissions for ~/Documents and Tor Browser permissions for ~/Downloads. I don't know yet of a user-friendly method to achieve that.
- curt15 5y ago
  >As a user, I'd like to give Krita/Libreoffice permissions for ~/Documents and Tor Browser permissions for ~/Downloads. I don't know yet of a user-friendly method to achieve that. The filesystem permissions are a bit more fine-grained than "all of home or nothing". Your two examples are already possible to achieve by granting filesystem access to xdg-documents or xdg-downloads.
  - brnt 5y ago
    So many flatpaks do this incorrectly though. For Browser by default saves in the flatpaks home/Downloads directory (which is 15 layers deep from ~). You just gotta know to navigate up. Signal let's you save attachments anywhere on disk, but only if you manually navigate to ~/Downloads, does it actually save (in a way visible and accessible outside of the app). You just gotta know. I forgot what exactly the problem was with Vscode(/ium), but it also has a catch like that. You just gotta know. Flatpak turns out to be the best compromise between distribution and cross distro compatibility, but there's still some low hanging fruit that could be improved.
    - 5y ago

fullstop 5y ago

> No. It doesn't. You still need to trust the people who package the thing. How is this any different than sudo apt install foo?

enriquto 5y ago
apt is not misleadingly advertised as a sandboxing environment. Flatpack is: "Flatpak: Linux application sandboxing and distribution framework " [0] "It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system." [1] The whole point of a sandboxing environment is that you can run applications that do not want to be sandboxed. The flatpack proposition is directly contradictory with this basic requirement, in that it requires the application to be flatpacked to begin with. [0] https://github.com/flatpak/flatpak https://github.com/flatpak/flatpak [1] https://en.wikipedia.org/wiki/Flatpak https://en.wikipedia.org/wiki/Flatpak
- fullstop 5y ago
  Trust of the packager is still involved, no?
  - silon42 5y ago
    Yes, but only for things you give access to (data files, internet)... sandboxing by default, it should not be able to do anything except consume CPU (memory needs to be limited also, which might be an issue in practice).
  - goohle 5y ago
    When I use something from a distribution, I trust the distribution as organization. When I use something packaged by a developer, I trust the developer. I cannot verify thousands of developers, so I must trust the distribution and I can trust few developers or packagers outside of distribution.