3 ms·

> Apt is by far the easiest way o install and keep software updated. The main issue with distro-centric package formats like deb/rpm is they come from a pre-co

> Apt is by far the easiest way o install and keep software updated. The main issue with distro-centric package formats like deb/rpm is they come from a pre-containers/pre-sandboxing era. Their most ergonomic usage is installing distro-blessed software system-wide, where you trust the distributor to have ensured it's not some malware or other nefarious junk. When it comes to installing software directly provided by third-parties, open or closed, there's a strong need for sandboxing integration at the package level. And once you're sandboxing instances of software, you start needing things like portals to access your files and devices outside the sandbox. If a third-party has provided you with a .deb or .rpm, what's to prevent that package's privileged hooks from doing harm when you install it via dpkg/apt/rpm as root? Let alone the installed software potentially being malicious, the packaging itself can do serious damage. This is a big part of why stuff like flatpak exists today.

hulitu 4y ago
And flatpak is preventing this how ?
- pxc 4y ago
  Flatpak doesn't prevent anything, but it does provide a way for users to avoid those bad things. The format is likely to give Linux users a slightly more BSD-ish separation between core system software and third-party applications, going forward. So 'avoid mucking about with third-party DEB and RPM files' is likely to become a rule of thumb for end users.
- pengaru 4y ago
  AIUI Flatpak attempts to sandbox everything as much as possible. I'm no flatpak dev, nor am I intimately familiar with its implementation. But with little effort glancing at the code one can confirm there's clearly effort to even sandbox triggers: https://github.com/flatpak/flatpak/blob/1.15.3/common/flatpak-dir.c#L7124 https://github.com/flatpak/flatpak/blob/1.15.3/common/flatpa... Note that flatpak builds upon bubblewrap, which descends from linux-user-chroot, a project specifically focused on preventing things like host contamination during package builds over tools like jhbuild. The devs are aware of these issues and aspire to address them. I doubt it's perfect though, and I'm sure there are insecure modes for flatpaks where everything just occurs in the host namespace. But hopefully that's made clear to the end-user before proceeding. I recall there being some brouhaha over flathub misrepresenting some apps as totally secure/sandboxed which shouldn't have been, because they were still running in the host namespace or something like that. I believe that got fixed though.
  - oynqr 4y ago
    Most of the crappy proprietary apps on Flathub still have very broad permissions that make sandbox escape trivial.
devwastaken 4y ago
Flatpak and snap both overwhelmingly had easy to bypass sandboxing policies, and/or the applications did not work because those restrictions were not intended to be used with the software. There can never be a package system where you can safely install malware. Trying to do so has now muddied the process, pushing developers away from learning how to properly package applications, if at all. .appimage makes them obsolete anyways. If I want to distribute malware I don't need a .Deb to do it.

hulitu 4y ago

And flatpak is preventing this how ?

pxc 4y ago
Flatpak doesn't prevent anything, but it does provide a way for users to avoid those bad things. The format is likely to give Linux users a slightly more BSD-ish separation between core system software and third-party applications, going forward. So 'avoid mucking about with third-party DEB and RPM files' is likely to become a rule of thumb for end users.
pengaru 4y ago
AIUI Flatpak attempts to sandbox everything as much as possible. I'm no flatpak dev, nor am I intimately familiar with its implementation. But with little effort glancing at the code one can confirm there's clearly effort to even sandbox triggers: https://github.com/flatpak/flatpak/blob/1.15.3/common/flatpak-dir.c#L7124 https://github.com/flatpak/flatpak/blob/1.15.3/common/flatpa... Note that flatpak builds upon bubblewrap, which descends from linux-user-chroot, a project specifically focused on preventing things like host contamination during package builds over tools like jhbuild. The devs are aware of these issues and aspire to address them. I doubt it's perfect though, and I'm sure there are insecure modes for flatpaks where everything just occurs in the host namespace. But hopefully that's made clear to the end-user before proceeding. I recall there being some brouhaha over flathub misrepresenting some apps as totally secure/sandboxed which shouldn't have been, because they were still running in the host namespace or something like that. I believe that got fixed though.
- oynqr 4y ago
  Most of the crappy proprietary apps on Flathub still have very broad permissions that make sandbox escape trivial.

devwastaken 4y ago

Flatpak and snap both overwhelmingly had easy to bypass sandboxing policies, and/or the applications did not work because those restrictions were not intended to be used with the software. There can never be a package system where you can safely install malware. Trying to do so has now muddied the process, pushing developers away from learning how to properly package applications, if at all. .appimage makes them obsolete anyways. If I want to distribute malware I don't need a .Deb to do it.