Flatpak 1.0 Released For Delivering The Best Linux App Sandboxing

[Candy]

[...] level of sandboxing security wise (AFAIK).

Please don't abuse the word "security" here. There are no long term investigations done and there are no external sources that made an audit over flatpak. I would clearly see some industry like organization that makes security audits like the german BSI or ENISA or NCC to first confirm whethere there are security concerns or not. Just because everyone abuses "security" here (and in special the developers themself) doesn't make it secure at all. It's just a selling argument by causing FUD in the public and trying to catch the customers with the "security" kind of argument.

[treba]

Please don't abuse the word "security" here. There are no long term investigations done and there are no external sources that made an audit over flatpak. I would clearly see some industry like organization that makes security audits like the german BSI or ENISA or NCC to first confirm whethere there are security concerns or not. Just because everyone abuses "security" here (and in special the developers themself) doesn't make it secure at all. It's just a selling argument by causing FUD in the public and trying to catch the customers with the "security" kind of argument.

Ahm sorry, but that's simply wrong. While it's true that there hasn't been any audits AFAIK (therefore allowing the possibility of bugs in the implementation), the concepts they introduce resemble those of mobile platforms like android/iOS. And those have long proven to be very successful.

I agree with you that it's probably a bit early to trust their solutions completely (especially the portals). But at least conceptually they are doing the right things. Plus they build on long established technology (for example cgroups) or on orthogonal projects (pulseaudio, pipewire, wayland).

[Candy]

[...] the concepts they introduce resemble those of mobile platforms like android/iOS. And those have long proven to be very successful.

This is not the same. Neither Android nor iOS require an external proprietary runtime to be downloaded and installed. I haven't seen a single Android nor IOS application coming from the Play-Store or App-Store, that contained anything else than the App-Executable itself, the Ressource-Files (like graphics, texts, audio etc.) and Meta-Information.

You need to understand that Linux is also used within the industry and high sensible areas like Healthcare or Defense. I can't sell this to a customer (argument wise), if there is no proof that the system actually holds what it promises. And I don't wave around in the public hoping that everyone will just deliver flatpaks in the near future, before "questions" has been answered. Otherwise we end up jumping in a big black shit-hole with flatpaks, if someone "official" organizations warn's the customer from using flatpaks because the underlaying eco-system (aka runtime) is a hole for secutiry vulnerabilities because no one want's to update their flatpaks anymore and delivers old outdated and with secutiry flaws contained old libraries etc (e.g. not updating an old libpng or other such libraries).

This is a high security concern and risk.

When we buy say "RHEL" licenses in dozens of packages, then we can be sure that we get the support we need because we paid for it. But with flatpaks companies as Red Hat for example will refuse all responsibility and pointing us to flathub (a community driven platform) and making them responsible for delivering broken programs. This is an absolute no go.

[You-]

This is an interesting update:

Permissions now use an up-front verification model: users are asked to confirm app permissions at install time, if an update requires additional permissions, the user must also confirm.

[boxie]

This is an interesting update:

Permissions now use an up-front verification model: users are asked to confirm app permissions at install time, if an update requires additional permissions, the user must also confirm.

Let's hope that does not lead to user fatigue.

See dialog that is getting in the way of getting the thing done, ignore what it says and click ok.

[starshipeleven]

Please don't abuse the word "security" here. There are no long term investigations done and there are no external sources that made an audit over flatpak.

It's mostly a a frontend, the core functionality is from Linux kernel.

This is not the same. Neither Android nor iOS require an external proprietary runtime to be downloaded and installed.

Google Play Services is an external proprietary runtime.
https://www.androidpit.com/install-g...y-services-apk
So is the Webbkit ("webview") component https://play.google.com/store/apps/d....webview&hl=en

I have no idea about iOS.

And no matter how many times you repeat it, Flatpack runtimes aren't proprietary, they are just dependencies.

[starshipeleven]

Let's hope that does not lead to user fatigue.

See dialog that is getting in the way of getting the thing done, ignore what it says and click ok.

A possible alternative is a preset system.
Afaik PrivacyGuard on Android/LineageOS enforces a preset of permissions denied to applications by default.

But for some things you need to ask the user and the user has to learn to read shit and decide. It's not like you install dozens of applications each day.

[Anarchy]

What advantage does Flatpak hold over Appimage and snaps?

[Ananace]

What advantage does Flatpak hold over Appimage and snaps?

Well, AppImage is a bit of a different beast than Flatpak or Snap, being based more around "uninstalled" application images instead of repository-based installations.

The biggest difference between Flatpak and Snap seems to be that Snap is centralized around the Canonical store, while Flatpak is entirely decentralized in that regard.
Snap also uses a Snap daemon that runs in the background while Flatpak instead consists of a collection of oneshot applications that perform their task and then exit.

Flatpak is also heavily pioneering the portal design where all system access is done through a portal application that lives outside of the sandbox, something that Snap seems to be working towards support of as well.

[M@yeulC]

I would like to get Adobe Reader working in Flatpak or similar framework. My dilemma is I don't want sensitive documents (that requires XFA forms) on my Windows file system and I don't want to run the Linux version of Adobe Reader outside of "a sandbox". At this point in time no open source PDF reader supports the version of XFA forms used by financial institutions and governments that I am forced to work with. Not sure if it's against Adobe Reader's EULA to use it in my desired way. I know there is a playonlinux solution which is currently my best compromise that I am aware of....

I'm not sure either if it would be against the EULA or not to distribute it in such form, but in any case, you should be able to make such a flatpak quite easily (install wine and adobe in the creation script, which runs sanboxed as well, AFAIK. Regarding XFA forms, Okular actually supports them relatively well, and has been improving lately.
In the worst case, I prefer printing them out, then scanning them than using Adobe products. I wish portable html forms were used instead...

Please define "The Best Linux App Sandboxing"

What advantage does Flatpak hold over Appimage and snaps?

Well, sandboxing is based around user namespaces instead of apparmor (snap), so it works on distributions other than Ubuntu for one thing (and Appimage doesn't do sandboxing).
Runtimes are partially shared among applications (with OSTree IIRC), which makes them lighter to download. It is restrictive by default (and now seems to actively asks for permissions), and I like the idea of portals, such as a native file dialog to send over a file instead of giving them whole filesystem access. I think it mirrors a bit Android in that respect.
Flatpaks are auto-updating, Appimages are not, AFAIK.
I'm not sure you can install snaps as an unprivileged user, but you can with flatpaks.

And lastly, I only know how to build flatpaks because someone showed me recently, but it isn't complicated, and dependencies are nicely separated, so I guess updates shouldn't take up a lot of space together with OSTree? I don't think it would be possible to offer binary diffs with Appimage, for instance.

But I must say that while flatpak is nice and tidy for proprietary software or the ones requiring complex dependencies (I use an Android studio flatpak, for instance), it doesn't beat regular package management for software that's packaged by the distribution. Moreover, Nix (or Guix) is really promising for an advanced package manager that can do a lot of the above (but no sandboxing).

Candy you were quite aggressive with you post, and the second part was (I'm sorry) mostly complete bulsh*t. What did platpak developers do to you?