8 ms·

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 sti

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.

joconde 5y ago
> 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. Does that mean I'll download one copy of libThatWasUpdated for every app that uses it? Seems like this is exactly like iOS and Android work. I see the appeal (they are definitely more secure against malicious apps than Linux with apt-get), but the waste of space still bothers me. Docker has the same issue, and didn't really solve it with its layered filesystem (you always need several dependencies, but you can't merge images, so you'll need to install a new copy of some of them). These packages also make it hard to audit the versions of security-critical code installed on my system. It's good that they can be updated separately by the OS, but at least when apt-get was upgrading shared libraries, I could be sure that all programs had the fix. Now I'll need to go dive into each package to know if it should be allowed to run, or if I should wait for the upgrade.
- deleted 5y ago
  [deleted]
- danShumway 5y ago
  > These packages also make it hard to audit the versions of security-critical code installed on my system. I think someone else has mentioned this somewhere, but Flatpak exposes information about the runtime it's using -- you can use metadata tools to iterate over the packages installed and check to see if any of them are outdated. I suppose the tooling in that area could be improved, but I suspect that's something that would happen in parallel with more maintainers getting involved in validating/moderating packages. I could easily see a world where you specify a set of minimum runtime versions (or pin an exact runtime version) and set up some rules about what packages you'll allow to run. Importantly, if you do have a critical vulnerability, you can make a list of the packages in your system that would be affected, and if you're willing to re-bundle them you can update the runtime for just them, which means if you're a maintainer you can push that update out immediately for those programs to everyone; you don't have to wait until somebody has finished checking to see if the update breaks a calculator app that doesn't have Internet or file access anyway. I don't think there's anything about Flatpak that blocks this kind of auditing (and the core technology may end up making it easier in the long run). So I do get the criticism, but it seems like the criticism here is more, "we need some more focus given to better userland tools" and not "this is the wrong technical/architectural direction to go." ---- > at least when apt-get was upgrading shared libraries, I could be sure that all programs had the fix Ironically, this is kind of the same behavior that the linked article calls out. You really couldn't be sure about that back then. Plenty of packages embed critical libraries like libsodium and don't use the shared versions. It is very common advice in the Linux world (particularly with games) to embed as many system libraries as reasonably possible, and regardless of whether or not that's good advice, developers do it. So right now, you're trusting package maintainers to catch that stuff and make sure that the dependencies are updated across the board (or converted into calls to shared libraries) even if the source code isn't using shared libraries by default. And after Flatpak, you'll still to some degree be trusting maintainers to do that, and you'll still be trusting maintainers to say that "updating libsodium" means updating every package that depends on it. The difference with Flatpak is that this is now very explicit and obvious to you, which may be a good thing because (in the article's words) it seems that the single shared runtime model "leads people to place more trust than they should" in their ability to ensure that applications are actually using system libraries. ---- > but the waste of space still bothers me I don't have too much to say here, it's a legit worry. I think this mostly comes down to how much space will actually be wasted in practice. Docker seems to be relatively inefficient about this, I'm not sure if Flatpak is better or not. But yeah, it would be good to minimize size as much as possible, I do understand that concern.

joconde 5y ago

> 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. Does that mean I'll download one copy of libThatWasUpdated for every app that uses it? Seems like this is exactly like iOS and Android work. I see the appeal (they are definitely more secure against malicious apps than Linux with apt-get), but the waste of space still bothers me. Docker has the same issue, and didn't really solve it with its layered filesystem (you always need several dependencies, but you can't merge images, so you'll need to install a new copy of some of them). These packages also make it hard to audit the versions of security-critical code installed on my system. It's good that they can be updated separately by the OS, but at least when apt-get was upgrading shared libraries, I could be sure that all programs had the fix. Now I'll need to go dive into each package to know if it should be allowed to run, or if I should wait for the upgrade.

deleted 5y ago
[deleted]
danShumway 5y ago
> These packages also make it hard to audit the versions of security-critical code installed on my system. I think someone else has mentioned this somewhere, but Flatpak exposes information about the runtime it's using -- you can use metadata tools to iterate over the packages installed and check to see if any of them are outdated. I suppose the tooling in that area could be improved, but I suspect that's something that would happen in parallel with more maintainers getting involved in validating/moderating packages. I could easily see a world where you specify a set of minimum runtime versions (or pin an exact runtime version) and set up some rules about what packages you'll allow to run. Importantly, if you do have a critical vulnerability, you can make a list of the packages in your system that would be affected, and if you're willing to re-bundle them you can update the runtime for just them, which means if you're a maintainer you can push that update out immediately for those programs to everyone; you don't have to wait until somebody has finished checking to see if the update breaks a calculator app that doesn't have Internet or file access anyway. I don't think there's anything about Flatpak that blocks this kind of auditing (and the core technology may end up making it easier in the long run). So I do get the criticism, but it seems like the criticism here is more, "we need some more focus given to better userland tools" and not "this is the wrong technical/architectural direction to go." ---- > at least when apt-get was upgrading shared libraries, I could be sure that all programs had the fix Ironically, this is kind of the same behavior that the linked article calls out. You really couldn't be sure about that back then. Plenty of packages embed critical libraries like libsodium and don't use the shared versions. It is very common advice in the Linux world (particularly with games) to embed as many system libraries as reasonably possible, and regardless of whether or not that's good advice, developers do it. So right now, you're trusting package maintainers to catch that stuff and make sure that the dependencies are updated across the board (or converted into calls to shared libraries) even if the source code isn't using shared libraries by default. And after Flatpak, you'll still to some degree be trusting maintainers to do that, and you'll still be trusting maintainers to say that "updating libsodium" means updating every package that depends on it. The difference with Flatpak is that this is now very explicit and obvious to you, which may be a good thing because (in the article's words) it seems that the single shared runtime model "leads people to place more trust than they should" in their ability to ensure that applications are actually using system libraries. ---- > but the waste of space still bothers me I don't have too much to say here, it's a legit worry. I think this mostly comes down to how much space will actually be wasted in practice. Docker seems to be relatively inefficient about this, I'm not sure if Flatpak is better or not. But yeah, it would be good to minimize size as much as possible, I do understand that concern.