I can't say I'm convinced introducing partial human review systems to
AUR is the right move. The scope of the repository is huge (100k+
packages, many of which are orphaned and even more are likely outdated,
so things that will change ownership once someone cares) and includes
very niche things it would be hard to find reviewers for.
Enthusiastic people on forums or IRC are hardly the people who you can
count on to actually commit to becoming package maintainers, let alone
people you can by default trust with actually verifying whether or not a
package is safe. I would expect 90%+ of the people currently up in arms
about this and ready to change the world for the better to forget about
it in a week or two once they get bored of using LLMs to produce the
100th "PKGBUILD checker AI tool" this week.
I feel like a massive effort to turn AUR into something it isn't (a
repository with human reviews maintained by trusted maintainers) is just
something that makes it prone to getting a clogged up review queue,
becoming inaccessible to new contributors and outdated if people can't
"easily" take over packages that have been abandoned, especially with
the rules regarding duplicate submissions.
If people want a proper human reviewed PKGBUILD or package repository
for things unavailable in extra for one reason or another they should
look to create one for that purpose (think RPMFusion) rather than trying
to repurpose AUR for that goal. At least that way whatever group of
volunteers that wants to take up such a review effort can scale up their
repository and work according to their capacity rather than hoping they
have the capacity of moderating the entire AUR.
At the very least I find the idea of a half human reviewed repository
where things are maybe sometimes reviewed based on some heuristics (that
a potential attacker can just test their malicious package against
before publishing) is just a worthless exercise in trying to build a
false sense of security in a repository where people should trust
nothing but their ability to review the contents of a package before
installing it.
On 6/17/26 9:37 AM, David C Rankin wrote:
On 6/16/26 9:32 PM, Andreas Reichel wrote:
Once a request is accepted, the new maintainer could be put on a
temporary status. Instead of their first update going live
immediately to everyone, it could go into a staging area where the
system automatically checks the changes in the build file.
And who shall do that? Who sponsors this work and effort?
Well, (unintended long post thinking through the human issue)
If I had a nickle for each time I've read the "who will do it?"
response regarding proposals aimed at shoring up AUR with a human
involved -- I could retire. I'm not being critical, but since this
began that same question has been injected to stymie the review idea,
here, on libera.chat and even in the bbs.archlinux thread -- so let's
answer that question.
The fact of the matter is, a human is necessary. Whether that be to
review adoptions or flagged suspicious commits identified by the
tools. So let's get past knocking holes in suggestions and instead
figure out the scope of what we are talking about - so we can put some
of these common-sense safeguards in place.
To harden AUR we have to eliminate the new user gets to adopt
packages and push changes without review - period. The immediacy
problem. That's the Achilles' heel that killed us.
After having been shot full of holes for suggesting tightening
anonymous account rules, the anonymity will be preserved. And,
admittedly, I've been brought around to understanding why that is
important for folks in places where state control of the internet and
identified misuse could cause problems.
To preserve the anonymous accounts, we then have to prevent what
happened by making AUR less attractive as a target. We have to
eliminate the immediacy problem.
To do that there has to be some period between account creation and
the time the user is able to adopt packages and push changes.
Additionally, there must be a review of the first (x number) or
commits within an (x month probationary period). (that can be done by
some of the proposed tools)
However, should those tools flag any commit as suspicious, there
must be human review. There is just no way around it. And, frankly,
that's a bit refreshing. This review should be the same that is
triggered when a member reports as suspicious commit as has been done
during the attack. The goal is to develop the tools to the point where
this review is manageable. Whether the same tools are applied to every
commit to AUR is a separate issue -- we are just focusing on the type
account creation that bit us.
Now none of this is 100% foolproof, it will not catch the much
lauded "infinitely patient attacker", nothing will. And the fact that
some infinitely patient attacker might out-wait any waiting period put
in place is not a valid argument for doing nothing.
So, a delay between new user account creation and adoption with push
privileges, and review of a first number or probation-period of
commits by the tools suggested with any flagged overflow queued for
human review. I see that as a bare minimum, but I'm open to other
ideas that may be better that eliminate the need.
That brings us back to the body-count - who's going to do it. If in
a non-attack, normal workflow, this looks like it is something that
would overload the current moderators, then we are going to need a
pool of AUR trusted users to help out. We will need to come up with a
"How to review suspicious flagged package checklist" to ensure
consistency and thoroughness and assign it to a pair of volunteers in
the pool to investigate. Assigning the work through gitlab is one way
to ensure we track and close every flagged issue and provide a
pipeline for feedback to improve the process.
Just judging by the suggestions on aur-general and on libera.chat,
there are more than enough of us around to do it. The
human-in-the-loop presents a challenge, so let's do the work to figure
out what it will take to make it so.
Part of the problem is there are only a handful of people that know
AUR, know the moderator resources available and are in a position to
know what the community will need to fill. That information isn't
transparent to most of us, which makes it hard to suggest fixes and
scope resources when the resources we have to work with are unclear.
I still think an RFC to collect the ideas and assign resources is
the best way to coordinate this effort. It is hit-or-miss whether the
current discussion is on aur-general, libera.chat, bbs.archlinux,
gitlab or elsewhere.
On the needed human front, I'll throw my hat in the ring and say I'm
willing to help out if a human review is needed and I'm certain most
who have participated in the discussions are willing to do the same.
What we need is coordination so we are not just sending to a
mailing-list hoping it gets to the right people..... If we clear that
issue up, we can turn all of this activity into progress.
Thanks to all that have shared ideas, the community members that
reported the malicious activity and the moderators that acted swiftly
on that to remedy the damage and delete accounts. Sorry this ended up
longer than I intended, but I want to see this effort succeed.
