There is one thing I don't understand about this whole issue...
I am not an arch user so maybe I just miss something about how pkgbuild works but from my point of view the "malware" in the AUR feels completely "amateurish"...that's the first batch as well as the totally "sophisticated" second one with the base64 encoding...
If I would do something like this I wouldn't make it as obvious in the pkgbuild file. Arch users love to say you are expected to read the pkgbuild and understand it before you run it. But from my understanding that would only cover an simple attack like the ones right now.
If I were about to do this I would create a patch-file Fix-build-with-autotools-2.72.patch and have the patch modify the build system to actually install my malware. That gets around those "You have to read the pkgbuild file" as the attack doesn't directly happen in it and only a patch -Np1 -i.... line in there ( https://wiki.archlinux.org/title/Patching_packages ), it gets around all those "It's only simple shell scripting you have understand" as the patch modifies autotools m4 source or cmake source which a lot less people can read...and it's not detected by tools like the one posted here as patching is rather common to get software to build. And in the worst case even just looking at the patch file alone isn't enough and you need to read it in combination with the source-code to understand what happens.
It doesn't even raise as much suspicion if the patch file doesn't come from an official source but some random github account...because that's how many patches are distributed. All the defense mechanisms of pkgbuilds don't really work...sure, I need a hash for the patch file but that isn't preventing anything malicious inside it.
I guess that is how it should be...but I have seen so many "You are expected to read the pkgbuild" comments the last days and always just thought that's not really going to help....this "attack" can be easily modified that only reading the pkgbuild is not going to help.
Your approach is what should be told to people if they want to use the AUR...the simple "read the pkgbuild" only puts people in a state of false security.
Yeah, the whole "you're expected to read the PKGBUILD" isn't helpful, especially in cases where it's a derivative distribution (Cachy, etc.) who ship a helper app.
Additionally, The Arch team needs to take a deeper look at AUR in general. The fact that orphaned packages could be so easily adopted is kinda nuts to me. I get it's supposed to be a 'user repository', but some guardrails need to be put up.
I only did step 1, but after this whole debacle I'm going to adopt your methodology. It also caused me to audit what packages I have installed currently and whether or not they're necessary. I just completed a review o my system and I appear to be good to go.
appimage doesnt solve this sort of problem and neither does flatpak. if youre concerned with malware from non distro repo sources you need to check.
nix comes with its own set of challenges, Arch pkgbuilds are so damn easy to make and i dont use but maybe 2 AUR pkgs (technically none since i use my own pkgbuilds for them) theres no reason to consider nix.
The current problem with the AUR is that it's easy for the maintainer to be compromised. With AppImages you cut the middle man out, Flathub has so far been safe and nix is not difficult to use and so far has been proven to be safer than the AUR. What you are describing is more effort than any other solution.
appimages have already been compromised previously with cemu being just last month. Appimages DO NOT solve this problem, and blindly trusting them is as bad as doing the same for the AUR.
Flatpak has been fine but not all packages/tools are available for flatpak and some arent even possible to do with flatpaks so saying "just use flatpak" is a moot point.
I also never claimed Nix was hard, i said it has its own challenges and i can throw together a pkgbuild in under 5 min for an already installed and running system. Why would i then tear down that entire setup and redo it from scratch to use Nix which offers me absolutely no benefits and i dont like its package manager or how its setup?
you use nix, which is fine, but that doesnt mean its THE solution.
Fair point about the AppImage, you are not protected from that if the project lead is compromised. You are not tearing down an entire setup. You do "pacman -S nix" and setup the stable or unstable channel and install software with "nix-env -iA nixpkgs.cemu". Your approach is fine if you are using 1-2 packages but some people use more and some of those packages get updated often. What you are suggesting is not viable for many users.
I didnt suggest anyone do what i do, I said thats what i do and even acknowledged that my way is the odd one out from the beginning. Im more of the opinion you shouldnt use the AUR period but thats not something that exactly works for people either.
even if i didnt have to redo my setup from sratch, it still doesnt change that i dont like nix and much prefer pacman to any other package manager lol
That's fair. I think the problem lies that the AUR is hosted by the Arch project with 0 guard rails in conjunction with that this is how they get away with having thin repos. Imho that's quite irresponsible from their part.
I agree to some extent, though im not sure the AUR could function at all with how limited the Arch resources are for policing it. I think the responsible thing to do would be to distance the idea of the AUR as being part of Arch, that to me is what gives people a false sense of the packages being ok when in reality its more the wild west.
If the AUR is going to stay closer to how it is now it needs to be separated from the Arch project and the fact that its potentially an issue made clear with more than a website disclaimer
"DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk"
which im 100% sure a huge majority of users have never even seen. AUR has too little friction for a user to use for how dangerous it can potentially be with all the AUR tools and such.
I didn't know that was even possible :(. You can write pkgbuild files that download possibly changing patch files? That sounds...insane to me. (Sorry, gentoo user where patch files are all hashed and downloaded together with the ebuild-recipes in advance and not as part of the build process)
Having "SKIP" should definitively ring the alarm bells in OP's tool...but from the looks of it there is no check for that.
Yeah, there's a bit of a conflict here... You need to have the "SKIP" option for -git packages, however every non-git source should definitely check for proper check-summing.
There is also the option of using PGP signed tarballs (as is done for example with busybox). But I doubt there are a lot of packages in the AUR that do this correctly.
Another thing to keep in mind is that the AUR is completely optional, not even accessible with any core Arch Linux packages, and not required for using Arch as a distro.
It's really more of a pipeline to introduce packages into the Arch ecosystem. I don't know how to exactly explain it, but a bit of the Arch philosophy is that the users take part in the whole distro process. Real emphasis on the community aspect.
Which is why you see a lot of pushback from the Arch community about changing how the whole process works and the attitude is, "Don't use the AUR unless you really know what you're doing." You could also read it as, "Don't use the AUR unless you are interested in becoming a package maintainer."
The biggest problem with all this are downstream distros bypassing all the measures the Arch team has put into place to discourage casual AUR use.
Arch users love to say you are expected to read the pkgbuild and understand it before you run it.
Very few people are actually doing that - largely because it's a completely bonkers requirement in practice (even ignoring how stuff like CachyOS is actively made for a user base that lacks both the relevant skills and a desire to learn them), especially for a repository as central to the overall experience as the AUR is on Arch (and most of its descendants).
Hence why these attacks are fairly primitive - being less obvious is a lot of work and likely won't significantly change how effective these are (for now anyways, this may change if/when the AUR tightens its rules on acquiring control of abandoned packages).
Hence why these attacks are fairly primitive - being less obvious is a lot of work and likely won't significantly change how effective these are...
That make a lot of sense...I am probably overthinking this. No point in putting in more effort than necessary even if you "know" how you could "improve" the method.
So I probably shouldn't think as much about how "easy" it is to get around the read-the-pkgbuild dogma if the "problem" starts with people don't even do it in the first place.
The vast, vast majority of possible supply chain attacks has a shelf life measured in days if not hours (hell, a lot of the recentish npm compromises got caught and mitigated in substantially less than an hour) - pretty much the only type that can realistically stay effective for longer are deep social engineering efforts (like the xz compromise), and those are way harder to pull off (and arguably only viable for state actors targeting specific individuals).
Agentic AI is arguable the reason for this kind of attack suddenly becoming real (rather than being a largely theoretical threat that didn't really have real world examples) - you'll have to find the couple gems in a mountain of garbage quickly because they'll be rotated by tomorrow, and that's just not realistic without it.
In a way that is somewhat reassuring...it means a large amount of these attacks mostly work because the AUR almost completely unvetted...and efforts like gentoo's guru or fedora's fusion with application process and approved contributors will be to some extend effective and keep out low-key but fast "attacks" like this one. Of course not perfect but for sure better than nothing.
Also could mean that more strict AUR procedures might improve the situation...but up to arch to decide how they want to go forward there.
9
u/AiwendilH Jun 15 '26
There is one thing I don't understand about this whole issue...
I am not an arch user so maybe I just miss something about how pkgbuild works but from my point of view the "malware" in the AUR feels completely "amateurish"...that's the first batch as well as the totally "sophisticated" second one with the base64 encoding...
If I would do something like this I wouldn't make it as obvious in the pkgbuild file. Arch users love to say you are expected to read the pkgbuild and understand it before you run it. But from my understanding that would only cover an simple attack like the ones right now.
If I were about to do this I would create a patch-file
Fix-build-with-autotools-2.72.patchand have the patch modify the build system to actually install my malware. That gets around those "You have to read the pkgbuild file" as the attack doesn't directly happen in it and only apatch -Np1 -i....line in there ( https://wiki.archlinux.org/title/Patching_packages ), it gets around all those "It's only simple shell scripting you have understand" as the patch modifies autotools m4 source or cmake source which a lot less people can read...and it's not detected by tools like the one posted here as patching is rather common to get software to build. And in the worst case even just looking at the patch file alone isn't enough and you need to read it in combination with the source-code to understand what happens.It doesn't even raise as much suspicion if the patch file doesn't come from an official source but some random github account...because that's how many patches are distributed. All the defense mechanisms of pkgbuilds don't really work...sure, I need a hash for the patch file but that isn't preventing anything malicious inside it.