3 ms·

> You'd expect individual applications might have out of date dependencies. Depending on the application this might be completely fine. This is not a security r

> You'd expect individual applications might have out of date dependencies. Depending on the application this might be completely fine. This is not a security risk of flatpak but of the application. Developers are responsible for releasing updates, not flatpak. Not so much in a system that links executable dynamically to system provided libraries (e.g. Debian), or provides system wide maintenance updates to statically linked binaries when their dependencies receive important updates (e.g. Alpine). ...which really covers every sane, actively maintained *nix system with a package manager, so in that sense Flatpak is definitely a step down. Instead of trusting, say, the Debian or OpenBSD maintainers to provide timely security updates, you have to trust each individual vendor of your flatpaks. The only advantage I can see for them is in providing closed source software, which OS maintainers simply can't maintain and update. A developer advantage may be that the standard of inclusion is much lower than for Debian or OpenBSD, but that's IMO a user disadvantage.

mixedCase 6y ago
> Instead of trusting, say, the Debian or OpenBSD maintainers to provide timely security updates, you have to trust each individual vendor of your flatpaks. Well, yes, and it's the most obvious approach. You're trusting the person producing the product for producing a good product. The distro approach is great, but it doesn't scale well for obvious reasons and it makes software development harder due to downstream issues often going reported as upstream issues. I appreciate and enjoy the distro approach for what it gives me, but there should always be a way for developers to provide packaging that works everywhere and then distro maintainers can feel free to recompile/repackage as they please.
- boomlinde 6y ago
  > You're trusting the person producing the product for producing a good product. That's a generalization. Specifically, I'm trusting the person producing the product to do something that e.g. Debian has a proven track record of doing quite well: maintaining dependencies so that I have a secure (and consistent) system altogether...so well that I'd rather trust them to do it over any existing flatpak vendor, and definitely more than trusting n vendors for the n flatpaks I have installed. > The distro approach is great, but it doesn't scale well for obvious reasons Regarding what aspect doesn't it achieve the scale necessary? It's not obvious to me what you mean at all. > and it makes software development harder due to downstream issues often going reported as upstream issues. A cost of system-scale software maintenance, for sure. > I appreciate and enjoy the distro approach for what it gives me, but there should always be a way for developers to provide packaging that works everywhere and then distro maintainers can feel free to recompile/repackage as they please. I don't fundamentally disagree. My point is that I think it's a security risk to leave it to every developer to maintain their dependencies as they see fit, and that this is a problem that flatpaks create that a well maintained distro software repo doesn't have. It's better to acknowledge this risk and consider it to grow as you install more flatpaks than to ignore it, expecting that every flatpak vendor will respond in a timely manner to dependency CVEs; the trust I place in Debian—by necessity very high—now has to be multiplied for each individual flatpak.

mixedCase 6y ago

> Instead of trusting, say, the Debian or OpenBSD maintainers to provide timely security updates, you have to trust each individual vendor of your flatpaks. Well, yes, and it's the most obvious approach. You're trusting the person producing the product for producing a good product. The distro approach is great, but it doesn't scale well for obvious reasons and it makes software development harder due to downstream issues often going reported as upstream issues. I appreciate and enjoy the distro approach for what it gives me, but there should always be a way for developers to provide packaging that works everywhere and then distro maintainers can feel free to recompile/repackage as they please.

boomlinde 6y ago
> You're trusting the person producing the product for producing a good product. That's a generalization. Specifically, I'm trusting the person producing the product to do something that e.g. Debian has a proven track record of doing quite well: maintaining dependencies so that I have a secure (and consistent) system altogether...so well that I'd rather trust them to do it over any existing flatpak vendor, and definitely more than trusting n vendors for the n flatpaks I have installed. > The distro approach is great, but it doesn't scale well for obvious reasons Regarding what aspect doesn't it achieve the scale necessary? It's not obvious to me what you mean at all. > and it makes software development harder due to downstream issues often going reported as upstream issues. A cost of system-scale software maintenance, for sure. > I appreciate and enjoy the distro approach for what it gives me, but there should always be a way for developers to provide packaging that works everywhere and then distro maintainers can feel free to recompile/repackage as they please. I don't fundamentally disagree. My point is that I think it's a security risk to leave it to every developer to maintain their dependencies as they see fit, and that this is a problem that flatpaks create that a well maintained distro software repo doesn't have. It's better to acknowledge this risk and consider it to grow as you install more flatpaks than to ignore it, expecting that every flatpak vendor will respond in a timely manner to dependency CVEs; the trust I place in Debian—by necessity very high—now has to be multiplied for each individual flatpak.