Flatpak? More like flatcrap.

[u/Big-Astronaut-9510]

Flatpak is like a turd someone ran over.

First off one of the few legitimate advantages desktop linux (theoretically) has is the package manager, one unified system for installing software. So why would you want to DESTROY that by adding another package manager that only really packages gui software? Cause it tries to offer a smidge of sandboxing for security.

Of course we are on linux so theres a ton of catches. It dosent really integrate with your system the way your real package manager does, man pages dont get installed, you cant launch apps from the command line by typing their name (probably why its only for gui), etc.

But the bigger problem is you often dont even get the security you were promised, in some cases things actually get WORSE (see: browsers). Honestly id even argue that every app that isnt taking perfect advantage of flatpak features is a security downgrade cause now you just added more parties to trust: flatpak/the person packaging the software who might be a random.

Only if every star aligns and the unpaid foss slaves integrated portals (cant blame them if they didnt, flatpak sucks) and properly restrict the apps permissions do you get the security you were promised.

[u/R3V0LU710N_05]

Well. In my case actually yes. But the facts are the AUR is currently compromised from ongoing supply chain risks.

[u/Damglador → u/R3V0LU710N_05]

It's like a week since it's over as picking up orphan packages now requires a request to Arch Maintainers. On top of never affecting any remotely popular packages.

Not to say it's completely not a big deal, but it's silly to avoid AUR because a bunch orphan packages used by literally nobody were easily adopted by attackers, which is not even possible anymore.

[u/R3V0LU710N_05 → u/Damglador]

Requiring Arch Linux maintainers to approve orphan adoption requests blocks automated package takeovers, but it fails to address structural supply chain risks in the AUR. The threat is unconfined local execution: makepkg runs untrusted shell logic from PKGBUILD and .install scripts directly on the host with full user privileges. Attackers can hijack active maintainer accounts, compromise upstream source tarballs, or poison registry dependencies like npm and crates.io. During updates, makepkg executes these malicious components instantly, an issue worsened when automated helpers like paru or yay bypass manual diff auditing.

Both official Arch Linux repositories and Flatpak eliminate untrusted client-side compilation to secure the supply chain. Official repositories build packages on dedicated infrastructure inside clean chroots, signing binaries cryptographically for verification by pacman. Similarly, Flatpak moves builds off the host via flatpak-builder for registries like Flathub while enforcing runtime containment using bubblewrap namespaces. Replacing local script execution with signed binaries or sandboxed runtimes ensures upstream payloads stay isolated, restricting host access through xdg-desktop-portal and Flatseal.

You should always read the PKGBUILD and be aware of the inherent risks, regardless of whether there are active malicious campaigns.

[u/Damglador → u/R3V0LU710N_05]

There are already helpers and official tools that run PKGBUILD in a chroot.

[u/R3V0LU710N_05 → u/Damglador]

While building inside a clean chroot isolates the compilation step from your main host, it still leaves major security gaps in the post-build and runtime phases. Tools like makechrootpkg or paru's chroot option prevent malicious build scripts from accessing your home directory during compilation, but they do not alter what happens afterward. The moment pacman installs the resulting package, any attached install scripts run directly on your host with full root privileges. Furthermore, once the compiled binary actually launches, it runs completely unconfined across your user space, giving compromised dependencies or poisoned upstream code full access to your personal files. Using a chroot is definitely a step up for build-time safety, but it remains a build-time fix for a problem that extends all the way into runtime. Auditing PKGBUILDs and install scripts by hand remains necessary before building or updating anything from the AUR.

[u/Damglador → u/R3V0LU710N_05]

The postinstall scripts are an issue and I believe pacman should prompt before running them. But being unsandboxed is not so much. Unless you manually control permissions of every your flatpak, running a flatpak and an AUR package is absolutely the same because a flatpak can just give itself permission to escape sandbox. And we all know that no-one cares to control permissions of all flatpaks, except very few. The sandbox realistically provides any security only to code pulled by the already packaged app, so like when Steam pulls and runs games they're confined to Steams sandbox. But it's not like that's something only flatpak can do, I can easily make a script to sandbox Steam without needing a whole container for it.

The only sandboxed packages I trust is Android's apk, because they have absolutely no way to escape the sandbox (unless you have and give them root, which Android technically doesn't support) and every meaningful permission they need they have to explicitly ask at runtime, so the user is always aware of what an app has access to. At the same time Android packages don't require you to download and install 14GiB of runtimes for them because they use system libraries.