Solution to the AUR crisis

MTu08 · 2026-06-13 20:29:42

I'm sure everyone is aware by the mass infection of orphaned packages (around 1700) that have been targeting developers, which is because orphaned packages can be "adopted" and be re-maintained by another maintainer to keep it active. Only issue is that this does way more harm than good, so why let this even be an option to begin with? Why let anyone adopt a package thousands have installed on their computers to be at the mercy of the new maintainer? If they want to continue a package let them just fork it or something don't hand them control over the package that many users have.
This is what i think at least, so correct me if I'm wrong.

cryptearth · 2026-06-13 20:33:50

please don't double post - use the report function to request a mod to move a topic
https://bbs.archlinux.org/viewtopic.php?id=313923

MTu08 · 2026-06-13 20:37:20

i already reported it thank you

loqs · 2026-06-13 22:50:28

As the current AUR frontend does not support forking how substantial a rewrite would your proposal require? This would also require a major policy change a forks are prohibited on AUR at present by the no duplicates rule. Would it also require a rewrite of he API and of of all AUR helpers. How would you avoid AUR helpers automatically locating the fork and switching to it similar to the current situation where AUR helpers follow official packages that are dropped to AUR? Have you considered also posting on the aur-general mailing list where AUR maintainers are much more likely to read it? Are you able to help with the implementation and maintenance of your proposal?

5hridhyan · Yesterday 04:12:17

Adding on top of loqs point, question: if a maintainer disowns a package and someone else is interested in maintaining it, but cannot adopt it and instead has to create a fork (according to your proposal), what happens to the original package? It would become redundant, wouldn't it? which would seem meaningful for the staff to delete those redundant(s), which obviously creates "yet another work" for them. [context: they are volunteers]

seth · Yesterday 07:25:07

5hridhyan wrote:

seem meaningful for the staff to delete those redundant(s)

loqs wrote:

forks are prohibited on AUR at present by the no duplicates rule

The orphan package would have to be removed first.

loqs wrote:

How would you avoid AUR helpers automatically locating the fork and switching to it

The for would also have to "provides" and "conflicts" *all* previous forks/versions to maintain dependency chains.

The result of this will also be that users have stale packages around, at some point or not realize that "hey, that's broken" and then have to search for and inspect the alternatives/forks like every PKGBUILD change before and after.

MTu08 wrote:

this does way more harm than good

=> If we for the sake of the argument accept that postulate as factual: What does your proposal improve about the status quo?

MTu08 · Yesterday 11:14:33

loqs wrote:

As the current AUR frontend does not support forking how substantial a rewrite would your proposal require? This would also require a major policy change a forks are prohibited on AUR at present by the no duplicates rule. Would it also require a rewrite of he API and of of all AUR helpers.

i suppose forking with a different name or atleast your own spin would be better, i'm not saying that the whole api would be rewritten all i'm saying is that if someone wants to maintain an orphaned package they shouldn't take control of the package that many have installed , and instead fork it.

How would you avoid AUR helpers automatically locating the fork and switching to it similar to the current situation where AUR helpers follow official packages that are dropped to AUR? Have you considered also posting on the aur-general mailing list where AUR maintainers are much more likely to read it? Are you able to help with the implementation and maintenance of your proposal?

i'm sorry i don't understand what you are referring to, i don't have that much knowledge over the inners of the AUR.

5hridhyan wrote:

Adding on top of loqs point, question: if a maintainer disowns a package and someone else is interested in maintaining it, but cannot adopt it and instead has to create a fork (according to your proposal), what happens to the original package? It would become redundant, wouldn't it? which would seem meaningful for the staff to delete those redundant(s), which obviously creates "yet another work" for them. [context: they are volunteers]

good point, if a package is orphaned and there is a trusted alternative, i guess it would work if there was some way to inform the maintainer of the alternative (either by reporting or some other way) and if they want they can either keep the orphaned package to download or close it with a link redirecting to the trusted alternative. i'm not sure what would happen if the original maintainer isn't online or didn't respond for a long time though, maybe either let the users decide or let a moderator decide if it should stay, be closed, or removed. but i'm no expert in this at al so take it with a grain of salt.

seth wrote:

=> If we for the sake of the argument accept that postulate as factual: What does your proposal improve about the status quo?

what do you mean by the status quo?

ultimately, i think what happens to the orphaned package should be up to the original maintainer (if they are available at least), no one should be able to re-maintain the package but the original maintainer or co-maintainers that the maintainer adds and trusts, and if not, then they can make a fork in a form of a revival that users can use instead. if that fork is noticed by the maintainer they can close their package and link the fork for everyone to use, or they can remove their package completely.

this is what i think atleast

seth · Yesterday 12:02:05

i'm sorry i don't understand what you are referring to

loqs is pointing out that the various AUR helpers (the main cause of problem here) are too smart™ for this adjustment and will just find the replacement package and substitute it (notably if it's installed as/provides a dependency)

The status quo is the situation as is.

i guess it would work if there was some way to inform the maintainer of the alternative (either by reporting or some other way)

What maybe implies what you envision the status quo is.
Package maintainers get notified of out of date flags and orphan request and have the ability to object to those.
You cannot just "1-click buy" a package by orphaning and taking control over it.

5hridhyan · Yesterday 12:04:22

Fork with a different name

That's just... creating a new package. Which already exists. And doesn't solve the orphan problem

Let the original maintainer decide what happens to the orphan

The original maintainer disowned it. They don't care anymore. That's why it's an orphan. In other cases maintainer went offline, flagged out of date, and then someone submit orphan request.

Moderators can decide

Moderators are volunteers. I don't think they have time to adjudicate every orphan dispute

Last edited by 5hridhyan (Yesterday 12:15:50)

Saverio · Yesterday 13:28:28

Hi,

for what concers the AUR security issues that like waves periodically happen, could make it sense to introduce a trustability level for the package maintainers when they want to get orphaned packages?

I mean for example, like happens on forums (e.g. Discourse), the maintainer can get packages if some rules are fulfilled:

1. Should be older than 3 months;
2. Should have at least ten post messages on the forum answered.
3. Should not be banned in the last 2 moths
4. (other)

It's just an idea.
Thanks for the attention

seth · Yesterday 13:46:19

https://bbs.archlinux.org/viewtopic.php … 6#p2301096 and the post before and the ones answered.
tl;dr - this is too easily gamed and introduces a false sense of security/trust that simply is not there and cannot be provided but for turning the AUR into a centrally maintained repo (which we already have)

You have to review every PKGBUILD and every update to it before you run makepkg.
Try to see the AUR more like a highly specialized unix.stackexchange.com where you can get ideas how to build some software. Not as an energy inefficient distro repo that one can use on autopilot to install stuff.

Saverio · Yesterday 13:56:05

@seth thanks for clarification. Further if a package is missing in the official Arch repos and it's a "good" package, there is the possibility to propose for it's introduction.

loqs · Yesterday 14:09:50

Additionally allowing forks / duplicates on AUR would mean the increased work for the API server and more importantly for the AUR maintainers.

SimonJ · Yesterday 14:31:17

I feel sorry for the maintainers at the moment, it must so hard to fix one issue and another arise soon after.

https://lists.archlinux.org/archives/li … XZE4WALM6/

noesoespanol · Yesterday 14:37:58

loqs wrote:

...and more importantly for the AUR maintainers.

This I definitely understand.

loqs wrote:

Additionally allowing forks / duplicates on AUR would mean the increased work for the API server...

This, I don't.

A laptop, Intel 14700HX, 96GB RAM... nothing fancy, just average MSI laptop, one crappy none optimized phpBB forum... 6 MILLION views a day. Barely notice it. My point it, in this day and age, CPU load shouldn't be an issue anymore. And as for space, what's the total size of AUR, 5-10TB? That's peanuts. The enitre community can't muster a bit CPU and storage? Seems odd.

What I mean is, the solution shouldn't factor the CPU nor storage.

But that's just me.

Last edited by noesoespanol (Yesterday 14:39:16)

noesoespanol · Yesterday 14:38:51

SimonJ wrote:

I feel sorry for the maintainers at the moment, it must so hard to fix one issue and another arise soon after.
https://lists.archlinux.org/archives/li … XZE4WALM6/

Jesus. This is so strange. Clearly someone(s) doesn't like Arch. Awful.

seth · Yesterday 14:46:46

The actual attack runs over arch-unrelated npm/bun packages, the AUR is merely a vector to force those down peoples throats.
There's a good chance that the AUR is just captured by some much wider efforts.

… alternatively it's somebody I probably pissed off

5hridhyan · Yesterday 14:48:55

Jesus. This is so strange. Clearly someone(s) doesn't like Arch. Awful.

Yeah I feel the same, I mean come on if I'm correct, from 2025 august...? or so there was DDoS, AUR stuff, and now its June 2026, still it haven't stopped whether its DDoS, or this AUR, infact, this time the malicious actors have hit hard with the AUR. I mean it doesn't seem like hatred or revenge towords FOSS or its project, I can justify that statement by seeing that I didn't hear these stuff w/ the other Linux distro's or project also not to be mean Im wishing that to happen, they are safe, good. Still smtg stings like "Why Arch?" and it comes down to things like AUR's design philosophy, Project budgets compared to other distro/projects, popularity, its user base, just becomes much "more" attractive for bad actors than any other projects or distro, whatever it is, its just bad [/rant]

Edit:
probably this post belongs to the "grrr" thread

Last edited by 5hridhyan (Yesterday 14:50:14)

loqs · Yesterday 14:54:49

noesoespanol wrote:

loqs wrote:
Additionally allowing forks / duplicates on AUR would mean the increased work for the API server...
This, I don't.
A laptop, Intel 14700HX, 96GB RAM... nothing fancy, just average MSI laptop, one crappy none optimized phpBB forum... 6 MILLION views a day. Barely notice it. My point it, in this day and age, CPU load shouldn't be an issue anymore. And as for space, what's the total size of AUR, 5-10TB? That's peanuts. The enitre community can't muster a bit CPU and storage? Seems odd.
What I mean is, the solution shouldn't factor the CPU nor storage.
But that's just me.

My expectation is that with unlimited forks a helper would query all matching forks and for each dependency it would then query all matching forks and so on recursively to find the dependency graph so the load increase is not linear with forks of a package but closer to exponential.

seth · Yesterday 15:10:53

static quota, but before justifying the costs one would have to justify the outcome.
My gut feeling is that the idea is "so I won't ignore a maintainer change", but one could just check the git log to see whether the author has changed recently™.

Bumble · Yesterday 15:22:16

the AUR is user-based, and used to run on an open model
what's gone wrong isn't the users, it's the open model
you need a philosophical refactoring

to be honest, I don't even know why I use the AUR anymore
if there was some package I didn't know how to build, or didn't want to, I would just ask an LLM
and it would get done in a heartbeat, even without human dialogue i can just mindlessly copy and paste error messages until it gets it right
this takes zero effort, and I'll probably be doing it from now on
and i'm not sure any of this is even necessary, because LLMs just make the AUR itself deprecated, but I'll leave this here in case anyone finds it useful

one solution would be for users to make their own private repository, with simple ID verification required to be a contributor, where each user pays the fees for their own ID process
but let's assume this isn't what most people would go for, there's still a better way to make is a semi-private club that's welcoming to newcomers

assuming people want to stay anonymous online: you need an improved reputation model
in terms of what the AUR needs, it's not safety measures, it requires reorganization
right now, packages just have simple upvotes, we probably need those for maintainers as well
reorganize its concept to allow multiple users to own any single package, and they can all upload their own PKGBUILD
this would be the easiest way to diff lines like dependencies and makedepends to determine which users have inserted unique packages that no one else has
in choosing which PKGBUILD to download, you can also view the reputation of those who provide it
give reputation to the maintainer instead of the package, and the reputation can be displayed as a time-series plot rather than a single number
the reputation sphere would be more like a stock market now
and upvote on a specific package would go to the maintainer's total reputation
any red flags, like a recent decrease in reputation, could trigger an AUR helper warning about the maintainer

as one final touch: add a second score, a dependency diff count to each maintainer, where lower means better, with vague guarantees
unique depends/makedepends that aren't seen anywhere else in the AUR, gives a +1 for each new package, maybe even listing them out on their profile would be useful too
but this introduces a problem that if a lot of new users suddenly start inserting tons of crooked dependencies, it wouldn't seem like a big diff, so the dependency should have an independent score divided by the amount of time it took to rise to to such popularity, a time-series plot showing its behavior over time, and
one could even imagine visualizing this diff score within a single package could be just as useful
people signing up and suddenly maintaining tons of packages but with the same strange dependency patterns would be easily detectable, and both the maintainers and packages can be intrinsically flagged by a simple scoring system visible to the user, that would then be able to be represented by a distribution showing they are in the top 90%, or whatever, of packages or maintainers with strange behavior

this would leave a hole where individual dependencies could still sneak in subtly, just not in mass waves
and most users wouldn't run into this problem given the reformated reputation system above generally blocks it out
it also wouldn't stop people from making a PKGBUILD for package A secretly named after package B
it's not perfect, but it's a plan

the simplest conversion would be to take the existing reputation scores of each packages owned by any person, and transfer it to the maintainer. small caveat: i think the votes become inherited by new package maintainers after taking an orphan. if there's any record of when those votes were cast, they could be transfered to the maintainer who gained the package that vote

AUR helpers would adapt with an option to specify the maintainer, and possibly list them in terms of reputation
you could also put a setting in your aur helper to notify you of new/previously unseen npm or bun dependencies

this wouldn't stop jia tan, but that's fine because jia is always going to be operating further upstream anyways
one might also question, after going through all this trouble, to make a multifacted user repository, who are they serving?
if everyone is contributing their own PKGBUILDs, then it's a bunch of people who don't follow the arch philosophy that are probably downloading them
idk

5hridhyan · Yesterday 15:42:53

so your point is

*Allowing multiple people to upload conflicting PKGBUILDs for a single package
*creating time-series graphs for maintainer upvotes
*calculating algorithmic "dependency diff scores" to detect anomalous packages

I mean turning a simple git-based repository into a massive, data-heavy analytics engine?

Bro, this ain't corporate drama, how will you even implement any of this? you could have suggested shutting down the AUR instead of this complex mess. LoL

Kirby · Yesterday 15:59:05

Correct me if I'm wrong, but aren't the majority of pkgbuild updates just to keep pace with a new upstream release? A new commit that changes only pkgver and sha256sums could be seen as mostly safe, while anything more than that can be marked for extra scrunity

Last edited by Kirby (Yesterday 16:04:26)

noesoespanol · Yesterday 16:05:28

Bumble wrote:

...to be honest, I don't even know why I use the AUR anymore
if there was some package I didn't know how to build, or didn't want to, I would just ask an LLM
and it would get done in a heartbeat, even without human dialogue i can just mindlessly copy and paste error messages until it gets it right
this takes zero effort, and I'll probably be doing it from now on
and i'm not sure any of this is even necessary, because LLMs just make the AUR itself deprecated...

Really well said. This is also the reason I'm using Arch now. There was no need of forums, asking people, getting stuck without help etc., I installed Arch from zero to full in about 2 hours. Any little issues I hit on the road, I asked Grok (even the free version was enough) and it was solved instantly.

I think generally speaking, we are looking into a new world, a new internet. We need to learn to do things a little bit differently now that we have LLMs available. It's a bit like running single threaded vs multi-threaded. This isn't the 80s anymore... well, this isn't the 2010s anymore! hahaha...

Yes, I'm old and grumpy.

On the flip side of this, it's nice to have trusted sources too, but solving trust is... well, I guess impossible? Look how many bots are out there now. 90% of the internet traffic or something. Maybe ID verifications will solve these issues. (right? RIGHT? lol)

Last edited by noesoespanol (Yesterday 16:07:31)

5hridhyan · Yesterday 16:07:36

Kirby wrote:

Correct me if I'm wrong, but aren't the majority of pkgbuild updates just to keep pace with a new upstream release? A new commit that changes only pkgver and sha256sums could be seen as mostly safe, while anything more than that can be marked for extra scrunity

True, but not in all case, sometimes you have to clean upstream mess
for example https://aur.archlinux.org/packages/happy-cli
had to re-write stuff for pnpm which was pain, and testing was mostly seeing it to fail, I some how shipped it in a working state and disowned it, which seems like it was caught in a crossfire

Last edited by 5hridhyan (Yesterday 17:46:39)

Arch Linux

#1 2026-06-13 20:29:42

Solution to the AUR crisis

#2 2026-06-13 20:33:50

Re: Solution to the AUR crisis

#3 2026-06-13 20:37:20

Re: Solution to the AUR crisis

#4 2026-06-13 22:50:28

Re: Solution to the AUR crisis

#5 Yesterday 04:12:17

Re: Solution to the AUR crisis

#6 Yesterday 07:25:07

Re: Solution to the AUR crisis

#7 Yesterday 11:14:33

Re: Solution to the AUR crisis

#8 Yesterday 12:02:05

Re: Solution to the AUR crisis

#9 Yesterday 12:04:22

Re: Solution to the AUR crisis

#10 Yesterday 13:28:28

Re: Solution to the AUR crisis

#11 Yesterday 13:46:19

Re: Solution to the AUR crisis

#12 Yesterday 13:56:05

Re: Solution to the AUR crisis

#13 Yesterday 14:09:50

Re: Solution to the AUR crisis

#14 Yesterday 14:31:17

Re: Solution to the AUR crisis

#15 Yesterday 14:37:58

Re: Solution to the AUR crisis

#16 Yesterday 14:38:51

Re: Solution to the AUR crisis

#17 Yesterday 14:46:46

Re: Solution to the AUR crisis

#18 Yesterday 14:48:55

Re: Solution to the AUR crisis

#19 Yesterday 14:54:49

Re: Solution to the AUR crisis

#20 Yesterday 15:10:53

Re: Solution to the AUR crisis

#21 Yesterday 15:22:16

Re: Solution to the AUR crisis

#22 Yesterday 15:42:53

Re: Solution to the AUR crisis

#23 Yesterday 15:59:05

Re: Solution to the AUR crisis

#24 Yesterday 16:05:28

Re: Solution to the AUR crisis

#25 Yesterday 16:07:36

Re: Solution to the AUR crisis

Board footer