> You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates.

But isn’t that also the case for every browser extension, VSCode extension, nuget package, Cargo crate, python package, npm package, etc? (Unless you are running them somewhere without internet access or without access to anything you don’t mind being public?)

Maybe it’s not the case for aur, but the others could theoretically be improved with better permissions, sandboxing, etc. I guess browser extensions basically have those options, even if no “normal” users use them.

Unfortunately 99.99% of people can’t or don’t have the time to review everything. :-(

I guess distro packages where there are trusted maintainers, or places like the iOS App Store where there are both permissions and somewhat of a review process, are the safest.

> I'm not sure what the alternative would be, reviewing every adoption request seems like too much effort and wouldn't necessarily even help every time.

Even the most primitive LLM review workflow would have caught this compromise.

Adding or modifying any invocation to a PKGBUILD that may download something from the network and execute it (whether using npm, pip, curll|bash, or whatever else) -> automatically quarantine the PR and flag for 2 human reviews required. Same for anything that looks like obfuscation. Same for anything that adds dependencies on the wrong language ecosystem (like new use of javascript ecosystem tools in a c++ based package).

I have no idea why they don't do this already.

>You have to review the source of every PKGBUILD from the AUR you install, full stop

Believing that even a small fraction of users actually do this is deeply detached from reality.

> You have to review the source of every PKGBUILD from the AUR you install, full stop

I don't really think this is a solution- the usual workflow for these attacks has been to hide your payload in some dependency. This one is somewhat unusual in that it's just a very lazy `npm install` in the pkgbuild. Pretty much every package repository even outside of AUR has this issue now, and it's not really viable to audit the entire dep chain by hand. Mind you, I don't have a solution either.

Why does nobody act like it is then? I don't use Arch but every Arch user talks about the Aur so matter-of-factly yet nobody treats it with the caution that it demands.

I think a notice on the front page of the AUR would make sense here. IMHO, a blurb on the Arch homepage with a link to a notice on the AUR page would also help.

If you don't want to list all known effected packages, at least recommend the official position that anyone using a AUR package should be reading every file of every package they use.

No it shouldn't. You don't break everyone's workflow just because some people refuse to take basic security advise seriously.

> New API should have infrastructure for informing users and making sure they've read the message before proceeding.

How would that even work? AUR packages are just git repos, everything that AUR helpers are doing or not doing is not under the control of the arch maintainers.

It is a bit disappointing to not see any mention anywhere official.

I know its all volunteer work and extremely not fun at the moment, but it feels weird to not even have some sticky-no-reply on the AUR sub forum with a list of compromised packages. You have to instead try and scrape them up from around threads like here or reddit.

Are you paying maintainers for that, or are you just blindly demanding things from a piece of software maintained by volunteers before saying iT'S sO uNprOfEsSiOnAL ?

There was never an era in which #2 was a reasonable policy.

This is essentially what the [extra] repository is. Not using the AUR and sticking to official Arch Linux packages exclusively is a very valid and reasonable choice (that I follow myself actually).

A large number of "an Arch Linux update broke my system" is very likely due to incorrect AUR use that AUR helpers don't handle for you. There's an elaborate writeup here from just 2 months ago: https://lists.archlinux.org/archives/list/arch-dev-public@li...

A quicker alternative:

  comm -1 -2 <(pacman -Qq | sort) <(curl -s https://gist.githubusercontent.com/quantenProjects/3f768dce7331618310f016d975bf8547/raw/beef579f8a8efeed6ccf60788e5b768775550095/packages | sort)

It isn't guaranteed that the list is conclusive.

Always check PKGBUILD and sources, AUR is not to be trusted for the most part. I'm actually more surprised that such compromise hasn't happened earlier.

Note that pacman supports date locales; searching for '9 Jun' only works in English locales (or locales using similar formatting, I suppose).

After correcting, for me, it flagged "jd-gui", but I had actually installed "jd-gui-bin" about two hours before the compromise. As far as I can tell, I was lucky that I felt lazy that night and went for the -bin package instead of waiting for the source to be compiled.

Noob question, but how do people know this is thrustworthy, since it's not from Arch / an official source?

There's a lot of voodoo in that script, i can't easily tell it's safe by reading the code.

I'd expect some reaction/solution from official Arch developers...

This may happen even with `pkgctl build` if a makedepends= (transitively) pulled in the shared library into the build environment, but depends= doesn't.

There's warnings in place if a .so dependency is detected, but it's up to the maintainer to notice and act on it.

For safety/security concerns, Arch Linux has been one of the driving forces in the reproducible builds project, and for large parts of the operating system it's possible to independently verify that those binaries have in fact been built from source code. It's auditing story for official packages is stronger than that of NixOS (and on par with Debian):

https://reproducible.archlinux.org/

All of this is entirely unrelated to the AUR incident however.

Tools exist (e.g. pkgctl) to allow you to test building and installing the package on a clean image to catch these kinds of things, maintainers should really be using these before publishing.

It's only relatively recently that this has shifted from the norm. Debian operated this way for a long time and it was only in 2019 that they forbade it entirely.

Yes, "untrusted" "app stores" should be sandboxed (including AUR, FlatPak, ...) Probably with a VM, at least as a default/option.

We are pretty far from "never perfect"

On the bright side you can get quite far without the AUR.

I have 1,135 packages installed. Only 3 top level packages are from the AUR and 2 of those 3 are from the same author, they just happened to split their packages into a client / server architecture.

Installed CachyOS to replace my Win 10 installation a month ago. Not looking back! But yeah this sucks, I've mostly used Ubuntu with apt in the past. Pacman and makepkg felt a bit weird to use in the beginning.

I also had an affected package installed, fortunately it was from the official repo before it was dropped and became an AUR package.

> Flatpak and Flathub terrify me

I thought Flathub has a review and approval process. Does it fall short in some fundamental way?

Any review process is more than the AUR and NPM are doing.

This doesn't really have anything to do with npm.

So true. The JavaScript ecosystem is trash.

> Guess I'll be switching to a new OS this weekend across multiple machines.

This is a bit of an odd response. Arch very explicitly separates the AUR from everything else and doesn't make it easy to work with, because its security model has always been fundamentally broken and requires you to do your own vetting. It exists to facilitate sharing of package recipes between untrusted users. You should treat it like a pastebin.

Nothing here is "fundamentally broken". Any usage of AUR was always one step above executing random shell scripts from the net, and any official Archlinux guides were explicit about it. That's why there are no AUR helper tools in official repos and their usage was always discouraged in forums/wiki.

PKGBUILDs are easily readable/reviewable and rarely go beyond a single page. Just take a moment and be responsible and review before running executable files you download from the net. Common sense stuff. That's always been the trade-off and it hasn't really changed much in last 20 years (even though every few years everyone seems to freak out over it).

Orphaned packages, so other people are able to file requests and take over them. That's how AUR works — it's community-driven [0].

[0]: https://wiki.archlinux.org/title/Arch_User_Repository

They were orphaned, so anyone could adopt them. There are 15k other orphans at the moment.

It's not the AUR. It's the rolling release cycle, and probably even more importantly, lack of support options.

Arch is not used in enterprise solutions because of the AUR? Can't you just not use it?