The Great Flatpak debate of 2022

Chat about Zorin
1

Telegram .deb installer:
http://archive.ubuntu.com/ubuntu/pool/universe/t/telegram-desktop/telegram-desktop_2.0.1+ds-1build1_amd64.deb

More trouble than it is worth.
RedHat has broken our trust as often as MS and almost as often as Ubuntu.
Flatpaks end up double sandboxed, which requires users to have to undo some of it just to get some apps to work. Which... you already know. What point is that sandbox when it gets in your way?
Especially when security-wise - it is a sham. Easily bypassed with echo download_and_execute_Malware >> ~/.bashrc

In spite of the claim that Flatpak is the most up to date: It isn't. In fact, for security updates, flatpak lags behind. Flatpaked Gimp for example had the critical vulnerability "shell in the ghost" which was fixed in flatpak about one month after linux distributions had applied the patch.

Or this patch which was a Major Security Update as it allowed using any Flatpak containing an suid binary to grant access to the hosts ROOT:

The Flatpak developers eventually got around to patching this... late... And commented merely it was:

This is a minor security update, matching the behaviour on master
where we avoid ever creating setuid files or world-writable
directories. However, the fix is more localized and does not
require a new ostree.

A "minor secureity update," they said. Minor. Trust -> Gone...
They were more concerned with trying to save face than trying to ensure the security and safety of users. Not... that this is unusual for RH but...

Just my 45 cents.

2

that build is ancient.

3

That is simply wrong, applications are by default not allowed access to these files.

image
image1620×1031 31.1 KB

4

You're right. I am sure it is utterly broken and unusable. :wink:

5

Many flatpaks, even from Flathub, are supported by the community, and not the Developers or Flathub themselves, this can slow down update times significantly.

6

Zorin has Flatpak version 1.10.2, and Flatpak has been improving for a long time now, and won't stop suddenly doing that, especially with wide adoption by many different distributions to the Format.

7

It is simply correct - they are.
many flatpak packages contain filesystem=host, filesystem=home or device=all permissions - Which you know this because you must use them for Flatseal. Plus, many applications would be hopelessly broken without them, due to their inability to communicate with the rest of the system.
Which some flatpaks still actualyl struggle to do...

I have no idea what you are doing in your screenshot... It makes no sense.

That is fine, as long as they make Honest Commentary as they go...
Claiming that major security hole was a Minor Update does not do this.

8

it actually is
half of the messages are unreadable as Telegram either blocks your client entirely, or all you see is "This message is not supported by your version of Telegram, please update your application here: telegram.org/download"

9

Humans are prone to make mistakes, and that is okay.

10

This is exactly why portals were first brought up and developed.

11

this is Librewolf, a firefox fork, with it's default permissionset, unable to access /home/rush/.bashrc

12

Also, I would like to know where you got the information that most applications ship with full home or filesystem access, when some programs won't even run with them granted intentionally? (see: Steam)

Infact, after checking, only 2 applications have any file access outside of what they NEED for it to work

Fondo: Host
Gnome Boxes: Host

13

TGRush, I appreciate your enthusiasm, but it would be helpful if you did not post your thoughts several times in a row. This is not telegram. It is perfectly fine to edit a further thought into a post.
This is a worthwhile debate - as many users have questions. Though we seem to have hijacked your own thread with it...:wink: It can split off, if you like.

Perhaps so, but I do not consider repetitive trust-breaking a mistake. That's a warning to stay away. It is true for significant others...

Your demonstration does not meet relevance as it is One Application, not set up as my example showed.

To me, this only begs the question of "why press on"?
We have a working, stable, and system-compatible APT.

The myth is that Flatpak offers distro agnostic and Highest Version with Best security. As already demonstrated in this thread, this is not really true.
The advantage is that Flatpaks carry all dependencies with it. But it fails at this sometimes, too.
And I do not see that as advantageous - but as Bloat. Microsoft operates the same way and it is one Standardized system with no distros.

You can check in ~/.local/share/flatpak/overrides
By necessity:

https://docs.flatpak.org/en/latest/sandbox-permissions.html
User experiences:

http://transit.iut2.upmf-grenoble.fr/doc/flatpak/flatpak-docs.html
By using the Flatseal; this is demonstrable:

Flatpak developers response to the very same example I gave above:

I partially agree with this. Some directories, like ~/.local/share/flatpak/overrides, are blocked. Even if they have home or host access, they will still need explicit permissions to get read-write access to the blocked directories. Doing this with .bashrc, .zshrc and other shell configuration files would be very useful from a security standpoint to prevent sandbox escape.
However, developers are aware of this problem and are working on it; they have introduced portals.

It's very difficult to claim otherwise, actually. Especially as even the FP Developer addressed it as something to be addressed and worked on.

14

I do agree that a samplesize of 1 is not very, effective to put it that way, it was just supposed to show that an application cannot simply just access that without permission really, though as I've said, my other applications mostly don't have the host or home permissions either by default

I only partially agree with this.
this really depends on who is maintaining any given flatpak, official Flatpaks like the OBS one hosted on Flathub for instance are well supported and get updates fast, meanwhile the Flatpak for Microsoft Teams for example is getting less of that premium treatment.

Yet APT, Pacman (or in extension: AUR helpers), plain dpkg, DNF, yum, eopkg, they all lack some things, notably:

  • being distro agnostic --- as in: not having to repackage for many different distributions and release a tarball, which is just a mess
  • being installed in user-space --- without further configuration of some package managers, easily getting things installed to single users simply isn't an option.
  • being Sandboxed --- unless you're using something like Qubes, your package manager simply isn't going to run your program in a Sandbox for security.

do you mind explaining how uploading a .exe installer (which already exists) to a web server is comparable to either uploading a full multi-arch build of your program, or even setting up your own repository are comparable?

I do not classify making a packaging format as bloat - especially as you're defending traditional packaging - simply for the fact that this not only improves developer-friendlyness for what platform they want to target, but also as this helps improve set some solid standards in the Linux desktop space, specifically things like Portals, or the FreeDesktop standard.

I want to clear up my stance on this a little bit, I am not trying to say that Flatpak is perfect and EVERYBODY should ONLY use that, after all, Linux offers choices, and I want to embrace that. Though for me, and most other desktop users I would assume, something like Flatpak is advantageous, especially with Permissions similar to how they're used to having it on their Phone, and security measures which just happen in the background without the user even noticing

I think the solution to the big issue you're mentioning here - that is insecurity of the sandbox in several places due to permissions - is a refactoring of some Flatpak default overrides, as well as a more sophisticated review process for Flatpak applications uploaded to Flathub. and NOT to just trash the project or refrain from using it intentionally because of these reasons

15

either way it looks like this discussion won't get my issue resolved lol

16

This is why I point out that Flatpak and Snap count as double sandboxed..
This needs clarification:
All apps are sandboxed. From APT and elsewhere. That is Linux.
Flatpak and Snap sandbox again and then use "Sandboxing" as their selling point.
You can plainly see the absurdity, here.

Dragging dependencies with it.

I do qualify it as Bloat, more specifically on the Snap Side, as it double or triple installs dependencies.
Flatpak is better about this; I agree. Generally, it is supposed to install dependencies only if needed and once installed, they remain and are accessed by other flatpaks that need them.
So, I kind of agree with you on this topic: Flatpak is Less Bloaty than Snap.
However...
It installs the Same Dependencies you already have installed... For Flatpak.
So, yes, that is bloat.

I have stated my own reasons: They break trust.
I can understand and forgive a mistake.
But I cannot forgive calling a major patch a "minor security update."
At all.
Any developer can make mistakes.
But the important thing is to Own Up to them. Address them. Make right.
Don't mislead.
The Flatpak Devs chose to mislead and once they did that - trust was broken. That is the whole purpose of my presence on Linux- to get away from that behavior with Google and Microsoft and others.
I do not believe it is unreasonable to Shun Flatpak for engaging in that behavior.

I will consider this a Split Request and so...
Done.

17

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.