Reviewing the Arch User Repository with AI — Cretezy Aug 2, 2026 Developer ToolsArch LinuxAI<br>Reviewing the Arch User Repository with AI<br>The Arch User Repository is one of the reasons I<br>like using Arch Linux. If a piece of software exists, there is a good chance<br>someone has already written a PKGBUILD for it.

That convenience comes with a specific trust model: a PKGBUILD is shell code<br>written by another user, and installing a package means running it. In June<br>2026, that stopped being an abstract warning.

On June 12, Arch Linux published an<br>official notice about an active malicious-packages<br>incident,<br>describing a high volume of malicious package adoptions and updates. The team<br>was removing malicious commits and trying to prevent new ones while account<br>creation, package updates, and package adoption were restricted.

It was not a one-off incident. On July 31,<br>Phoronix reported another wave of malicious packages and that Arch had halted<br>package adoptions.<br>The previous campaign had affected more than 1,500 packages, and the new wave<br>already included dozens more. Arch disabled adoptions while the team handled<br>the influx and again asked users to stay vigilant.

Arch’s advice was direct: review every PKGBUILD and install-script change<br>when updating AUR packages, especially while the incident was active.

Those incidents are the specific reason I started this project. The problem was<br>not limited to an obviously fake new package nobody had heard of. A familiar<br>or orphaned package could be adopted, receive a malicious update, and arrive<br>through the same update workflow as a boring version bump.

Reading every update by hand does not scale very well, but reducing the answer<br>to “an AI said it was safe” is not useful either. I wanted another review layer<br>for exactly these changes: automatically inspect current package updates,<br>preserve exactly what was reviewed, and make the evidence easy to inspect<br>afterward.

Most AUR changes are still completely ordinary version bumps. Occasionally a<br>download moves to another domain, a repository changes owners, or a new command<br>appears in a packaging step. Those are the changes I want to notice before<br>installing an update.

That became<br>aur_ai_security, a small Rust<br>service that indexes AUR package versions, uses AI to review each package<br>update’s Git diff, and serves the results in a web interface.

You can browse the current results in the<br>live demo.

The project is still early, but the complete index-to-review flow works. This<br>post goes over what it records, how a check works, and the parts that took more<br>iteration than I expected.

The problem with reviewing only a PKGBUILD

Looking at the current PKGBUILD is a useful start, but it loses the most<br>important context: what changed?

A package downloading a binary from its established upstream GitHub release is<br>normal. The same package suddenly downloading from an unrelated domain is much<br>more interesting. A new checksum is expected when the version changes. A new<br>repository owner or delivery mechanism deserves attention even if the shell<br>code still looks clean.

The AUR already stores each package base in Git, so the useful unit of review<br>is not just a file. It is a package version, its repository commit, the full<br>PKGBUILD, and the diff that introduced it.

How it works

aur_ai_security has three main parts: the indexer, the AI checker, and the web<br>interface used to catalog and review the results.

Indexer

The update-index command downloads the AUR metadata index and appends newly<br>seen package versions to SQLite:

cargo run -p aur_ai_security -- update-index<br>Package metadata is scoped to package name and version. The index keeps the AUR<br>package and package-base IDs, submitter, last-modified time, snapshot path, and<br>popularity. Versions present in the latest index are marked current, while old<br>rows remain available for historical checks.

The package index and check results are currently stored in a SQLite database<br>shared by the CLI and website.

Checker

The check command selects current versions that have not already been checked<br>with the chosen provider and model. It can be limited to exact package names or<br>to packages modified after a timestamp:

cargo run -p aur_ai_security -- check \<br>--provider codex \<br>--model gpt-5.6-luna \<br>--since 24h \<br>--filter netcatty-bin zed-preview-bin<br>For each selected package, the checker:

clones its AUR Git repository;

records the current commit;

reads the complete PKGBUILD;

builds a commit diff with PKGBUILD first, followed by the other changed<br>files;

sends that context to the selected AI provider;

stores the verdict, explanation, source, diff, commit, provider, and model.

The project uses Rig for its AI agent<br>loop, which lets it support multiple providers without tying the checker to one<br>API. OpenAI, Anthropic, and OpenRouter are currently supported. The agent has a<br>single read_file tool so it can inspect other files in the cloned repository<br>when the diff needs more context.

It also...