We definitely won't be using any of the vibe-coded AUR scanners that have popped up on the list, trust me. I find it just as annoying as you do.
Campbell On June 17, 2026 8:44:50 AM EDT, Atte <[email protected]> wrote: >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. >>
