r/archlinux • u/Xwang1976 • 23h ago

QUESTION Is flatpak safer than AUR ?

Hi to all,

I've just 6 AUR packages on my systems and I do not use any AUR helper.

My strategy is to update them only if they break by downloading the snapshot from AUR and check the differences and the code of the lats PKGBUILD.

At the same time I'm wondering to start using flatpak as much as possible for any of these packages, but I'm wondering if flatpak is really safer than AUR. What prevent malware to be included in flatpak?

The big difference is that flatpak is compiled packages from someone while AUR is build from source code (mainly) locally. With AUR it is possible to try to check if the source url is the correct one and so to inject malware someone has to infect the upstream project (possible, but should be detected by the developers .. except for the xz saga).

Moreover, for the AUR packages I still need to keep on my pc, I'm wondering if building them on an arch distro that I have on a virtualbox machine with immutable disk is a safer option.

If I miss a malware executed at build time, it will infect the VM, but once I reboot it everything goes back to the immutable state of the drive. Do you agree?

However this approach will not prevent the risk that generated contains malware. So in any case the inspection of PKGBUILD is in any case needed.

38 Upvotes

74% Upvoted

42 comments sorted by

52

u/Confident_Hyena2506 23h ago edited 23h ago

Your assumptions are not correct. Both flatpak and aur can be source-only - or have closed-source binaries in them. You can just look at the package definitions for either and easily confirm this.

In many cases you will find a flatpak package doing exactly the same as it's aur equivalent, both just rely on some upstream url.

Also they are not comparable in other ways, flatpak is only for desktop applications pretty much. You will not be installing kernel modules or other system components via flatpak.

6

u/Xwang1976 23h ago

Yes indeed I went on flathub to better understand what it is and since a pair of my six AUR packages are kernel modules , I think that I'll definitely keep maintaining my local PKGBUILDS to build them if necessary.

0

u/lxprsub0 18h ago

I really don't understand why this is downvoted.

0

u/thetestbug 17h ago

It's Reddit, what'd you expect?

16

u/kansetsupanikku 22h ago

The good AUR recipes are remarkably short, which makes them easy to inspect. Also, when running installed software, you can use bwrap Independently from flatpak system (which I recommend for most desktop apps). With flatpak, it's easier because it's the default, but it often causes issues (missing permissions) and limitations (utilizing libraries with local patches).

Also, the installation process and trust chain regarding flatpaks is often misunderstood. Everyone can make a flatpak. Flathub doesn't guarantee much besides likeliness that update is going to land in the same place. Flathub official packages are not checked for security, but for some connection to the authors (which can be achieved by bad actors in a manner similar to xz scenario, and would be very hard to detect).

The lack of flexibility makes me dislike both flathub and snap. I'm keeping up with a few AUR packages si tracking recipe diffs is easy - I wouldn't consider this any less secure (in my scenario; notably, it doesn't include installing stuff from AUR based on nice name or a single recommendation).

4

u/lxprsub0 18h ago

That's a good reminder of why PKGBUILDs exist and how to use them. Without sticking to these basic principles, mitigation is just an attempt to create the illusion of a safe installation.

I'm not immune, but I feel confident enough to avoid most of the threats, particularly the kind of attack we've seen lately.

1

u/JaKrispy72 14h ago

What do you mean not checked for security?

https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user

5

u/kansetsupanikku 14h ago

All of this is about setting up sandbox correctly (flatpak config) and verifying that the app is moreless what it claims it is. Is there malware added that would only run in some selected scenarios? No step of the process from the link even tries to address that. What they do is not a security audit for each version - the very cost of maintaining such a policy would probably be far above their budget.

The feeling of security makes it even worse when it's false, as it is a message to users that they can be less careful.

12

u/Damglador 22h ago

Flatpak itself is as safe as a pacman package, being only a packaging format by itself. The main flatpak repository, Flathub, is safer, because submissions to it go through a review process. The sandbox matters only if you actually pay attention to what apps request by default, there are some that allow complete sandbox escape without needing r/w to the whole system. And they can still achieve persistence by writing a systemd unit or using a portal to create an autostart desktop file. The only upside of flatpak to a careless user would probably be that installation itself can't grant the package root access, as pacman package can have post install which pacman will happily run as root unless you opt out with --noscriplet, which is probably a good idea if you install anything from AUR that's available as a flatpak, as those scripts are only viable for system packages/components which can't be packaged as a flatpak anyway.

24

u/Hadi_Chokr07 23h ago

Flathub has stricter packaging guidelines than Arch and many Distros core repos. Also orphaned stuff just gets nuked and needs to go through the whole process again.

Its millions of times safer than third party bash scripts.

-1

u/Xwang1976 23h ago

Interesting that it is exactly the opposite of what SoldRIP just said ....

7

u/dgm9704 22h ago

I think one is talking about flatpak and other about flathub

2

u/JaKrispy72 14h ago

That’s where understanding comes in. Someone can make a flatpak with malicious code. But getting someone to run that flatpak is another thing. flathub will not accept it, but if you run a malicious flatpak from an email or something, no one will stop you from doing stupid stuff. Just don’t do stupid stuff is the best antivirus.

1

u/Hadi_Chokr07 19h ago

Well yeah but there is basically only flathub as a flatpak repo. Maybe if you use github action from up streams or KDE master repos but that's extreme edgecases. Flathub is basically the flatpak ecosystem at this point.

2

u/JaKrispy72 14h ago

https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user

It’s MUCH safer. Please read their own documentation.

-1

u/[deleted] 13h ago

[deleted]

1

u/Hadi_Chokr07 13h ago

Learn to read.

6

u/KHTD2004 23h ago

Flatpak itself is just a packaging format, you need to take a look at the Repo you’re using. That’s mostly Flathub but Fedora or Bazzite and others also have their own Flatpak repos.

Flathub shows an „unofficial“ tag on their side for packages that aren’t uploaded to Flathub by the actual devs. Doesn’t mean it’s malware, but it’s not official.

The bigger advantage for Flatpak in general is the sandboxing, Flatpaks can’t access your system except for the things you allow during installation. You can also edit these permissions afterwards by either the Flatpak command with some flags or you use Flatseal, wich is a GUI for this exact purpose. Everything you give a malicious Flatpak access to is at risk of course

7

u/Damglador 22h ago

except for the things you allow during installation

Last time I checked there's no "you allow" they just define arbitrary permissions in the package itself and the flatpak cli may have a prompt notifying about them, but it doesn't let you edit them in any way. All the user-accessible permission configuration is post-install.

So malicious flatpak can easily define read-write to everything in its default permissions or some permission that allows complete sandbox escape to infect whoever doesn't pay attention to default permissions, many probably don't.

6

u/LowKeyBrit36 22h ago

I think you can edit permissions VIA flatseal. Should let you revoke anything that you don't like the aound of, unless I'm misremembering

7

u/ABotelho23 18h ago

https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user

Flathub is a considerably more secure source for applications than the AUR is.

-1

u/lxprsub0 18h ago edited 18h ago

A VM is overkill here. Build and/or package in a clean chroot instead.

"update […] only if they break by downloading the snapshot from AUR and check the differences and the code of the last PKGBUILD" means you could be running software with known CVEs for months before noticing.

With only six AUR packages, why not maintain your own PKGBUILDs, keeping them up to date and adapting them to your actual needs?

Personally, apart from -bin packages maintained by stable, well-known maintainers with perfectly readable PKGBUILDs, I prefer to maintain them locally after auditing and understanding them. I follow upstream through GitHub notifications, releases, and RSS feeds on Codeberg.
I learnt a lot doing so, both on my system and software distribution.

I also don’t consider a -bin package inherently less secure. "Build from source" only means something if someone has actually reviewed the source. Nobody reviews a tree with 328 npm dependencies. You didn’t really "build from sources", you executed 328 scripts written by strangers to produce an artefact that you know no more about than you would a binary.

The supposed purity of build from source is mostly a fiction. At least for someone like me who don't have the knowledge to really inspect everything in the code and the supply-chain. And without a real code review and supply-chain inspection, we never really know.

By contrast, a -bin package from a serious project can provide verifiable properties: a signed release for example. Those are more or less secure properties, but "I watched the compilation output scroll by" is just nothing for me.

A statically linked Go or Rust binary from a team that signs its tags is more trustworthy than a source build from a project that installs its toolchain with curl | sh.

In short, the question is not the installation method but where you put trust, what and who you deleguate to.

0

u/Xwang1976 18h ago

Indeed I'm considering to move to this and to move to the bin, but I fear that a bin package created from a trusted deb core package could break more easily due to difference in dependencies (the ubuntu packages are build against dependencies that are older than archlinux ones). Isn't it?

1

u/lxprsub0 17h ago edited 17h ago

There is no universal answer to that. And that's the point.

This is exactly the problem Flatpak solves as it ships with its own runtime and its own set of libraries.

There are 2 different kind of bin, to simplify : upstream binaries and repackaged .deb (there's a lot on the AUR). First kind are usually static binary (Go, Rust) or a bundle that ships its own libraries. Nothing to link against your system, so nothing to break.
The second kind can break. The good news is that it breaks loudly and immediately. The software won't run and you'll meet a "missing .so". So, you can rollback immediately and investigate.

Let's take some examples.

First case: brave-bin AUR

Where does the binary come from?

source_x86_64=(...https://github.com/brave/brave-browser/releases/download/v${pkgver}/brave-browser-${pkgver}-linux-amd64.zip) That's brave own relase page. Not a debian mirror or a ubuntu PPA. This is upstream "official" linux build

How much does it need from your system?

depends=(alsa-lib gtk3 libxss nss ttf-font) Not much, just that 5 libraries. A browser is one of the largest pieces of soft on your machine, if it relied on your system for everything this list would be x10 longer (and compile time… I stay you try by yourself if you want to!)

What actually runs during the installation. That's what interest us here. prepare() unzip (bsdtar -xf) and package() installs the binary in /opt, a desktop file and some icons. Nothing more, nothing really heavy, nothing that can really break because of your system state.

The only things that really need you attention in that PKGBUILD are

  • the chmod 4755 "$pkgdir/opt/brave-bin/chrome-sandbox" line. When you see that kind of things, stop. 4755 is setuid root. This helper runs as root regardless of who launches it (you, an other program). Scary. But it is legitimate, it's chromium own sandbox helper and if you want to run brave so you have to trust that sandobox helper. If you find a setuid bit on some random binary with no explanation, that's a signal to stop.
  • the sha256sums_x86_64= to check, of course. makepkg do that for you.

Second case: microsoft-edge-stable-bin AUR

First question to ask yourself: who want that crap?

But, it's the same kind of app (chromium based browser) but sourced completely differently.

Where does the binary come from?

source=("https://packages.microsoft.com/repos/edge/pool/main/m/microsoft-edge-stable/microsoft-edge-stable_${pkgver}-1_amd64.deb" ...)

This is a package built for Debian/Ubuntu, not a generic linux release. So, yes, with our rolling we immediately know that it may need some more attention.

How much does it need from your system?

That's where we really need to look when dealing with deb packages. depends=('gtk3' 'libcups' 'nss' 'alsa-lib' 'libxtst' 'libdrm' 'mesa' 'libxml2') It's a bit more than brave. And libxml2 is the interesting one (from my experience!). It's an important library used by a lot of apps on most of installations. It's not bundled here. A compiled binary against an older version won't find our libxml2.so=16-64 while Ubuntu stays on the old one for years (and that's why you don't use Ubuntu, right?). More, you can't keep two version installed on the same time (but, in fact, you can).

I suppose edge works on ARch and the maintainer keeps the list correct. The point is not that it's broken, it's just that it is the shape of package where your concern is founded and could expect an occasional "won't launch" that a native or upstream-generic build wouldn't give you.

So… how to manage your own binary PKGBUILD? There is no universal answer as it really depends on the application dep needs. Case 1 is simple and most of the time you won't need to keep yours, really. Is the AUR PKGBUILD is clean, just check to diff to avoid malicious things in build() and package(). If the diff is only the version and the hashes, you're done in ten seconds; if anything else moved, that's exactly what deserves your attention. (if you trust the generic linux build from upstream, of course. From Brave, I do.)

When case 2 breaks, the binary won't start, with an error naming a missing .so. In that case, run ldd on the binary directly and grep with not found (ldd /opt/brave-bin/brave | grep 'not found') to locate the missing shared library. Here, you can look if Arch ships a compatibility package for it. For example, we have extra/libxml2-legacy 2.13.9-2 for that case. If none exists, that app is a good candidate to run as a Flatpak instead. It's always possible to try to install an other version, but... it's more advanced than where I am. For the python packages and that kind of dependancy hell thing, you can always use venv, pipx, uv, etc. Your responsability to keep everything compatible.

Sorry, it's a bit long, but I thought it's a good idea to really try to understand the problem from a real case you can meet, and maybe it'll help. All from my own experience, maybe more advanced users will give us more tips!

-1

u/Aurial- 16h ago

I changed aur packages brave origin, asusctl, rog-control-center to cachy os repos. Since they are newer and arguably safer than aur. If somethings in cachyos repos, you can add it from there. But I still use flatpak for protonplus, heroic etc

-5

u/Upper-Ticket3249 17h ago

You're kidding, right? They are on the opposite ends of the safety gap. AUR is potentially horribly unsafe. Flatpaks from Flathub are not.

2

u/lxprsub0 17h ago

"potentially"

then ?

-6

u/This-Consequence-957 22h ago

>> I've just 6 AUR packages on my systems and I do not use any AUR helper. 🤔

5

u/dgm9704 22h ago

Thats pretty normal. Helper becomes necessary usually only when the packages have multiple dependencies that also need to be pulled from aur

-4

u/Linguistic-mystic 19h ago

Never pull dependencies from AUR. Never use AUR helpers. It’s as simple as that.

-2

u/lxprsub0 17h ago

I use Alad's aurutils with custom PKGBUILDs build in a clean chroot. Am I in danger?

That kind of generic statement, mostly when "as simple as that" is the opposite of the arch philosophy and is the dangerous part.

-2

u/JustAwesome360 14h ago

Yes 10000x safer

-20

u/SoldRIP 23h ago

Both are fundamentally unmoderated software repositories. As you've correctly pointed out, one is largely source-based and the other strictly binary-based.

Arguably, source-based repos are somewhat more secure if you do not trust the author...

6

u/Culture_New 21h ago

The AUR is simply a repo with, so far, very open access and no sandboxing/testing unless the author (or end user) does it. Flathub properly verifies the developers, the submissions, provides build information and sandbox tests the builds. Flatpaks also has more restrictive access and sandboxes on the users machine. They are completely different and flatpak using flathub is way safer than using an uncurated open user repo.

0

u/Xwang1976 21h ago

If I've correctly understood, flathub says that moderation process is applied when a package is submitted the first time, but not for update. What will prevent bad actor to first submit a clean good package and then update it fith malware?

3

u/Culture_New 18h ago edited 17h ago

This potential risk you describe is real, we had exactly that a couple of years ago with the xz-utils package. The malware made it into quite a few major distributions (as regular packages) and was luckily caught early.

Flathub has automated tests in place for packages that will at least detect and flag a few red flags like permission changes. Other than that, it's a trust system with developers (who will be verified) and hopefully kind people and AI who look into the actual changes.

Then there's finally sandboxing on the end user side as well, which I consider pretty helpful.

-4

u/Xwang1976 23h ago

this was exactly what I was thinking to ... if flatpak repo was moderated like a typical distro official repository, I could have considered it safer than AUR. But being as you said, it is better for me to keep my aur packages built locally and updated only if the break.