My bigger concern with things like Flatpack is security updates for dependencies. If 10 different packages on my system depend on libfoo, the package maintainers will ensure that only one or two versions of libfoo are shipped. If there’s a CVE in libfoo, there’s a coordinated disclosure mechanism in place and the package maintainers will push out an updated package set with everything (including statically linked packages) built with the new version.
The selling point of things like Flatpack is that each app can depend on a different version of libfoo without conflicts. So now I may have 10 different versions of libfoo. Upstream libfoo provides the CVE fix in their main branch. How many of the Flatpak authors bundling libfoo are on their coordinated disclosure list? How many are able to back port a security fix to the version that they bundle?
The mindset that says ‘we have a difficult problem, we solve it by introducing a combinatorial multiplier’ is one that I do not understand.
The whole Flatpaks world is built on a very different set of premises, which I guess aren’t bad on paper but they don’t really hold in the wider Linux world. The “base” model for Flatpak, in which author-packaged applications only depend on the libraries in the runtime they run on (e.g. one of these), handles these things reasonably well. The runtime is actively maintained, basically just as well as in a well-maintained distro (unsurprising, things like GTK and GStreamer receive timely updates in mainstream distros as well). The part that Flatpak is expected to handle better is that when there’s an update (possibly, though not necessarily security-related) in an application. If the author publishes a Flatpak build, anyone can get it, without depending on their distribution’s maintainers.
This is the model we all know (kind of) from e.g. Android but it’s a pretty bad fit for the Linux world. None of the runtimes cover as much ground as the Android SDK does, so lots of non-trivial apps will end up depending on some libfoo sooner or later.
Also based on lessons from Android world, I think this just assumes a lot more goodwill on application authors than is warranted and we’re gonna be learning that more and more as Flatpak becomes more common. There’s a good example in the article.
This kind of model works moderately well on systems like Windows and macOS, where the base system provides a few GiBs of libraries that provide almost all dependencies. Even then, it’s painful. There are third-party tools available that look inside macOS .app bundles and try to find known-vulnerable versions of .dylib files that people have bundled and failed to update. That doesn’t catch things that have statically linked dependencies into the main app binary but they routinely trigger on actively maintained apps from big-name publishers.
Android is a mess in this regard. A huge number of apps in the Google Play Store bundle old versions of libraries / frameworks and often these have security vulnerabilities. It’s mostly okay because most Android apps don’t deal with untrusted data (or, if they do, only via a system-provided web view, which is updated separately).
Android is a mess in this regard. A huge number of apps in the Google Play Store bundle old versions of libraries / frameworks and often these have security vulnerabilities. It’s mostly okay because most Android apps don’t deal with untrusted data (or, if they do, only via a system-provided web view, which is updated separately).
Yeah, I know :-(. Lots of people in the Linux desktop community see it through the rose-tinted glasses of architecture documents and basic apps, and are then horrified to find what hacks are needed to keep it spinning.
I didn’t mention how poorly that ended up working even on Android because I think Flatpak is years away from that being the primary practical problem. Who knows, maybe in a few years we’ll just have an org.debian.libs runtime or whatever and bundling outdated libraries won’t be as big a problem. You can’t bundle every library out there but I wouldn’t be surprised if bundling the top 100 libraries by download count which aren’t already part of the XDG runtime or one of the desktop runtimes covered enough of the packages Debian offers that anything left out is probably not that big a catastrophe.
But until then, if you try to use it, it’s still pretty obvious that this is a distribution & sandboxing layers shoehorned into a framework that was never built with isolation in mind. So interface papercuts aside (e.g. things like font rendering settings aren’t very well integrated), lots of large applications still need to be packaged with very loose permissions, and still end up ran in an environment where sandboxing is not universal. Escaping the sandbox is probably pretty difficult at this point but eluding it is still kindda trivial in virtually every real-world setup. E.g. the big bad vulnerable browser runs in a sandbox which is obviously better than not at all but if you double-click a bad file you downloaded with it (or get bit by a thumbnailing-related CVE, as it happened years ago) in Files/Nautilus/Thunar/Dolphin/whatever you’re still pretty screwed, because those are probably not sandboxed anywhere.
None of the runtimes cover as much ground as the Android SDK does, so lots of non-trivial apps will end up depending on some libfoo sooner or later.
FWIW, Flathub runs flatpak-external-data-checker, which is somewhat similar to dependabot and renovate. You specify some metadata for each module in the manifest (a JSON or YAML file describing how to build the Flatpak) and fedc will automatically open pull requests when those modules need updating. We at Endless originally wrote it to update the main app module, but is now used by many apps to update their dependencies, too.
flatpak-external-data-checker is really cool and more people should know about it because lots of them don’t know this is automated to some degree (so, upvote, too!). However, I think the parent post is about a problem that can’t really be solved with software, because it’s a social/maintenance problem, not a technical problem.
Indie developers have astonishing response times but they’re not always a match for the security teams of major distros, if only because of sheer numbers and time zones.
I mean I was stuffing my face with bacalhau in Portugal when KRACK hit. I think Debian had security updates the day it was announced. flatpak-external-data-checker could’ve opened PRs or dispatched a pesterbot to harangue me and make sure my wine was always a little warmer than it had to be, it would’ve still taken me a week to update my flatpaks because I was on holiday with nothing but a tablet on me.
Lots of applications on Flathub (and Apple’s AppStore, and Google Play, and many others) are one-man shows. It’s a little unrealistic to expect them to have security teams. Tools like flatpak-external-data-checker help bridge the gap between “vulnerability announced” and “maintainer knows”, which is super useful in its own right (because I used to do it and monitoring all relevant lists for your program was not cool). But once the PR is open you’re still depending on manual action from someone who might be days away from even seeing the PR in the first place.
The “traditional” way is only viable if the security update doesn’t modify the ABI, which may be the case for more established and mature libraries with long support cycles but it doesn’t necessarily apply in general.
ABI changes are not a problem. The package set is rebuilt and picks up the changes. API or subtle logic changes are a problem because they require source-code modification to fix. Containerised package distribution does not help with this. The work still needs to be done, only now it needs to be done in more places.
Your bottles are isolated from the system and will only hit your personal files when you decide. (only when using Flatpak)
To have downstream packages, completely removes the security protections provided. The complaints that flatpaks are done wrongly also don’t make much sense in this aspect, it has an incentive to be better at flatpaking than other applications.
he does not trust that upstream Flatpaks “follow any standard except standard of their authors”
The program downloads and runs community forks of Wine, which arn’t included in Fedora Packages. One has to wonder if the person complaining even ran the software?
My bigger concern with things like Flatpack is security updates for dependencies. If 10 different packages on my system depend on libfoo, the package maintainers will ensure that only one or two versions of libfoo are shipped. If there’s a CVE in libfoo, there’s a coordinated disclosure mechanism in place and the package maintainers will push out an updated package set with everything (including statically linked packages) built with the new version.
The selling point of things like Flatpack is that each app can depend on a different version of libfoo without conflicts. So now I may have 10 different versions of libfoo. Upstream libfoo provides the CVE fix in their main branch. How many of the Flatpak authors bundling libfoo are on their coordinated disclosure list? How many are able to back port a security fix to the version that they bundle?
The mindset that says ‘we have a difficult problem, we solve it by introducing a combinatorial multiplier’ is one that I do not understand.
The whole Flatpaks world is built on a very different set of premises, which I guess aren’t bad on paper but they don’t really hold in the wider Linux world. The “base” model for Flatpak, in which author-packaged applications only depend on the libraries in the runtime they run on (e.g. one of these), handles these things reasonably well. The runtime is actively maintained, basically just as well as in a well-maintained distro (unsurprising, things like GTK and GStreamer receive timely updates in mainstream distros as well). The part that Flatpak is expected to handle better is that when there’s an update (possibly, though not necessarily security-related) in an application. If the author publishes a Flatpak build, anyone can get it, without depending on their distribution’s maintainers.
This is the model we all know (kind of) from e.g. Android but it’s a pretty bad fit for the Linux world. None of the runtimes cover as much ground as the Android SDK does, so lots of non-trivial apps will end up depending on some libfoo sooner or later.
Also based on lessons from Android world, I think this just assumes a lot more goodwill on application authors than is warranted and we’re gonna be learning that more and more as Flatpak becomes more common. There’s a good example in the article.
This kind of model works moderately well on systems like Windows and macOS, where the base system provides a few GiBs of libraries that provide almost all dependencies. Even then, it’s painful. There are third-party tools available that look inside macOS .app bundles and try to find known-vulnerable versions of .dylib files that people have bundled and failed to update. That doesn’t catch things that have statically linked dependencies into the main app binary but they routinely trigger on actively maintained apps from big-name publishers.
Android is a mess in this regard. A huge number of apps in the Google Play Store bundle old versions of libraries / frameworks and often these have security vulnerabilities. It’s mostly okay because most Android apps don’t deal with untrusted data (or, if they do, only via a system-provided web view, which is updated separately).
Yeah, I know :-(. Lots of people in the Linux desktop community see it through the rose-tinted glasses of architecture documents and basic apps, and are then horrified to find what hacks are needed to keep it spinning.
I didn’t mention how poorly that ended up working even on Android because I think Flatpak is years away from that being the primary practical problem. Who knows, maybe in a few years we’ll just have an
org.debian.libsruntime or whatever and bundling outdated libraries won’t be as big a problem. You can’t bundle every library out there but I wouldn’t be surprised if bundling the top 100 libraries by download count which aren’t already part of the XDG runtime or one of the desktop runtimes covered enough of the packages Debian offers that anything left out is probably not that big a catastrophe.But until then, if you try to use it, it’s still pretty obvious that this is a distribution & sandboxing layers shoehorned into a framework that was never built with isolation in mind. So interface papercuts aside (e.g. things like font rendering settings aren’t very well integrated), lots of large applications still need to be packaged with very loose permissions, and still end up ran in an environment where sandboxing is not universal. Escaping the sandbox is probably pretty difficult at this point but eluding it is still kindda trivial in virtually every real-world setup. E.g. the big bad vulnerable browser runs in a sandbox which is obviously better than not at all but if you double-click a bad file you downloaded with it (or get bit by a thumbnailing-related CVE, as it happened years ago) in Files/Nautilus/Thunar/Dolphin/whatever you’re still pretty screwed, because those are probably not sandboxed anywhere.
FWIW, Flathub runs flatpak-external-data-checker, which is somewhat similar to dependabot and renovate. You specify some metadata for each module in the manifest (a JSON or YAML file describing how to build the Flatpak) and fedc will automatically open pull requests when those modules need updating. We at Endless originally wrote it to update the main app module, but is now used by many apps to update their dependencies, too.
flatpak-external-data-checker is really cool and more people should know about it because lots of them don’t know this is automated to some degree (so, upvote, too!). However, I think the parent post is about a problem that can’t really be solved with software, because it’s a social/maintenance problem, not a technical problem.
Indie developers have astonishing response times but they’re not always a match for the security teams of major distros, if only because of sheer numbers and time zones.
I mean I was stuffing my face with bacalhau in Portugal when KRACK hit. I think Debian had security updates the day it was announced. flatpak-external-data-checker could’ve opened PRs or dispatched a pesterbot to harangue me and make sure my wine was always a little warmer than it had to be, it would’ve still taken me a week to update my flatpaks because I was on holiday with nothing but a tablet on me.
Lots of applications on Flathub (and Apple’s AppStore, and Google Play, and many others) are one-man shows. It’s a little unrealistic to expect them to have security teams. Tools like flatpak-external-data-checker help bridge the gap between “vulnerability announced” and “maintainer knows”, which is super useful in its own right (because I used to do it and monitoring all relevant lists for your program was not cool). But once the PR is open you’re still depending on manual action from someone who might be days away from even seeing the PR in the first place.
The “traditional” way is only viable if the security update doesn’t modify the ABI, which may be the case for more established and mature libraries with long support cycles but it doesn’t necessarily apply in general.
ABI changes are not a problem. The package set is rebuilt and picks up the changes. API or subtle logic changes are a problem because they require source-code modification to fix. Containerised package distribution does not help with this. The work still needs to be done, only now it needs to be done in more places.
Confusing!
The one of the features of Bottles is
To have downstream packages, completely removes the security protections provided. The complaints that flatpaks are done wrongly also don’t make much sense in this aspect, it has an incentive to be better at flatpaking than other applications.
The program downloads and runs community forks of Wine, which arn’t included in Fedora Packages. One has to wonder if the person complaining even ran the software?