6 ms·

There are plenty of drawbacks: - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever

There are plenty of drawbacks: - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. - Privacy: distros like Debian spot and patch out trackers, telemetries and similar things. - Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have to maintain yourself. - Licensing issues: distros review licenses (and find plenty of copyright violations while doing so). A flatpak puts you or your company at risk. - Impact on the ecosystem: the more users switch to opaque blobs the less testing and review is done for proper packages. The whole ecosystem become more vulnerable to supply chain attacks.

fsflover 5y ago
So basically all the same drawbacks as in Windows, when you install third-party software?
- ahartmetz 5y ago
  Of course, it's basically the same distribution model. Everything but the kernel and a very basic set of runtime libraries are shipped with the application. Except, I guess, that the basic Windows runtime libraries cover more security-relevant functionality than the same with Flatpak. I'm thinking of SSL, for example.
- raffraffraff 5y ago
  When I had to install my first AppImage I got a horrible déjà vu from my Windows XP days. The Linux repo experience is just better. Trust the repo via gpg and https instead of trusting every download url and scanning every blob for malware. Upgrade the whole system at once, instead of hunting down every new blob (and remembering where you got it).
- monopoledance 5y ago
  Haven't used Windows in a decade, but third party apps on Windows don't even have the framework for some sort of package management, do they? At least with snap/flatpak/AUR/PPA you got an aggregated updating interface and optionally sandboxing for snaps and flatpaks. I think, something like Appimages are the better fitting equivalent to Window's normalized madness, no?
pas 5y ago
Debian could provide their packages as flatpacks too. Not to mention that container images are still mostly built by using regular packages, aren't they? (So they are not as opaque, nor the regular packages go untested.)
- goodpoint 5y ago
  > Debian could provide their packages as flatpacks too. That would provide no benefits. > Not to mention that container images are still mostly built by using regular packages Yes, and because of the bundling they are a security disaster, as proven by many researchers: e.g. https://www.infoq.com/news/2020/12/dockerhub-image-vulnerabilities/ https://www.infoq.com/news/2020/12/dockerhub-image-vulnerabi... https://www.darkreading.com/threat-intelligence/malicious-or-vulnerable-docker-images-widespread-firm-says https://www.darkreading.com/threat-intelligence/malicious-or...
- tremon 5y ago
  So they are not as opaque Ok, say a wild CVE appears and it says libblip versions 1.3 through 2.0.4 have a severity-10 RCE vulnerability and should be patched ASAP. If the container images and flatpaks are not opaque, I presume you have a simple command that lists all vulnerable library versions that are present on all the machines you administer? And, subsequently, that you have an easy procedure to patch them all?
  - pas 5y ago
    If Debian (or whatever org/group/project/initiative that) provides the images has a security policy, they can extend that to the images too. Users don't run CVE checkers [0], at best they reluctantly click on the update button. Of course the authoritarian evergreen auto-update thing is what actually works in practice. For example as much as snap's UX sucks it does auto update by default. [0] Though they could, as files in container images are trivially accessible, after all it's their purpose. Plus there are metadata based approaches: https://github.com/TingPing/flatpak-cve-checker https://github.com/TingPing/flatpak-cve-checker (plus the Flatpak project already spends some energy on ensuring that the base image is chechekd against CVEs https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/1804964393 https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/18... ) of course duplicating this effort, and building a parallel world besides packages is not ideal
rattlesnakedave 5y ago
> - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. As opposed to what? Dynamic linking does not solve this problem, contrary to popular belief. >- Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have to maintain yourself. Again, as opposed to what? >- Licensing issues: distros review licenses (and find plenty of copyright violations while doing so). A flatpak puts you or your company at risk. Sounds like a good way for a proprietary software to be distributed... >- Impact on the ecosystem: the more users switch to opaque blobs the less testing and review is done for proper packages. The whole ecosystem become more vulnerable to supply chain attacks. I don't see how one follows the other.
- goodpoint 5y ago
  >> - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. > As opposed to what? Opposed to distributions providing targeted updates to each package. > Dynamic linking does not solve this problem, contrary to popular belief. On the contrary it provably works very well for distributions. >>- Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have to maintain yourself. >Again, as opposed to what? Opposed to distributions that do the huge work of packaging, testing, backporting etc. >>- Licensing issues: distros review licenses (and find plenty of copyright violations while doing so). A flatpak puts you or your company at risk. >Sounds like a good way for a proprietary software to be distributed... This is unrelated to the lack of licensing review. >>- Impact on the ecosystem: the more users switch to opaque blobs the less testing and review is done for proper packages. The whole ecosystem become more vulnerable to supply chain attacks. >I don't see how one follows the other. Supply chain attacks are strongly mitigated by maintainers doing vetting and packaging, and by distribution doing release freezing.
  - jcelerier 5y ago
    > On the contrary it provably works very well for distributions. if it worked very well there wouldn't be a need for flatpak / snap / appimage / etc. How do I install an older or newer inkscape / ardour / krita in the latest debian stable / ubuntu / fedora / whatever without recompiling stuff ?
danShumway 5y ago
Worth noting that nothing about Flatpak necessitates that distro maintainers can't compile their own Flatpak apps the same way they currently do. Debian can still compile Firefox from source and patch out trackers and update dependencies, even if at the end of the day it bundles the changes back into another Flatpak app. In fact, the lack of interdependence between apps makes this considerably easier, because a Debian upstream that sits in the middle and custom-compiles it's "official" software can release security updates immediately for critical apps with critical security flaws -- without waiting to make sure that the security fixes don't break some other app. Flatpak does not require you to have a separate upstream for every app, or to get your updates straight from the developer. Debian can still be a middleperson and they can still do all of the same moderation/customization/legal analysis. ---- Very importantly, on security, Flatpak is a paradigm shift away from the existing model of needing complete trust for the entire app: > Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. A big part of this is that you don't trust random developers with Flatpak, or even your own distro maintainers. Most applications do not need the level of access they have by default. The end goal of Flatpak (it is debatable whether it is achieving this, but the goal at least) is to significantly shrink the attack surface of your app. If your calculator app doesn't have file access, or network access, or process forking, or any of these things because the runtime blocks them (and honestly, why on earth would it ever need those things), then it is a lot less dangerous for your dependencies to go out of date. A calculator should not need to worry about updating its dependencies, because it should not have access to anything that could be abused. Now, that's an extreme example. Many apps will not be in the position of needing no privileges, but many of them will still be able to have their attack surfaces shrunk. Firefox for example really shouldn't have that much access to my filesystem. Apps should not (in general) share parts of the filesystem except in user-defined contexts. Many of them don't need Internet access at all. Flatpak makes it easier for dependencies to go out of date, but it also (ideally) drastically reduces the number of potential security flaws you can have in the first place, and drastically reduces the ability of apps to exfiltrate data from other apps (again, this is the ideal, see X11 vulnerabilities + Wayland for how much of an ongoing process fixing Linux security is). ---- I would question a few things: - Is the reduction in attack surface big enough to balance out the extra attention users/devs need to pay to updating dependencies? - How many security vulnerabilities are due to dependency issues vs data exfiltration from the home folder, or from other apps that they have no need to access? Linux security is kind of a disaster in this area, how many vulnerabilities would we fix immediately just by sandboxing filesystem access so /home wasn't a free for all? - Is this actually blocking maintainers from releasing security patches or making it harder for them to do so? I would argue no, I think the maintainers can do the exact same things they're doing today, and that their job may be even easier when they don't need to hold up an entire house of cards with every release. - Is it better to trust Debian to try and patch out every tracker/telemetry, or is there an improvement to having apps that don't require Internet access just be flat-out unable to call home or send telemetry in the first place? I don't think this blocks maintainers from doing their jobs, and it means I just don't have to worry about trackers at all in my calculator app, even if I download it from a 3rd-party source. ---- The weak point here is other Linux vulnerabilities (gotta get off X11!), UX (an eternally hard problem to solve), and Flatpak immaturity/mistakes (I don't like that manifests are still a thing, portals are still being built, I think permissions could be better). But the fundamental concept here isn't bad. People rely on shared libraries/runtimes for a lot of things that they don't need shared runtimes to get. And I can't stress enough: distros can still moderate and compile custom versions of Flatpak apps.

fsflover 5y ago

So basically all the same drawbacks as in Windows, when you install third-party software?

ahartmetz 5y ago
Of course, it's basically the same distribution model. Everything but the kernel and a very basic set of runtime libraries are shipped with the application. Except, I guess, that the basic Windows runtime libraries cover more security-relevant functionality than the same with Flatpak. I'm thinking of SSL, for example.
raffraffraff 5y ago
When I had to install my first AppImage I got a horrible déjà vu from my Windows XP days. The Linux repo experience is just better. Trust the repo via gpg and https instead of trusting every download url and scanning every blob for malware. Upgrade the whole system at once, instead of hunting down every new blob (and remembering where you got it).
monopoledance 5y ago
Haven't used Windows in a decade, but third party apps on Windows don't even have the framework for some sort of package management, do they? At least with snap/flatpak/AUR/PPA you got an aggregated updating interface and optionally sandboxing for snaps and flatpaks. I think, something like Appimages are the better fitting equivalent to Window's normalized madness, no?

pas 5y ago

Debian could provide their packages as flatpacks too. Not to mention that container images are still mostly built by using regular packages, aren't they? (So they are not as opaque, nor the regular packages go untested.)

goodpoint 5y ago
> Debian could provide their packages as flatpacks too. That would provide no benefits. > Not to mention that container images are still mostly built by using regular packages Yes, and because of the bundling they are a security disaster, as proven by many researchers: e.g. https://www.infoq.com/news/2020/12/dockerhub-image-vulnerabilities/ https://www.infoq.com/news/2020/12/dockerhub-image-vulnerabi... https://www.darkreading.com/threat-intelligence/malicious-or-vulnerable-docker-images-widespread-firm-says https://www.darkreading.com/threat-intelligence/malicious-or...
tremon 5y ago
So they are not as opaque Ok, say a wild CVE appears and it says libblip versions 1.3 through 2.0.4 have a severity-10 RCE vulnerability and should be patched ASAP. If the container images and flatpaks are not opaque, I presume you have a simple command that lists all vulnerable library versions that are present on all the machines you administer? And, subsequently, that you have an easy procedure to patch them all?
- pas 5y ago
  If Debian (or whatever org/group/project/initiative that) provides the images has a security policy, they can extend that to the images too. Users don't run CVE checkers [0], at best they reluctantly click on the update button. Of course the authoritarian evergreen auto-update thing is what actually works in practice. For example as much as snap's UX sucks it does auto update by default. [0] Though they could, as files in container images are trivially accessible, after all it's their purpose. Plus there are metadata based approaches: https://github.com/TingPing/flatpak-cve-checker https://github.com/TingPing/flatpak-cve-checker (plus the Flatpak project already spends some energy on ensuring that the base image is chechekd against CVEs https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/1804964393 https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/18... ) of course duplicating this effort, and building a parallel world besides packages is not ideal

rattlesnakedave 5y ago

> - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. As opposed to what? Dynamic linking does not solve this problem, contrary to popular belief. >- Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have to maintain yourself. Again, as opposed to what? >- Licensing issues: distros review licenses (and find plenty of copyright violations while doing so). A flatpak puts you or your company at risk. Sounds like a good way for a proprietary software to be distributed... >- Impact on the ecosystem: the more users switch to opaque blobs the less testing and review is done for proper packages. The whole ecosystem become more vulnerable to supply chain attacks. I don't see how one follows the other.

goodpoint 5y ago
>> - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. > As opposed to what? Opposed to distributions providing targeted updates to each package. > Dynamic linking does not solve this problem, contrary to popular belief. On the contrary it provably works very well for distributions. >>- Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have to maintain yourself. >Again, as opposed to what? Opposed to distributions that do the huge work of packaging, testing, backporting etc. >>- Licensing issues: distros review licenses (and find plenty of copyright violations while doing so). A flatpak puts you or your company at risk. >Sounds like a good way for a proprietary software to be distributed... This is unrelated to the lack of licensing review. >>- Impact on the ecosystem: the more users switch to opaque blobs the less testing and review is done for proper packages. The whole ecosystem become more vulnerable to supply chain attacks. >I don't see how one follows the other. Supply chain attacks are strongly mitigated by maintainers doing vetting and packaging, and by distribution doing release freezing.
- jcelerier 5y ago
  > On the contrary it provably works very well for distributions. if it worked very well there wouldn't be a need for flatpak / snap / appimage / etc. How do I install an older or newer inkscape / ardour / krita in the latest debian stable / ubuntu / fedora / whatever without recompiling stuff ?

danShumway 5y ago

Worth noting that nothing about Flatpak necessitates that distro maintainers can't compile their own Flatpak apps the same way they currently do. Debian can still compile Firefox from source and patch out trackers and update dependencies, even if at the end of the day it bundles the changes back into another Flatpak app. In fact, the lack of interdependence between apps makes this considerably easier, because a Debian upstream that sits in the middle and custom-compiles it's "official" software can release security updates immediately for critical apps with critical security flaws -- without waiting to make sure that the security fixes don't break some other app. Flatpak does not require you to have a separate upstream for every app, or to get your updates straight from the developer. Debian can still be a middleperson and they can still do all of the same moderation/customization/legal analysis. ---- Very importantly, on security, Flatpak is a paradigm shift away from the existing model of needing complete trust for the entire app: > Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. A big part of this is that you don't trust random developers with Flatpak, or even your own distro maintainers. Most applications do not need the level of access they have by default. The end goal of Flatpak (it is debatable whether it is achieving this, but the goal at least) is to significantly shrink the attack surface of your app. If your calculator app doesn't have file access, or network access, or process forking, or any of these things because the runtime blocks them (and honestly, why on earth would it ever need those things), then it is a lot less dangerous for your dependencies to go out of date. A calculator should not need to worry about updating its dependencies, because it should not have access to anything that could be abused. Now, that's an extreme example. Many apps will not be in the position of needing no privileges, but many of them will still be able to have their attack surfaces shrunk. Firefox for example really shouldn't have that much access to my filesystem. Apps should not (in general) share parts of the filesystem except in user-defined contexts. Many of them don't need Internet access at all. Flatpak makes it easier for dependencies to go out of date, but it also (ideally) drastically reduces the number of potential security flaws you can have in the first place, and drastically reduces the ability of apps to exfiltrate data from other apps (again, this is the ideal, see X11 vulnerabilities + Wayland for how much of an ongoing process fixing Linux security is). ---- I would question a few things: - Is the reduction in attack surface big enough to balance out the extra attention users/devs need to pay to updating dependencies? - How many security vulnerabilities are due to dependency issues vs data exfiltration from the home folder, or from other apps that they have no need to access? Linux security is kind of a disaster in this area, how many vulnerabilities would we fix immediately just by sandboxing filesystem access so /home wasn't a free for all? - Is this actually blocking maintainers from releasing security patches or making it harder for them to do so? I would argue no, I think the maintainers can do the exact same things they're doing today, and that their job may be even easier when they don't need to hold up an entire house of cards with every release. - Is it better to trust Debian to try and patch out every tracker/telemetry, or is there an improvement to having apps that don't require Internet access just be flat-out unable to call home or send telemetry in the first place? I don't think this blocks maintainers from doing their jobs, and it means I just don't have to worry about trackers at all in my calculator app, even if I download it from a 3rd-party source. ---- The weak point here is other Linux vulnerabilities (gotta get off X11!), UX (an eternally hard problem to solve), and Flatpak immaturity/mistakes (I don't like that manifests are still a thing, portals are still being built, I think permissions could be better). But the fundamental concept here isn't bad. People rely on shared libraries/runtimes for a lot of things that they don't need shared runtimes to get. And I can't stress enough: distros can still moderate and compile custom versions of Flatpak apps.