How (and not) to fix the AUR

seth · 2026-08-02 23:40:19

How to NOT fix the AUR

There are a lot of reddexpert opinions on what *needs* to happen (or else…), so explaining why you're wrong:

1. You cannot *fix* the AUR by aborting it. You can abort it, but that's not fixing it.

2. Turning the AUR into something that is not the AUR is the same as aborting it, therefore
2.a) "Only trusted users must commit to the AUR" (instead of just a regular repo for some reason)
2.b) "Trusted users must vet and sign all 100k packages in the AUR" (instead of just creating the packages, what would be easier)
2.c) "The AUR needs to work like PPAs" (ie. "archlinux needs PPAs")
2.d) "There just need to be more packages (especially my personal pet-peeve) in the official binary repos"
are fair (albeit not necessarily feasible) calls, but none of that comes even remotely close to even addressing the AUR situation.

3. Calls for "namespaces" / forks hinge on the *false* premise that the problem is somehow limited to orphan adoption - and fix that by introducing a bunch of other problems
3.a) Server overhead (notably on maintaining forked repos)
3.b) Fragmentation (why talk to the maintainer about what you think is a bug or bad default or whether to add some downstream patch if you can just fork your own itch?)
3.c) Confusion ("Ok, I need foo but which of the two dozen versions is the right one? I guess I'll have to check 24 PKGBUILDs to figure it out…")
3.d) Silent orphans (you installed gnarf/foo but that has been abandoned and does't get updates and the crowd has moved to sna/foo - when and how do you notice that?)

4. Honorary mention for everything "just put AI to it":
You've to understand that AI finding packages that follow a recent, specific, known pattern is not the same as AI analyzing packages for generic malware.
If you want to put AI to it, ask the AI whether it has objections regarding the PKGBUILD you're currently reviewing, but integrity checkers, AI or not, can only provide you an opinion, not a guarantee.
They do therefore not allow the AUR to drop the demand that you need to verify and validate what you'er going to run on your system.

How to fix the AUR

The first step is to understand the nature of the problem.
People will say that the AUR or its users are being attacked, but that's wrong (and formally not possible, the "attacks" are necessarily too transparent to be effective)
In reality the AUR is being vandalized and its users currently suffer from the consequences in different ways.

This distinction is important, because vandalization isn't necessarily goal driven or the goal might differ from those implied by attacks.
Eg. the goal could be to terminate the AUR rather than to actually compromise any systems or the vandalization might be 4chan-style, just for the lulz.

The mission is therefore NOT to prevent attacks but to disincentivise the malicious vandalization.
Since it is impossible to know the motive (or there might be different ones behind different waves) it must be treated as irrelevant detail.
We shall therefore assume that the vandalization is purely for the lulz.

The success metric is the vandalization being perceived as harm, which it generally speaking isn't:
A common pattern is to adopt some unmaintained orphaned package nobody cares enough about and add some malware - other than reddit users seem to believe, there's no one-click adoption-transfer of an actively maintained package.
Likewise someone might just upload some deceptive derivate, "v1valdi-bin" - other than reddit users seem to believe, the problem isn't tied to package adoption at all.

The vandalization is then driven by and driving FUD:
"Nobody vets packages before installing them from the AUR; therefore nobody can ever know whether something is affected by these incidents - the AUR is become useless!"

There's a kernel of truth in that:
The AUR *is* useless to anyone not vetting packages before installing them from there, anybody else isn't touched by the recent vandalizations anyway.
This has always been the case and a supposedly changed Arch userbase (because derivative distros only exist since this year, I assume) changes absolutely nothing about that.
What changed is that the recent incidents made this reality inevitably obvious to everyone.

The same way however, a half-pipe is very useful to a competent skater and a completely useless hazard to everyone else.
So why do non-skaters not casually drop into a half-pipe?
Because it's fucking scary! You instinctively understand that this is not gonna end well.

In a way the malicious vandalization provides what's necessary to scare away users that simply are not fit to use the AUR (for lack of competence or diligence) - the only problem is that it also carries active harm.
(The other "problem" is that those users then proclaim that *everyone* has to stop using the AUR and use flathub or whatver)

The approach could therefore be to steal the vandalizers jobs and simply institutionalize the vandalization:
Systematically vandalize PKGBUILDs w/ a git hook by randomly shadowing (early) functions like verify() or build() to print a clear enough warning and exit makepkg.

This isn't a major problem to proper users: the PKGBUILD is still fully intact (a later function will replace an earlier one w/o the need to remove the latter from the file), the message can be made easy to spot (some all-caps part) and the function removed when inspecting the PKGBUILD.
Everyone else can have a jump scare and blind-trust automated builds using a helper won't work.

The tricky details will be to prevent AUR-helpers from undermining this (in any way but forcing the user to look at the PKGBUILD) and (probably?) to keep git merges smooth.

Extras

For additional active defense measures it *might* help to detect the vandalization waves early by dropping some honeypots:
Useless orphan packages (despite not the only still a popular vector) packging nonsense but with manipulated statistics (upvotes, downloads, etc)
Once such is adopted there's probably something up.

Another active measure in the same directions is of course to rake the forest:
Systematically ping maintainers of stale *looking* packages (many VCS package will falsely appear stale) and ask them to respond or update the package within the next 3 month to prevent the package from being removed.

It's however unclear whether any of this can actually add anything significant if disenfranchising incompetent AUR use renders the AUR an uninteresting vandalization target.

cryptearth · 2026-08-03 00:24:21

to me there's a flaw in "a package that wasn't updated in X time becomes outdated and later orphaned automatically"
what about software that's just "complete/final/free of bugs"?

like, minesweeper or solitair? these are simple games with simple rules and at some point an implementation is just done - because both games not guarantee every game can be finished due to randomness

why should such a package receive a heartbeat update every now and then if nothing has chamged because nothing has to?

or Factorio: the devs released a statement: "the game is finished, we're done with what we planed, all bugs have either be fixed or the last few ones won't be touched - 2.1.x is the final update"

ok, these are just games, but i'm sure there're other types of software - for example i have a few apps on my phone last updated before my current device was build, some were pulled from Google's PlayStore (likely for that very reason) - but they still work and do thier job

do they contain some bugs or security vulnerabilities? maybe but unlikely - Android apps are written in Java - and be design this language isn't vulnerable for buffer overflows and such - if something goes out of rang or becomes null it results in RuntimExceptions which usually cause just a crash

so, let's say I implement 7 card stud poker (something I haven't found and hence am currently working on)
at some point that implementation will be "just complete" with all bugs fixed working perfectly according to someones rules, maybe with options to set a few house rules
why should i bump its version every month just to show "hey, it's still 'maintained'" when it really isn't because it's "just done"?
why would it be considered outdated and then orphaned if i don't? it's not like i have actively abadoned my project - there's just nothing left to be done?

loqs · 2026-08-03 01:12:23

@cryptearth a project may be complete but how does that address PKGBUILD vandalism?

Edit:
On complete projects needing no maintenance see https://archlinux.org/todo/rebuild-pack … two-years/ so far excluding errors in the project I have encountered packages failing to build due to newer autoconf, cmake, gcc, pacman and rust.

Edit2:
Something I have not seen proposed before is keep AUR registration disabled until AUR single single on integration is completed. I expect this would remove a number of dead account and accounts without valid emails, reducing the number of account that can potentially be compromised.

Last edited by loqs (2026-08-03 01:47:30)

cryptearth · 2026-08-03 05:17:13

my focus was specific on Java as, although yes there were a few removals of long deprecated stuff and java9 broke quite some stuff with project jigsaw, it's quite stable
I have classes compiled 10+ years ago still running without issues

how could this prevent such vandalism we experienced? by marking a package "final" it can't become outdated/orphan on it's own
if, for some reason, a project becomes unable to build from source, because the language and tools changed so much 10 year old build instructions no longer work, then it can be reported and set outdated by an aur mod

although now that you given an example i wonder what's the actual reason the packages in the linked list breaks - if it's because gcc updates and introduce breaking changes that's hardly the fault of the original dev
i myself recently had to setup from archive somewhere in late 2022 in a vm to get an old project building again because in early 2023 some update broke the entire chain
unfortunate the software wasn't update because the product went EoL long ago and was never really meant for it (change from legacy seabios to uefi for a one-board-system)

maybe for such software either some protective flag like "archived" could be used - or instead of have them decay the usual way outright removed

hell - i don't know how to fix it - point is: to me the current system has a flawed auto-process which enabled the vandalism in the first place (or at least made it easier)
so maybe instead of asking "how to harden overtaking old packages?" another question might be "do we even need this auto-outdated/-orphaned in the first place?"
yes, it might use more human resources than the current process - but the clean up showed that if some attacker abuses the system seemingky automated remove all that junk is quite a lot more effort than "hm, a request for overtake?, let's check it" would have needed - as someone could have noticed "wait a minute? some random account request for a bunch of old stuff without any comnection?"
i don't say this would have prevented it - but it maybe could have or at least keep it within limits

5hridhyan · 2026-08-03 06:09:53

Systematically vandalize PKGBUILDs w/ a git hook by randomly shadowing (early) functions like verify() or build() to print a clear enough warning and exit makepkg.

So all those times I accidentally broke PKGBUILDs, spent hours fixing them, and blamed my packaging skills... turns out I was implementing a high-level security feature all along? Nice. I can leave them broken. FOREVER.

WorMzy · 2026-08-03 07:48:50

loqs wrote:

Something I have not seen proposed before is keep AUR registration disabled until AUR single single on integration is completed. I expect this would remove a number of dead account and accounts without valid emails, reducing the number of account that can potentially be compromised.

Putting auth behind a broken registration process would certainly prevent abuse.

mariguana · 2026-08-03 14:16:32

Yes we're supposed to check pkgbuilds, yes we're supposed to understand that installing anything off the AUR is just like pulling random code and executing scripts or compiling with admin privileges, yes, people who press the big commit suicide button shouldn't complain after pressing the big commit suicide button. But we're getting to a point where very questionable design choices should be addressed because, at this point in time, the AUR clearly isn't operating normally when waves of attacks are happening regularly to the point where we have to block pushes temporarily, close package adoptions, etc.
We are going to have to choose between "it's the user's fault" (which it kinda is), pretending it's not a problem, and limiting the AUR's functions due to a lot of users seemingly making a lot of errors. Let's pick one, please.

I'm not sure what type of checks are done but clearly there aren't enough of them. Why do we, in an era where these attacks are automated easily, have to rely on users reporting issues with a package they inspected? Are we really going to pretend we can't even have automated flagging of suspicious packages, not even through heuristics or anything fancy like that but just at the very least these that have calls to curl, npm, etc in them?

I mean hell... I don't think people who manage the AUR are necessarily the same who made this forum for instance but just the fact that I had to register to say this and received a password in clear by mail speaks volume about the current culture of this community when it comes to security. Maybe the immediate self destruction button needs a warning label? Personally when I installed arch, I was fine with having to check sources, pkgbuilds, and compile a significant amount of packages on my own, but I wasn't really aware of the adoption mechanics and could have absolutely gotten infected through an update rather than an installation.

5hridhyan · 2026-08-03 15:00:08

loqs said:
Something I have not seen proposed before is keep AUR registration disabled until AUR single single on integration is completed

It's already taking weeks and months for the GitLab SSOs to be allowlisted, and an AUR SSO wouldn't be any different.

Last edited by 5hridhyan (2026-08-03 15:09:50)

SimonJ · 2026-08-03 15:00:26

mariguana wrote:

Personally when I installed arch, I was fine with having to check sources, pkgbuilds, and compile a significant amount of packages on my own, but I wasn't really aware of the adoption mechanics and could have absolutely gotten infected through an update rather than an installation.

Well here's the thing, I installed Manjaro first, as introduction to Arch, then Endeavouros and then Arch. At the time I thought installing yay and then bumbling around the AUR was fine. I didn't check anything. I didn't know to check anything. Then I learnt more about it and became more cautious, but here's the thing, users of derivative distros do not, usually, routinely check these things.
I am guessing that is changing, I haven't checked. So yes Arch is going to change but I imagine the attack was aimed more at derivatives than Arch itself.

combuster · 2026-08-03 20:50:59

From my POV, this is a viable attack vector (and always have been) on Arch Linux community as a whole, and someone is using it to inflict real damage.

I agree that vandalism is a word in general that can be used to describe what's happening here (similar to wikipedia vandalism which in part can be malicious) but there are several misconceptions that is making the attack even more impactful:

1. AUR Home description header is perfect - it states that you are, in fact, contributing a PKGBUILD. There is a disclaimer, clearly stated. But again, the word package is used intermitently with PKGBUILD below the description - giving a notion that it's the same thing. Because of that, a title online "Over 400 Arch Linux packages compromised to push rootkit, infostealer" is in fact correct, only thing missing is the word AUR from the title. Would "Over 400 Arch Linux PKGBUILDS compromised to push rootkit, infostealer" be any better? Best would be "Over 400 PKGBUILDS from *think of a new name here* compromised to push rootkit, infostealer". There is still a connection as it being somehow endorsed and owned by the Arch maintainers because in fact it is and the fix is their responsibility:

https://wiki.archlinux.org/title/Package_Maintainers

2. AUR submission guidelines state "Verify carefully that what you are uploading is correct. Packages that violate the rules may be deleted without warning.". I interpret this as - OK, so Arch Linux maintainers will delete if something is wrong, and should delete if something is wrong. Whatever procedure for this workflow is - should be clearly stated. When and how? When the package is being flagged or reported as malicious? How the report should be filed, what should it contain as proof.Do you have the capacity to follow up on every one? Have a bot running over AUR? etc, etc...

The way you've envisioned AUR to function should be described, not a word less, not a word more, exact and correct. It's place is currently in the title bar between Security and Download - has the same look and feel as the rest of the project. Are you sure this is what you want? That anyone can create and upload a malicious PKGBUILD and it feels like the part of the official project?

This is not damaging to experienced Arch community members, we either vet every PKGBUILD or we're not using those at all (git clone, configure/make etc) but is problematic for new/inexperienced/or downright lazy/ members or those that would try Arch but reading news of malicious packages gives them a scare or a sense of distrust. Also members that have the need for badly architected apps with tons of dependencies may resort to AUR helpers and vetting each and every one could prove "bothersome" but in some cases unrealistic to say the least.

In short, real damage is the notion of distrust that can circulate online because, most of all, AUR "packages" feel as part of the project and with Arch maintainers engaged in one form or the other, and Archers getting their passwords/data nicked - which is dangerous and not something to be overlooked easily even if you feel remotely engaged and have any sense of ownership for the material source of those troubles. Even one is a one too many.

Anyone can distribute malicious PKGBUILDS online, peddle them through youtube videos, SEO poisoning, you name it. This rings true for anything else out there. But the pickle here is that it's happening in the section of the project that feels very much officially part of it. If there is no capacity to prevent this from happening or never have been than make it painfully obvious that package maintainers have nothing to do with it. ie, different color/style of the page, linked in the lower right and making it feel for what it is: a "marketplace" for scripts that can be used to compile software from source on Arch Linux, both malicious or otherwise. That should make it even more frightful to use, and only when in dire need - which is how everyone should approach AUR at all times. Then it will fix itself.

KISS principles and being that close to upstream are great values on their own that creates a unique character for Arch Linux which makes it an easy recommendation to anyone, be it the intention to run current/latest/patched software, develop, test, understand what you own, you name it. I don't feel AUR design is contributing that much to mentioned above - but if you have ideas how to resolve it differently, or believe that majority of Arch community members feel different - then I would like to stand corrected.

loqs · 2026-08-03 21:04:27

cryptearth wrote:

although now that you given an example i wonder what's the actual reason the packages in the linked list breaks - if it's because gcc updates and introduce breaking changes that's hardly the fault of the original dev

Every major gcc version update introduces breaking changes. Most likely to cause a breakage is a change to the default C or C++ standard then you have headers no longer transitively providing things, warnings becoming errors and the compiler itself becoming better at identifying errors in code.

aminepro · 2026-08-03 21:49:01

As expected I need to focus on learning everything well before conversing in the forums. Is reading the only way to learn stuff? as I'm doing it anyway, keeping on trying. (It has become scary to do anything without understanding>knowledge), Well most of my problems seems rather personal so I have no one to blame.

noesoespanol · 2026-08-04 04:07:39

cryptearth wrote:

to me there's a flaw in "a package that wasn't updated in X time becomes outdated and later orphaned automatically"
what about software that's just "complete/final/free of bugs"?
like, minesweeper or solitair? these are simple games with simple rules and at some point an implementation is just done - because both games not guarantee every game can be finished due to randomness
why should such a package receive a heartbeat update every now and then if nothing has chamged because nothing has to?
or Factorio: the devs released a statement: "the game is finished, we're done with what we planed, all bugs have either be fixed or the last few ones won't be touched - 2.1.x is the final update"
ok, these are just games, but i'm sure there're other types of software - for example i have a few apps on my phone last updated before my current device was build, some were pulled from Google's PlayStore (likely for that very reason) - but they still work and do thier job
do they contain some bugs or security vulnerabilities? maybe but unlikely - Android apps are written in Java - and be design this language isn't vulnerable for buffer overflows and such - if something goes out of rang or becomes null it results in RuntimExceptions which usually cause just a crash
so, let's say I implement 7 card stud poker (something I haven't found and hence am currently working on)
at some point that implementation will be "just complete" with all bugs fixed working perfectly according to someones rules, maybe with options to set a few house rules
why should i bump its version every month just to show "hey, it's still 'maintained'" when it really isn't because it's "just done"?
why would it be considered outdated and then orphaned if i don't? it's not like i have actively abadoned my project - there's just nothing left to be done?

RIGHT? If someone wants to "update" an "old" package, it should be FORKED, and marked as such CLEARLY, so that the original remains UNTOUCHED.

Imagine if you had some code or whatever on GitHub and you were ill a while or travel or anything life event, you come back and someone just took over your stuff and messed it all up, like WTF is this kind of "system"? It's a trash bin basically, that's not a system at all. It's like keeping your home door open in middle of a big city and letting anyone just walk in and out and move and do stuff in there. It's all just very strange to me.

Last edited by noesoespanol (2026-08-04 04:09:56)

cryptearth · 2026-08-04 06:01:32

@noesoespanol no full-quote needed
as for forks: unfortunately, forks are not allowed on the AUR (what i'm split about because although i understand why i also see legit reason for allow them)

Last edited by cryptearth (2026-08-04 06:02:18)

flying sheep · 2026-08-04 12:59:13

The AUR *is* useless to anyone not vetting packages before installing them from there, anybody else isn't touched by the recent vandalizations anyway.

I’m touched by it now that uploads are deactivated. That and annoying Redditors have been the full extent of damage to me.

They’re right in one way though: originally Manjaro, now CachyOS and so on brought in a lot of users with their own culture of seeing the AUR as something it isn’t. That’s a problem.

As expected I need to focus on learning everything well before conversing in the forums.

That sucks, people should be less elitist. In some cases (not talking about you!) I understand though: sometimes you read the same question a millionth time on the same day and get a bit peeved because there is a search function.

seth · 2026-08-04 13:57:11

@cryptearth

there's no expectation to update packages.
As mentioned - VCS ones will typically have an extremely low update frequency.
The point (of that extra measure) would be to ensure that a package is still actively maintained and the consequence of not responding to to the live-ping would be to remove the package from the AUR, explicitly to prevent somebody from flagging it out of date, orphaning and maliciously adopting it (because that is not a possible vector w/ maintained packages - the maintainer would object to both, the out-of date flag and the orphan request)
It's about being more aggressive to remove cruft from the AUR.

What happens if a package is flagged "final" and then abandoned and ultimately starts to show issues because it no longer builds w/ newer toolchain versions etc?
Edit: also later pointed out by loqs

I'd also want to stress that I threw that in there as additional active measure that can be taken for AUR maintainance.
It would under no circumstances fix anything about the current situation. The adoption path is a popular vector because the script kiddies are unimaginative. It's by far not the only way to vandalize the AUR to scare its users.

@WorMzy

I'm pretty sure loqs meant to point out that forcing users to renew/re-register their account would serve as an implicit filter for silently unmaintained packages.
The ridiculous state of the SSO that currently turns filing bugs into a privilege is kinda the opposite of the AUR and would rather lead to some form of PPA where a trusted elite shares PKGBUILDs (at which point the AUR would become a lower tier repo)

@mariguana

https://www.youtube.com/watch?v=5RyYrs5tu60 - mandatory watch
* Having people register w/ a public key would not achieve anything in terms of addressing the AUR situation.
* Running heuristically filters on PKGBUILDs would at best provide a completely false sense of security - the "attacks" can be automated because in reality they're also completely harmless.
I'm not sure whether you've actually read the initial post or just sought to comment on the situation but the only solution maintaining the nature of the AUR can be to ensure that the remaining AUR users are not scared by this kind of vandalism.
Hence the idea to enforce the requirement to review the PKGBUILD by systematically breaking them. Everybody who cannot or does not want to deal with that is simply better off not using the AUR (which they then no longer can)

@combuster

Semantics are hard and communication flawed. Any audience will get or communicate things wrong inevitably.
I'd tell you to re-phrase the wiki but I'm afraid it as well as the AUR webpage are full of explicitly warnings about the situation and in reality people are confused not by reading those statements but very aggressive 3rd party "advertising" in social media channels.
The idea however was to bypass those ambiguities and move the terms of usage into the process in form of a hard-stop, making clear that you've to review (and fix) the PKGBUILD

@noesoespanol

seth wrote:

How to NOT fix the AUR

seth, item #3 wrote:

*false* premise that the problem is somehow limited to orphan adoption - and fix that by introducing a bunch of other problems

were ill a while or travel or anything life event, you come back and someone just took over your stuff

This isn't what's happened here, but
https://wiki.archlinux.org/title/AUR_su … nes#Orphan
https://wiki.archlinux.org/title/Arch_U … ut-of-date
you need to be offline for at least 4 weeks for this to become a realistic situation.

I guess the cooldown could be expanded but you'll also have to account for legitimate maintainer abandonment.

@flying sheep

seth wrote:

the AUR is being vandalized and its users currently suffer from the consequences in different ways

You're not touched by the vandalization, but the consequences?
For context on aminepro see https://bbs.archlinux.org/viewtopic.php?id=314340 - his claim is wrong. You're ok to state uninformed nonsense - I'll let you know

cryptearth · 2026-08-04 15:19:25

@seth
to keep my reply short and within topic: i only know java and php - both with remarkable long-term stability since i first learned them 20-ish years ago
if one keep external libs the same version there's not much that was removed or broke since the hard cut from java8 to java9
same goes for php4/5 to php8
so, for me, i don't know hard breaks because the language and its toolchains changed over two decades

flying sheep · 2026-08-04 16:23:02

seth wrote:

You're ok to state uninformed nonsense - I'll let you know

yikes, I understand when people don’t feel welcome in the presence of attacks like that. chill out bro.

I have no problems with your original post, but if this is how you choose to engage with people, nobody will want to work with you.

Last edited by flying sheep (2026-08-04 16:26:13)

combuster · 2026-08-04 17:03:14

To put things in perspective:

https://digital-strategy.ec.europa.eu/e … ementation

49. Given the specificities of the development of FOSS, which often involves multiple
contributors, decentralised collaboration models and a separation between
contribution and decision-making, it is useful to clarify that FOSS is considered to be
'under the responsibility' of natural or legal persons who publish it and exercise
primary control over its development, releases, and distribution decisions (often
referred to as ‘maintainers’). Persons who contribute source code but do not control
releases, roadmaps, or governance decisions are considered ‘contributors’; in such
cases, the FOSS is not under their responsibility, even though they contributed code
to it. The mere existence of technical permissions, such as commit access, is not
sufficient to establish that the FOSS is under that person’s responsibility;
responsibility lies with those who publish and control the FOSS.
Example 13: An individual developer or an employee of a company submits a ‘pull’ or
‘merge’ request containing a security patch or a new feature to a FOSS project. The
project’s maintainers review, accept and merge the code into the main repository,
subsequently including it in a new release. In this scenario, the person who submitted
the pull request is a ‘contributor’ and is not subject to the CRA. Although that person
contributed source code, they do not exercise primary control over the development,
releases or distribution decisions.

I'm not going legal eagle on anything, Arch is not being put on the market in any commercial sense, donations in this case are not being recognised as monetisation for profit - but I'm reluctant to blatantly pass the responsibility to people using the software, as are people who wrote this, while owning part of the workflow or being able to decide upon distribution directions. I tend to own or disown (helping for me is owning something, no matter what the papers say) I sense that current approach for maintainers is to own - but the way AUR is functioning currently is too much of a burden - even though I can't speak for them and haven't seen anyone actually complaining.

seth · 2026-08-04 18:55:04

@flying sheep
I was trying to clarify the context of aminepro's (false) assertion and put a funny smiley at the end to stress the tongue in cheek part.

@combuster
Who does "exercise primary control over its development, releases, and distribution decisions" of a PKGBUILD on the AUR or anywhere else?
Who does "contribute source code" to it?
So who is responsible for the contents of that PKGBUILD?

The AUR is a moderated, indexed and special-purpose pastebin - not a coherent project with a leader board that controls "development, releases, and distribution"
It is more akin to this forum than to some software VCS where a project owner manages patch submissions.

combuster · 2026-08-04 20:03:31

Who does "exercise primary control over its development, releases, and distribution decisions" of a PKGBUILD on the AUR or anywhere else?

Not just the PKGBUILD but AUR as a service. AUR functions the way it's intended by people that brought the idea to fruition, and maintained and developed/adapted by community leaders and package maintainers. Control stems from ability to allow or deny access to a service, establish terms of usage and provide resources for it to function, and moderate it as you've mentioned. PKGBUILDs are contribution to a service that brings added value to Arch Linux project. Now that value should be reassessed considering everything and influence the future of AUR as a service.

Who does "contribute source code" to it?

Someone wrote a code for it to be managed, indexed and searchable and it's open. PKGBUILDS are also contributions.

So who is responsible for the contents of that PKGBUILD?

Well, according to the document, sure as hell not the "users" And if AUR is owned and being presented as an added value and a part of the Arch Linux project - than apparently not the PKGBUILD contributors either.

I'm bringing in this as another view so that whatever choice is made regarding AUR should prove it to be as resilient as possible. And communication regarding it too.

Last edited by combuster (2026-08-04 20:09:09)

seth · 2026-08-04 20:13:42

Not just the PKGBUILD but AUR as a service.

Does pastebin "exercise primary control over" what I dump there?
Does this forum "exercise primary control over" what I write here?
I like to think that actually rests with me.

Well, according to the document, sure as hell not the "users"

The user becomes absolutely responsible for the content of the PKGBUILD before they run "makepkg" - that's being made adamantly clear in the AUR context and true no matter where they downloaded it.
The user effectively decides to run a script some dude posted on the internet and runs that on their system.
Who else would be responsible for those actions?

combuster · 2026-08-04 20:49:10

Well, I don't waste my thoughts on pastebin, but this forum can't exercise nothing on itself, their mods can. Each of them are taking ownership of their own thread groups and feel responsible for the content there. If there are enough of them - they react as fast as possible. But neither pastebin nor this forum have an impact as "packages" do.

The user becomes absolutely responsible for the content of the PKGBUILD before they run "makepkg" - that's being made adamantly clear in the AUR context and true no matter where they downloaded it.

Archer in me screams yes to what you've said right here - if it weren't for all the other facts mentioned surrounding this whole shebang.

The user effectively decides to run a script some dude posted on the internet and runs that on their system.
Who else would be responsible for those actions?

If that were the entire truth, you would let them share those PKGBUILDS on pastebin instead of AUR.

It doesn't feel right for me to pursue this past it's usefulness, if anyone found any...

noesoespanol · 2026-08-05 02:49:47

cryptearth wrote:

...
as for forks: unfortunately, forks are not allowed on the AUR (what i'm split about because although i understand why i also see legit reason for allow them)

An absolute bare minimum should've been: automatically rename or archive the old package when someone new takes over. "PackageXYZ.2026-01-01.old.zip".

My God.

Last edited by noesoespanol (2026-08-05 02:50:36)

seth · 2026-08-05 06:50:16

combuster wrote:

If that were the entire truth, you would let them share those PKGBUILDS on pastebin instead of AUR.

Everyone's free to post PKGBUILDs on pastebin and hand around links.
You'll have to do the latter because pastebin doesn't provide a searchable index

seth wrote:

The AUR is a moderated, indexed and special-purpose pastebin

You could technically abuse fluxbb (the forum software) to provide the same function (but not as efficient)

@noesoespanol
The AUR works via git, you can revert to any specific index at any point - and also inspect to log to see what has happened since then.

I'm afraid your god is busy fixing the rest of the planet.
I can hear him gasping "Why in gods name did I make the humans?" and get a mean side eye when reminding him that he's that god's name…

Arch Linux

#1 2026-08-02 23:40:19