Following up on the automated scanning idea, a completely new package has no history, so a diff check wouldn't work. The system would have to shift from checking changes to inspecting the code for absolute risk factors instead. This means looking for things like dynamic downloads inside the build functions (using curl or wget instead of the source array) or obfuscated blocks.
To help move this forward practically, I have an open-source security tool written in Rust called Oversight that focuses on this type of static analysis. It parses shell scripts, flags suspicious execution patterns, and calculates a risk score based on what the code is attempting to do. Since a PKGBUILD is fundamentally just a Bash script, the underlying logic is structurally very close to what is needed here. The tool is a personal project to learn the language (with LLM assistance during development) and needs tailoring to fit the AUR's specific architecture, but the core engine works. If any developers on the list want to look at the logic, fork it, or help adapt it into a fast scanner for the repository pipeline, the code is up on GitHub: https://github.com/Rakosn1cek/oversight Best regards, Lukas Grumlik Sent using From: David C Rankin <[email protected]> To: <[email protected]> Date: Wed, 17 Jun 2026 07:37:19 +0100 Subject: Re: A possible way to secure the AUR orphaned packages from being easy target for malicious scripts. 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. -- David C. Rankin, J.D.,P.E.
