People need to get into their heads that the AUR is just a collection of user-produced PKGBUILDs.
You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates. This really has always been the case; we've had discussion about this for well over a decade. People are always asking why there's no official AUR helper like yay - this is why.
A lot of people complain about Arch Linux being elitist, but the simple reality is it's a distro built for people who know what they are doing and don't need or want their hand held at every step of the way. This also means that if you break or compromise your own system by installing random AUR packages, it's your own damn fault.
All of that being said, the era of allowing anyone to adopt AUR packages might be coming to an end. If for no other reason then the effort of rolling back every affected package every time is too high. 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.
This is one of the aspects of AUR which never fully convinced me: it purely hosts user-generated content, there's no review process or alike.
I'd really prefer to see a model where a 'community' repository contains user submitted packages which have at least one Trusted User review the package before it's merged in. This doesn't just prevent malware, but also common mistakes in general.
7+ hours into this and still no mention on archlinux.org webpage nor on aur.archlinux.org. Why??? AUR should have been blocked until user takes action to prove he knows about this.
Eg. change AUR API URL slightly so yay/yaourt users need to look up what is going on. New API should have infrastructure for informing users and making sure they've read the message before proceeding. Especially when they're not even sure that all malware was found.
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.
As people have noted, this sort of thing has become inevitable and likely to increase in occurrence unless some changes are made. I'm a big fan of the AUR PKGBUILD system, and I leverage it quite frequently to write my own. The most egregious issue in my opinion, and one of the low hanging fruit to fix, is the fact that anyone can adopt an orphaned package with no notification to end users that this has happened.
It's honestly more trouble than it's worth to get your package deleted, instead leaving orphaning as the more optimal way to relinquish control. This should be the opposite in my opinion, or at the very least the users should be made very aware that an orphaning has occurred. Perhaps that burden is more on the AUR helper like paru and yay (who I would encourage to make such a change).
This campaign is still ongoing. I just got an email that one of my old packages (which hasn't worked for years and was orphaned for a while) was adopted and immediately a malicious commit was pushed. They seem to be using bun instead of npm now, so any npm-based workaround likely isn't effective.
Obviously installing anything from AUR must be done cautiously and there have always been sketchy (as in improperly built/packaged) packages in the past but seeing actively malicious injections is concerning. I think there are two main problems with AUR: 1. it is a remnant of a slightly more egalitarian era in the open source history when you could generally trust 3rd party code and 2. orphaned packages can be adopted by anyone with their full history and vetting intact.
I think we are well past (1) but (2) could be mitigated by tighter controls on AUR accounts and potentially additional safeguards from AUR helpers. Maybe show a big scary warning if the package has changed owners recently. I know there will still be people that will "y" their way forward but it's better than nothing.
Or just avoid AUR helpers altogether and inspect/build the packages you need yourself from their PKGBUILDs directly.
For every single update, for all your AUR packages, all the time.
You know that thing where if you make a security review feature obnoxious, after some time people will just accept everything without even looking? Yeah...
You are thinking of the alarm fatigue[1], but it doesn't apply here -- there are no constant alerts warning that you are doing something dangerous to the point you get desensitized and start to ignore them. The correct analogy here are checklists -- things that you need to check if you are to do this "dangerous" activity (AUR usage), akin to pre-flight checklist.
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.
Just not always on this scale and doesn't always end up on HN.
Similar to how you don't see every npm supply chain attack or malicious github action or similar on HN.
In general you _have to_ manually review every PKGBUILD update by hand (by diff). Everything else is neglect IMHO. Luckily for most packages this is reasonably doable, IFF you trust the upstream sources they fetch from. (As in: Most packages are a small amount of glue between pacman and a upstream source.)
As consequence AUR packages with AUR dependencies are in general "uh..., lets not do it" cases for me, as on one hand the review overhead can be a pain and on the other hand it's easy to make a mistake overlooking a change in AUR dependencies.
Still the policy which allows relatively easy adoption of orphaned packages is IMHO a problem. A adoption should be treated as a new package which just happen to have the same name. (It can be fine to not have that if arch maintainers "bless" the adoption, but IMHO that would only matter for a view very widely used packages which are candidates to be included in the official repo but aren't for e.g. license reasons.)
I have opencode review it for me. Works great. With the opencode-pty plugin it operates a terminal like a human would, runs yay, opens the pkgbuild in vim when yay asks it, reviews, etc etc. gives an `n` at the end cancelling the operation and gives me a report. I read that and then upgrade. For non-famous 3-4 aur packages I have, I have it read the code itself. It's enough to catch the non-jia-tan problems.
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.
I remember installing an emulator (Mednafen) on Arch Linux about a decade ago. The program failed to run because it was linked against a library my system didn't have. Turns out, the maintainer built the software on his own system and it used a library he had on his system but was not listed in the dependencies.
It is an officially maintained package and I always assumed these were built on a dedicated build server instead of some a random volunteer/home computer. Don't know if Arch still builds the same way but this event scared me enough to switch distros.
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):
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.
So what's a solution to this? Install packages like this in Docker containers without network access? I don't think we should assume it's limited to AUR. Every software source should be considered suspect in 2026, particularly with the adoption of vibe coding, and closed software is a bigger mess than open source because it's a black box.
Not the first time this has happened recently. There were a few emails in the AUR list a few weeks ago about malicious packages, and a few reports on IRC too. The only difference in the campaign back then was the malicious npm package name (`linux-utils` in the campaign a few weeks ago).
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.
This is similar to my situation with Gentoo. Across my Gentoo systems, I have exactly one package installed from an "overlay" [0], and that's Steam. Everything else is straight out of the official package tree.
[0] ...which is -IIRC- Gentoo's term for a user-provided and entirely-unvetted collection of packages...
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.
Be aware of false positives! I found I had two of these packages installed, clang19 and compiler-rt19, but due to my recent laziness in updating my system, mine were still the versions from July 2025 from the official repos before they had relegated them to AUR.
You can check the build and install date with `pacman -Qi <package>`.
I run Arch Linux in a container (within Fedora Silverblue), but my plan for the future:
- consider switching away from Arch Linux for my dev container, with great sadness. A rolling distro is a terrible idea in the current security climate. I loved using Arch for my dev container exactly because of AUR.
- switch to Fedora Stable, perhaps the previous release which still gets security fixes but no other updates. I am still on Fedora 43, I guess I have no rush to update to 44.
- be even lazier in updating my workstation. I used to update daily when I was running Arch, then I moved to weekly last year when I got stuck with slow internet, now consider updating monthly or more (of course, unless there are critical security bugs)
- Flatpak and Flathub terrify me, it's only a matter of time until malware appears. I have had automatic upgrades disabled for a while.
- for the love of God don't touch anything that uses npm
If your manifest is covertly injecting malware into the build it could be easily missed. Consider some of the manifests are simply downloading deb packages and unzipping them.
Wow, this is effectively the end of the AUR model. There's been a malicious package or two before, but an attack this widespread shows things are fundamentally broken. Guess I'll be switching to a new OS this weekend across multiple machines.
> 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.
Tbh Arch itself is the most explicit about this compared to the derivatives. Manjaro etc allow installing AUR stuff directly from their main package manager
> ...because its security model has always been fundamentally broken...
I disagree that "These packages are provided as-is. No work has been done to determine their safety or fitness for purpose. Use at your own risk!" is a "fundamentally broken" security model. It's one that places the burden of verification and validation on the system administrator and -in the case of the AUR- fully informs them of this fact. Treating system operators like the adults that they are isn't "fundamentally broken", but it is _much_ more work for that operator than if they relied exclusively on distro-vetted packages.
I do agree that it'd be fucking silly of OP to switch away from Arch because some of the packages in the collection of packages that are explicitly provided as "as-is and unvetted" got some malware in them.
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).
You’re not wrong, but then we ought to pump the brakes in telling everyone and their mother to hop onto arch based distros that make installing AUR packages seem as safe as any other action (via Shelly on cachyos for example)
Honestly, it's hard to see how Arch is a usable distro for most potential users without AUR. If you want a large selection of official packages, the Debian world is going to be the better choice.
Obviously usages vary greatly, but I doubt it's that of big deal for majority of Arch users (maybe it's different for Arch derived distros). My AUR maintained package count has been in single digits for decades (both on my home PC and work station), and I don't think it as a heavy burden to update those packages.
There's a certain selection bias going on here -- I drop AUR packages if they become too annoying (if they require updates too frequently or they want a slew of other AUR only packages as dependencies), I either find alternatives or alternative sources for them (e.g. flathub).
Arch still hits the sweet spot for me -- unobtrusive, close to upstream, and well-documented enough to keep full control over your own system. Both for the times when you want to go with the most default path and for the cases when you want to deviate and go play in the weeds.
I think the issue with AUR is that you get your foot in the door with packages like spotify[1]. It does its magic to allow you to install a .deb package on your distro. I don't know how else to install the Spotify desktop app without AUR. But once you're willing to do that, why not go a little further and trust other packages?
Now, someone could argue that the Spotify app isn't important, but there's a reason it has 268 votes. A better solution would be having packages like spotify in their own repo, and a separate, you-better-verify repo for the rest.
AUR doesn't guarantee security, its upto the user to use AUR & verify before installing anything, its very evident why arch is not used in enterprise solutions.
No, it's not. If Debian had a community-maintained repo of additional packages, the same thing could happen there.
The fundamental problem is having something that has very loose oversight and next to no controls. That may have worked in the past, but in the day and age of constant supply chain attacks, it's a major liability.
People need to get into their heads that the AUR is just a collection of user-produced PKGBUILDs.
You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates. This really has always been the case; we've had discussion about this for well over a decade. People are always asking why there's no official AUR helper like yay - this is why.
A lot of people complain about Arch Linux being elitist, but the simple reality is it's a distro built for people who know what they are doing and don't need or want their hand held at every step of the way. This also means that if you break or compromise your own system by installing random AUR packages, it's your own damn fault.
All of that being said, the era of allowing anyone to adopt AUR packages might be coming to an end. If for no other reason then the effort of rolling back every affected package every time is too high. 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.
This is one of the aspects of AUR which never fully convinced me: it purely hosts user-generated content, there's no review process or alike.
I'd really prefer to see a model where a 'community' repository contains user submitted packages which have at least one Trusted User review the package before it's merged in. This doesn't just prevent malware, but also common mistakes in general.
7+ hours into this and still no mention on archlinux.org webpage nor on aur.archlinux.org. Why??? AUR should have been blocked until user takes action to prove he knows about this.
Eg. change AUR API URL slightly so yay/yaourt users need to look up what is going on. New API should have infrastructure for informing users and making sure they've read the message before proceeding. Especially when they're not even sure that all malware was found.
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.
As people have noted, this sort of thing has become inevitable and likely to increase in occurrence unless some changes are made. I'm a big fan of the AUR PKGBUILD system, and I leverage it quite frequently to write my own. The most egregious issue in my opinion, and one of the low hanging fruit to fix, is the fact that anyone can adopt an orphaned package with no notification to end users that this has happened.
It's honestly more trouble than it's worth to get your package deleted, instead leaving orphaning as the more optimal way to relinquish control. This should be the opposite in my opinion, or at the very least the users should be made very aware that an orphaning has occurred. Perhaps that burden is more on the AUR helper like paru and yay (who I would encourage to make such a change).
This campaign is still ongoing. I just got an email that one of my old packages (which hasn't worked for years and was orphaned for a while) was adopted and immediately a malicious commit was pushed. They seem to be using bun instead of npm now, so any npm-based workaround likely isn't effective.
https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...
Obviously installing anything from AUR must be done cautiously and there have always been sketchy (as in improperly built/packaged) packages in the past but seeing actively malicious injections is concerning. I think there are two main problems with AUR: 1. it is a remnant of a slightly more egalitarian era in the open source history when you could generally trust 3rd party code and 2. orphaned packages can be adopted by anyone with their full history and vetting intact.
I think we are well past (1) but (2) could be mitigated by tighter controls on AUR accounts and potentially additional safeguards from AUR helpers. Maybe show a big scary warning if the package has changed owners recently. I know there will still be people that will "y" their way forward but it's better than nothing.
Or just avoid AUR helpers altogether and inspect/build the packages you need yourself from their PKGBUILDs directly.
There was never an era in which #2 was a reasonable policy.
The canonical answer to any concerns with the AUR is always “just read the PKGBUILDs bro”
For every single update, for all your AUR packages, all the time.
You know that thing where if you make a security review feature obnoxious, after some time people will just accept everything without even looking? Yeah...
You are thinking of the alarm fatigue[1], but it doesn't apply here -- there are no constant alerts warning that you are doing something dangerous to the point you get desensitized and start to ignore them. The correct analogy here are checklists -- things that you need to check if you are to do this "dangerous" activity (AUR usage), akin to pre-flight checklist.
[1] https://en.wikipedia.org/wiki/Alarm_fatigue
Here's an easy script to scan for compromised packages:
https://cscs.pastes.sh/aurvulntest20260611.sh
Not my script. It's easy to read/parse. Never pipe a script directly to bash.
A quicker alternative:
It's never a bad time to learn about comm(1).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.
> hasn't happened earlier.
it happens all the time
Just not always on this scale and doesn't always end up on HN.
Similar to how you don't see every npm supply chain attack or malicious github action or similar on HN.
In general you _have to_ manually review every PKGBUILD update by hand (by diff). Everything else is neglect IMHO. Luckily for most packages this is reasonably doable, IFF you trust the upstream sources they fetch from. (As in: Most packages are a small amount of glue between pacman and a upstream source.)
As consequence AUR packages with AUR dependencies are in general "uh..., lets not do it" cases for me, as on one hand the review overhead can be a pain and on the other hand it's easy to make a mistake overlooking a change in AUR dependencies.
Still the policy which allows relatively easy adoption of orphaned packages is IMHO a problem. A adoption should be treated as a new package which just happen to have the same name. (It can be fine to not have that if arch maintainers "bless" the adoption, but IMHO that would only matter for a view very widely used packages which are candidates to be included in the official repo but aren't for e.g. license reasons.)
I have opencode review it for me. Works great. With the opencode-pty plugin it operates a terminal like a human would, runs yay, opens the pkgbuild in vim when yay asks it, reviews, etc etc. gives an `n` at the end cancelling the operation and gives me a report. I read that and then upgrade. For non-famous 3-4 aur packages I have, I have it read the code itself. It's enough to catch the non-jia-tan problems.
> I'm actually more surprised that such compromise hasn't happened earlier.
This is like the 3rd or 4th time. It's been ongoing and persistent for the last 2 years with frequent AUR downtime as a result.
The AUR should be deprecated in its current state, simply can't be trusted and is a blemish on an otherwise great distro.
The Arch Wiki does note that malware has made it into the AUR several times before.
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.
Same situation for me. "alvr-bin" instead of "alvr". I'm a week out of date too.
The (Arch) community is moving quickly to release scripts/tools.
Right now, this is the most up to date, consolidated utility to check for infection:
https://github.com/lenucksi/aur-malware-check
I remember installing an emulator (Mednafen) on Arch Linux about a decade ago. The program failed to run because it was linked against a library my system didn't have. Turns out, the maintainer built the software on his own system and it used a library he had on his system but was not listed in the dependencies.
It is an officially maintained package and I always assumed these were built on a dedicated build server instead of some a random volunteer/home computer. Don't know if Arch still builds the same way but this event scared me enough to switch distros.
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.
There are some AUR hooks that can help. I use https://github.com/Sohimaster/traur which also has scans for orphan package takeover patterns.
So what's a solution to this? Install packages like this in Docker containers without network access? I don't think we should assume it's limited to AUR. Every software source should be considered suspect in 2026, particularly with the adoption of vibe coding, and closed software is a bigger mess than open source because it's a black box.
Yes, "untrusted" "app stores" should be sandboxed (including AUR, FlatPak, ...) Probably with a VM, at least as a default/option.
More news is coming out about this:
https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised
I toyed with the idea that someone should write a binary that simply emails, or alert you when it's been run... as a canary... and call that `npm`.
At this point, not renaming the npm binary is a big risk.
I haven't used Arch for a few years now, but when I did the AUR was my favourite aspect.
It was never perfect from a security PoV, but in 2026 this kind of trust model feels increasingly scary.
We are pretty far from "never perfect"
Here's a commit showing how they did it: https://aur.archlinux.org/cgit/aur.git/commit/?h=pass-cli&id...
Internet archive URL: https://web.archive.org/web/20260611213640/https://aur.archl...
Not the first time this has happened recently. There were a few emails in the AUR list a few weeks ago about malicious packages, and a few reports on IRC too. The only difference in the campaign back then was the malicious npm package name (`linux-utils` in the campaign a few weeks ago).
third time this has happened:
https://news.ycombinator.com/item?id=17501379 https://news.ycombinator.com/item?id=44607740
This is especially gnarly as more people have been picking up arch distros as of late (like CachyOS).
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.
This is similar to my situation with Gentoo. Across my Gentoo systems, I have exactly one package installed from an "overlay" [0], and that's Steam. Everything else is straight out of the official package tree.
[0] ...which is -IIRC- Gentoo's term for a user-provided and entirely-unvetted collection of packages...
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.
Best to stick to official repositories only.
Be aware of false positives! I found I had two of these packages installed, clang19 and compiler-rt19, but due to my recent laziness in updating my system, mine were still the versions from July 2025 from the official repos before they had relegated them to AUR.
You can check the build and install date with `pacman -Qi <package>`.
I run Arch Linux in a container (within Fedora Silverblue), but my plan for the future:
- consider switching away from Arch Linux for my dev container, with great sadness. A rolling distro is a terrible idea in the current security climate. I loved using Arch for my dev container exactly because of AUR.
- switch to Fedora Stable, perhaps the previous release which still gets security fixes but no other updates. I am still on Fedora 43, I guess I have no rush to update to 44. - be even lazier in updating my workstation. I used to update daily when I was running Arch, then I moved to weekly last year when I got stuck with slow internet, now consider updating monthly or more (of course, unless there are critical security bugs)
- Flatpak and Flathub terrify me, it's only a matter of time until malware appears. I have had automatic upgrades disabled for a while.
- for the love of God don't touch anything that uses npm
Previously: https://news.ycombinator.com/item?id=48458931
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.
Flathub only reviews the manifest.
If your manifest is covertly injecting malware into the build it could be easily missed. Consider some of the manifests are simply downloading deb packages and unzipping them.
Thanks AI!
Is there a way to verify if the malware is actually installed on a machine?
Wow, this is effectively the end of the AUR model. There's been a malicious package or two before, but an attack this widespread shows things are fundamentally broken. Guess I'll be switching to a new OS this weekend across multiple machines.
> 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.
Tbh Arch itself is the most explicit about this compared to the derivatives. Manjaro etc allow installing AUR stuff directly from their main package manager
> ...because its security model has always been fundamentally broken...
I disagree that "These packages are provided as-is. No work has been done to determine their safety or fitness for purpose. Use at your own risk!" is a "fundamentally broken" security model. It's one that places the burden of verification and validation on the system administrator and -in the case of the AUR- fully informs them of this fact. Treating system operators like the adults that they are isn't "fundamentally broken", but it is _much_ more work for that operator than if they relied exclusively on distro-vetted packages.
I do agree that it'd be fucking silly of OP to switch away from Arch because some of the packages in the collection of packages that are explicitly provided as "as-is and unvetted" got some malware in them.
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).
You’re not wrong, but then we ought to pump the brakes in telling everyone and their mother to hop onto arch based distros that make installing AUR packages seem as safe as any other action (via Shelly on cachyos for example)
Honestly, it's hard to see how Arch is a usable distro for most potential users without AUR. If you want a large selection of official packages, the Debian world is going to be the better choice.
Obviously usages vary greatly, but I doubt it's that of big deal for majority of Arch users (maybe it's different for Arch derived distros). My AUR maintained package count has been in single digits for decades (both on my home PC and work station), and I don't think it as a heavy burden to update those packages. There's a certain selection bias going on here -- I drop AUR packages if they become too annoying (if they require updates too frequently or they want a slew of other AUR only packages as dependencies), I either find alternatives or alternative sources for them (e.g. flathub).
Arch still hits the sweet spot for me -- unobtrusive, close to upstream, and well-documented enough to keep full control over your own system. Both for the times when you want to go with the most default path and for the cases when you want to deviate and go play in the weeds.
I think the issue with AUR is that you get your foot in the door with packages like spotify[1]. It does its magic to allow you to install a .deb package on your distro. I don't know how else to install the Spotify desktop app without AUR. But once you're willing to do that, why not go a little further and trust other packages?
Now, someone could argue that the Spotify app isn't important, but there's a reason it has 268 votes. A better solution would be having packages like spotify in their own repo, and a separate, you-better-verify repo for the rest.
[1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=spoti...
Thanks for the link. It contains link to list of the affected packages, that will be useful.
Man, I never hear good security things about npm
This doesn't really have anything to do with npm.
anything except that it's malware installed via npm
From the Arch mailing list [0]
>The result is a rather long list of ~408 packages all doing npm install atomic-lockfile something something
[0] https://lists.archlinux.org/archives/list/aur-general@lists....
They could've pip installed, curl|sh'd or anything else, it's not relevant to the underlying issue.
Perhaps there were other vectors, but npm was the one used here.
And yes, this is an AUR issue, but npm being used to host and dissiminate malware is also [a chronic] one, even if separate.
So true. The JavaScript ecosystem is trash.
How a person 'adopts' 408 packages and controls their build scripts?
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.
AUR doesn't guarantee security, its upto the user to use AUR & verify before installing anything, its very evident why arch is not used in enterprise solutions.
It's not the AUR. It's the rolling release cycle, and probably even more importantly, lack of support options.
The AUR has absolutely nothing to do with the rolling release cycle
yes & comment didn't mention that both are dependent, fooqux is correct.
He literally said "It's the rolling release cycle" he is not correct
You're reading it wrong. He's giving an alternative reason why it's not used in enterprise.
Agree
Arch is not used in enterprise solutions because of the AUR? Can't you just not use it?
AUR is choice, rolling release is the reason
No, it's not. If Debian had a community-maintained repo of additional packages, the same thing could happen there.
The fundamental problem is having something that has very loose oversight and next to no controls. That may have worked in the past, but in the day and age of constant supply chain attacks, it's a major liability.
Rolling release has nothing to do with this. It could just as well be a PPA in ubuntu or any deb repo for debian or similar.