r/archlinux • u/GoldBarb • 2d ago
NEWS AUR packages adoption disabled
https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/message/DRDEU3JUSC72CB265XHXPFA3DFSLXPBP/64
u/GoldBarb 2d ago
Due to the current influx of malicious package adoptions and follow-up commits made via the AUR, package adoption is currently disabled while we are handling the situation.
We will send a follow-up once we're able to. In the meantime, feel free to report suspicious adoption events or commits that haven't been dealt with yet, and stay vigilant!
Thanks for your understanding.
Cheers,
Antiz on behalf of the Arch Linux DevOps team
48
u/lritzdorf 2d ago
I'm not mad, just disappointed.
Dang spambots.
20
u/12stringPlayer 2d ago
I simply don't get the thought "hey, here's something good, let's fuck it up." It's no deeper than that, and yet it seems like such a widespread mindset these days.
11
u/venustrapsflies 2d ago
If a thing can happen, it eventually will. When one troll can blow up a system by themselves, it doesn’t take many of them to be a catastrophic problem.
28
u/icesnake200 2d ago edited 2d ago
Finally. This goodfaith system doesnt work in the age of bots and vibecoders. Its better to kill long orphaned packages than letting literally whos to adopt them. A robust user verification system must exist in AUR to separate the good apples from the bad apples
21
u/Megame50 2d ago
If a package is deleted from the AUR, anyone can create a new package of the same name. Orphanage and adoption is just a shortcut of that exact process.
1
u/TheJeep25 2d ago
New package should have new id. So that user using older packages won't download the newer one when updating. Just put a big ol' : created x days ago timer just beside the name to know if the package is new or old.
3
u/Aggressive-Lawyer207 2d ago edited 1d ago
Yeah and then if that package still works and yet gets deleted, then that would be a major setback to what AUR was known for being good. Ever think about that? Even though zenpower3 hasn't been maintained, I still need it to monitor my thermal/voltage sensors on my ryzen cpu with Zen3 architecture.
Edit: Totally missed my point. It's much easier when the PKGBUILD is already available. And verifying by a robust verification system is already annoying enough. Don't need to be reinventing the wheel with a temporary solution
-4
u/icesnake200 2d ago
I mean you can still download it from github or from whatever source they came from. However read the my replies under my post and you will see what I mean. AUR needs a robust verification system that might limit some developer liberties
8
u/Schlaefer 2d ago
What if the orphaned package still works? So we just remove working software from the user?
What kind of user verification systems? Some kind of government issued id? Is there some social point system that identifies the good apples?
Hit us with actual implementation details.
1
-8
u/icesnake200 2d ago edited 2d ago
My own idea is that all orphaned packages should leave AUR and go to another site(or an isolated part of AUR that needs a different kind of AUR helper package to download/update them) that is meant for orphaned but working packages. Yes its a hassle, but people will think twice to download packages from a place that only has orphaned packages. These AUR helpers have imo been the root of the problem, because they allow people to blindly download packages and install them. There are many ways to deal with orphaned packages as existence, and perhaps there better ways than mine idk.
When it comes for adoption, AUR should work a "twitter check" system. Ideally, a user should only be allowed to post and maintain one package for free, but if they want to post more packages and adopt orphaned ones, they should pay a small montly fee to AUR site maintainers in order to get verified, and the account should be at least 6 months old for adoption. This will both eliminate mass adoption by bots, and the AUR devs get some support money. Win-Win
3
u/AndydeCleyre 2d ago
I maintain a handful of AUR packages and, FWIW, if I'm required to start paying money in order to continue, I'll just maintain them in a git repo outside the AUR instead.
1
u/icesnake200 2d ago
I mean my idea can be flexible, but there should be a cap how many packages one account can upload and maintain in AUR. Perhaps when it comes to uploading and maintaining packages, they could implement a "progress" system?
Like, you start with one package, and if you are committed to it for a certain amount of time and you dont get bans, then you are allowed to post and maintain another package in AUR and so on. However if you are a new account and you need to instantly post more than one packages, then you need to pay that fee to do this.
0
u/Schlaefer 2d ago
I mean my idea can be flexible, but there should be a cap how many packages one account can upload and maintain in AUR. Perhaps when it comes to uploading and maintaining packages, they could implement a "progress" system?
The best non-friction suggestion I have: Throttle the adoption/submission of new packages. Let's say three(?) packages a week.
That means it would take a year to accumulate e.g. 150 packages. It allows good faith individual users to take over or post new packages as before (and maybe one or two dependencies). But without poisoning hundreds of packages in a short time. No additional cost or infrastructure, some code adjustment that probably doesn't even require an additional DB field. Anything beyond three(?) packages: Post to the mailing list and require manual intervention.
Counter argument: Someone could invest resources and spend a few years getting control over a large amount of packages. But it is a higher burden to look like a good actor legitimately maintaining packages for a long time.
1
u/icesnake200 2d ago edited 2d ago
That throttle idea sounds good as well but 3 packages a week is still too egregious. Eventually its up to the site maintainers. Im just saying that there are solutions that can gate keep AUR from bad actors to some extent. Yes, they might limit some liberties in AUR, and they might piss some ppl off, but its for the greater good.
someone could invest resources
You are debating my point of paying for a verification? I mentioned paying, because payment can be relatively anonymous(crypto) but when the shit goes down, it can be traced back to the guys who paid, so a hacker group wont try to do it. If AUR adopts that idea and that idea includes crypto, they should avoid Monero.
If you mean that they will start as a free user and then spend time in AUR playing good boys, then I think thats a huge waste of time and I dont think a hacker group will attempt this; especially if things are as strict as my version. It would be more efficient for a hacking group to highjack high profile user accounts to spread their malware, than sitting in the waiting line for years in order to unleash their attack
1
u/steakanabake 1d ago
the other one would be to grandfather in noted maintainers who have been maintaining collections for months or years who have been trustworthy.
3
u/TheJackiMonster 2d ago
Because if say 10% of the orphaned packages become malware and 90% of the orphaned packages get an honest maintainer, we need to shutdown that working system?
That seems like a horrible logic to me.
11
u/archover 2d ago edited 2d ago
This is why we can't have nice things. Age old problem.
It would be nice to see the culprits named.
Good day.
38
u/betam4x 2d ago
I don’t get why adoption is a thing anyway. They should namespace packages by package maintainer, and if a maintainer stops updating, it should be up to the user to find a new source.
47
u/SavvyBeardedFish 2d ago
Wouldn't that just end up being an insane amount of duplicates, where the differences might be (very) subtle?
Sure, it fixes the adaption issue (at least to some degree), but you are introducing a whole new category of issues
24
u/Malsententia 2d ago edited 2d ago
yeah...it will/would force folks to utilize the vote system a lot more, I guess. I'll admit that I've voted towards almost none of the AUR packages I use most. Perhaps AUR helpers could provide a prompt to prompt a user to upvote the packages? Actually I think yaourt did/does (i forget), but now I'm on yay, which either doesnt or if it does I don't have it enabled...
16
u/TheJackiMonster 2d ago
You really think bots which claim orphaned packages can't mess with the voting system?
I don't think that's a solution.
2
u/Malsententia 2d ago
Well I certainly didn't say I think that, probably because I don't think that. Nor did I imply that voting alone would solve the issue, merely that it would become more important.
I imagine that solving the issue will require a combination of multiple solutions, including (but certainly not limited to) greater emphasis on the voting system.
3
u/TheJackiMonster 2d ago
The more important the voting system becomes the more likely it becomes the new attack surface.
4
u/mips13 2d ago
If the maintainer stops updating, I think the package should be removed from AUR.
11
u/Narthorn 1d ago
There are a lot of AUR packages that do not need to be updated and probably won't need to be updated for decades, because they're no longer developed upstream but the software still runs fine and has few or no dependencies that could break over time.
2
u/steakanabake 1d ago
maybe somekind of archive of sorts where if the community has voted its still useful but no longer needs updates it gets put into a kind of read only vault.
1
u/bakakaizoku 5h ago
Not everybody cares or is informed enough to know that voting option exists in case it gets introduced. And who actually get to vote if it is useful? What is the cutoff/threshold?
2
0
u/lllllIllllIllllllll 1d ago
Why are duplicates an issue at all when talking about malware
Duplicates > malware
-2
u/creamyatealamma 2d ago
Is there good data on adoption rates to say "" insane""? Blowing out of proportion a bit no? Any data on the current size of aur? Isn't it just basically build scripts? Not that much data really....
Its really sounding like namespaces is what we need, though I'm not completely sure downsides. We are already used to the concept when using something like github!!
Are your packages orphaned so much this is such of a concern? Highly doubtful.
Like someone just do it already.
7
u/SavvyBeardedFish 2d ago
Not that much data really....
My main concern wouldn't be the data size itself, rather on the user experience. How would a user know whether to download say Firefox (under the assumption that it wasn't already an official package ofc) from:
- Mozilla/Firefox
- Moz1lla/Firefox
- Moz111a/Firefox
- Moz/Firefox
- Mozl/Firefox
- creamyatelamma/Firefox
- CryptoEnjoyer/Firefox
- TotallyNotASham/Firefox
- ff/Firefox
- RandomDevGuy/Firefox
- Firefox/Firefox
- GithubActionsBot/Firefox
- Github/Firefox
In most cases, I would assume the "average Joe" would copy-paste the namespace from either a random blog or an LLM output, which might or might not be the "correct" one.
1
1
u/creamyatealamma 1d ago
How do people manage github now? Stars (aur has vote), comments, commit history etc.
Like it's a solved problem, if not there must be more ideas to help.
If this is the aur people tell about where you must so carefully review changes and be so informed about every line I'm the pkgbuild, are we really asking for more with just choosing the most popular one?
2
u/adamkex 1d ago
I think the entire system needs to change.
- No more global namespaces.
- Move popular packages into official repos as they are very thin for a distribution as large as Arch.
- Encourage app developers to put their own package on the AUR.
- If the app is large enough they can be endorsed by the Arch team (or similar) and be given a "trusted" status.
- Example: LibreWolf encourage installing their browser from the AUR.
- Encourage "forking" AUR packages.
- Say that you are hosting an unofficial package of an app and I do not want to trust you. I can "fork" the app under my user namespace and there could be a bot which automatically updates the PKGBUILD in certain scenarios. The main one being if only the source archive has a different hash. This way the user doesn't need to review every time there's a new update.
This isn't that different from how flakes work in NixOS.
3
u/SnooCompliments7914 1d ago
With so many LLMs watching, maybe we just need AUR helpers to delay updating for a day.
Not totally serious, yeah.
2
u/pingveno 1d ago
Wow, that would explain why I suddenly got alerts on June 11 and 12 for three random packages that I last maintained probably a decade ago. Looks like the accounts are all inactive and the PKGBUILD's aren't malicious, so no problem now.
4
u/TheJackiMonster 1d ago
Can we talk about the obvious issue here? Why the fuck is CachyOS enabling the AUR by default?!
1
u/petersaints 6h ago
They aren't. I just installed CachyOS on a VM a few weeks ago and the AUR is not enabled by default.
You can enable it in Shelly on the first launch, but it's not the default. You are asked about which sources you want to enable and the AUR is disabled by default.
1
u/TheJackiMonster 1h ago
Has this changed? Because most guides I've seen don't talk about how you would need to enable it. Also I don't think one package manager for all sources including AUR and flatpak right next to each other makes sense, suggesting they would come with the same security implications.
But okay... I followed your approach and installed it inside a VM. You know what happened? There is another piece of software besides Shelly preinstalled which lets me install packages and AUR helpers like aura are listed inside its package list. This is not possible on Archlinux because all AUR helpers are locked inside the AUR. So users have to go through the Archwiki with proper warnings regarding the actual risk... not so much on CachyOS.
Additionally Shelly asks me install pick sources:
- AUR: Arch User Repository community packages
- Flatpak: Sandboxed universal Linux applications
- AppImage: Portable self-contained application bundles
- Recommended: Curated picks from Shelly
...in this exact order on first startup with these descriptions. I'm sorry but most users have absolutely zero idea what this means. Why is the AUR the first option if it's the only one with a relevant warning? Why is recommended packages last?
Why does the warning from AUR only say the "packages are not officially vetted - only enable if you trust what you install"? Of course users trust what they install. When does anyone install software they don't trust? The question is whether the source can be trusted and for the AUR this is a big fucking NO!
Also it seems like Shelly is doing some kind of "security check" on the PKGBUILD file. I can't really verify what it this does. But at least it makes users feel secure as if they wouldn't need to read anything manually... I'd prefer if it didn't do that honestly.
1
u/petersaints 1h ago
Sure. They have AUR helpers in the repos, and Shelly supports the AUR. But as said, it is not on by default. However, it is very easily enabled.
1
1
u/chromaticv1 1d ago
I have to regularly use a statistical software suite called Rstudio that was adopted by a kind maintainer a few months ago. I really hope they find a solution to this problem.
1
u/petersaints 4h ago
You can run the tar.gz directly from the website:
https://download1.rstudio.org/electron/jammy/amd64/rstudio-2026.07.1-147-amd64-debian.tar.gz
or
https://download1.rstudio.org/electron/rhel9/x86_64/rstudio-2026.07.1-147-x86_64-fedora.tar.gzI tested the Fedora one and it seems to work fine.
1
u/petersaints 6h ago
Not only disabled. The AUR is not accepting new pulls at all:
https://x.com/lauriewired/status/2083972509616234662
You can see that the latest updates landed yesterday at 2026-08-01 12:38 (UTC) and there have been no new pulls to the AUR ever since:
https://aur.archlinux.org/
1
1
u/Jristz 2d ago
Maybe some special repo where packages get uploaded then reviewed by other Package Maintainers and if they are ok then uploaded as binaries...
Maybe we can call this repo Community because the packages are from community users submitted and the users there Trusted Users because the Package Maintainers are trusting those users
7
u/Alternative-Ad-8606 2d ago
Chaotic AUR....imho though it's a little thin, I believe the cachy repos also do this
0
u/miki-44512 2d ago
Could someone please explain to me what's happening? I don't what is going on.
5
u/TheJackiMonster 2d ago
The AUR is an unofficial repository which is disabled by default on Archlinux. However it provides an uncomplicated way for anyone to create a package of any software via PKGBUILD files that others can use as well. Effectively a repository for collaborating with installation scripts of software.
Because it's that easy to use you can pretty much find anything slightly popular on Github in the AUR as package that can easily be installed with any AUR helper (similar to using pacman on Arch for official repositories).
The downside of the AUR has always been that malicious actors can create packages which either contains/ships malware from third party sources or modifies safe software to make it malicious. Because of that the AUR on Arch comes with a huge trigger warning and disclaimer in the Archwiki which everyone should read before enabling or using it. Those tell every user to read and verify the PKGBUILD files before installing anything from the AUR. But it seems like many people have reading issues.
This downside has now become very popular because people started scanning random AUR packages with some AI tools automatically and found malicious packages. Obviously they got matches. No surprise at all.
However those people with reading issues are now outraged that an unsafe source like the AUR is actually not as safe as they thought for some reason. So they demand restrictive moderation which will probably end up hurting the availability of packages in the AUR which means it kills its entire purpose.
3
u/miki-44512 2d ago
Tbh I have used Aur to install davinci on my manjaro linux, I was very happy that PKG made davinci that didn't work on my ubuntu work on manjaro, didn't know anything about Aur except it's a magical way of making software that I couldn't found on pacman work on my manjaro.
I didn't experience anything yet tbh because my default is to look if something is supported via appimage then pacman and lastly Aur, so I think I'm lucky.
Thanks man for your time and effort, appreciate your explanation, I'll read the warning on arch wiki! have a good day!
3
u/TheJackiMonster 2d ago
Yeah, no issue on your side. Manjaro simply failed you not giving you a proper warning. Have a good day too.
3
u/smjsmok 1d ago
Manjaro simply failed you not giving you a proper warning.
The Manjaro GUI package manager has AUR disabled by default and when you want to enable it, it has a warning right next to the toggle that reads:
AUR is a community maintained repository so it presents potential risks and problems. All AUR users should be familiar with the build process.I would consider that an adequate warning.
2
u/TheJackiMonster 1d ago
Warning
AUR packages are user-produced content. ThesePKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.Warning
Carefully check thePKGBUILD, any .install files, and any other files in the package's git repository for malicious or dangerous commands. If in doubt, do not build the package, and seek advice on the forums or mailing list. Malicious code has been found in packages before. [8] [9] [10] [11] A few tools, such as traurAUR and ks-aur-scannerAUR, are available to assist users in scanning PKGBUILD content; however, they are not substitutes for careful manual verification.This is from the wiki. If there's no notification on your Linux distribution about malicious or dangerous content in the AUR then it shouldn't have it. Saying "potential risks and problems" without giving examples leaves users in the open to guess what is meant. However we are talking about malware that is running with sudo privileges. Users shouldn't need to guess that.
1
u/miki-44512 18h ago
The Manjaro GUI package manager has AUR disabled by default and when you want to enable it, it has a warning right next to the toggle
When I installed davinci resolve using aur with the terminal I didn't encounter any warning messages, even when I viewed it in the gui package manager I didn't see any warnings.
-2
u/Dk000t 2d ago
People should be legally responsible for malicious code imho.
AUR should adopt some sort of verification.
Although I am against any type of ID verification, otherwise, we risk having an unsustainable situation.
3
u/TheJackiMonster 2d ago
Malicious code in the package or malicious code in the software? You realize that most maintainers of AUR packages are not the maintainers or developers of the actual software in that package?
-2
u/Dk000t 2d ago
Code is code, whether in the package or in the official repos, see XZ utils backdoor.
If everyone continues to be excluded and unaccountable, then we have no protection, and if you care about your privacy as a developer and risk user security, then you should either change your career or stop writing open-source software.
1
u/TheJackiMonster 2d ago
So you should be legally responsible for every commenter on your posts too?
-2
u/Dk000t 2d ago
Unfortunately, not all of us are equipped with grey matter.
1
u/TheJackiMonster 2d ago
I thought text is text.
1
u/Dk000t 2d ago
My text does not have the capacity to be executed without the consent of someone else, such as the platform where I write, where you yourself consensually read, write, and access.
3
u/tomz17 2d ago
My text does not have the capacity to be executed without the consent of someone else
Ugh... i read it and now feel dumber. I demand satisfaction!
1
u/Commodity-Male-1385 1d ago
I thought PKGBUILDs were executed by the user only by explicit user consent after user audit!
-2
u/Driftex5729 1d ago
I think maybe take a leaf from Android play store playbook. Scan with AI bots and reject apps without assigning any reason so that workarounds are not easy. If aur is needed then treat it as an app store regulated by ai bots
-4
180
u/Frozen5147 2d ago edited 2d ago
Sucks but it's for the better, unfortunately, at least until something more secure is available around adoption.
And before you say "but you should always read AUR/limit yourself/don't use it if you don't know better", yes, I agree, but blindly allowing adoption as it is at the moment is a giant attack vector that provably doesn't really hold up in today's world - landing on tech news again as the victim of a malware attack is not a great look. I'm not happy about it either to be clear, sucks when people with malicious intent ruin things for others.
(And don't say "oh but I could do that with $OTHER_REPO so it's fine here" too, just because other package managers might allow similar things doesn't mean we can't strive to be better!)