{"slug": "reviewing-the-arch-user-repository-with-ai", "title": "Reviewing the Arch User Repository with AI", "summary": "Arch Linux faced two waves of malicious package attacks in the Arch User Repository (AUR) in 2026, affecting more than 1,500 packages in the first wave and dozens more in the second, prompting the distribution to restrict account creation, package updates, and adoptions. In response, developer Cretezy created aur_ai_security, a Rust service that indexes AUR package versions, uses AI to review each update's Git diff, and serves results via a web interface, aiming to provide an additional review layer for AUR package updates.", "body_md": "# Reviewing the Arch User Repository with AI\n\nThe [Arch User Repository](https://aur.archlinux.org/) is one of the reasons I\nlike using Arch Linux. If a piece of software exists, there is a good chance\nsomeone has already written a `PKGBUILD`\n\nfor it.\n\nThat convenience comes with a specific trust model: a `PKGBUILD`\n\nis shell code\nwritten by another user, and installing a package means running it. In June\n2026, that stopped being an abstract warning.\n\nOn June 12, Arch Linux published an\n[official notice about an active malicious-packages\nincident](https://archlinux.org/news/active-aur-malicious-packages-incident/),\ndescribing a high volume of malicious package adoptions and updates. The team\nwas removing malicious commits and trying to prevent new ones while account\ncreation, package updates, and package adoption were restricted.\n\nIt was not a one-off incident. On July 31,\n[Phoronix reported another wave of malicious packages and that Arch had halted\npackage adoptions](https://www.phoronix.com/news/Arch-Linux-AUR-Adoptions-Halted).\nThe previous campaign had affected more than 1,500 packages, and the new wave\nalready included dozens more. Arch disabled adoptions while the team handled\nthe influx and again asked users to stay vigilant.\n\nArch’s advice was direct: review every `PKGBUILD`\n\nand install-script change\nwhen updating AUR packages, especially while the incident was active.\n\nThose incidents are the specific reason I started this project. The problem was not limited to an obviously fake new package nobody had heard of. A familiar or orphaned package could be adopted, receive a malicious update, and arrive through the same update workflow as a boring version bump.\n\nReading every update by hand does not scale very well, but reducing the answer to “an AI said it was safe” is not useful either. I wanted another review layer for exactly these changes: automatically inspect current package updates, preserve exactly what was reviewed, and make the evidence easy to inspect afterward.\n\nMost AUR changes are still completely ordinary version bumps. Occasionally a download moves to another domain, a repository changes owners, or a new command appears in a packaging step. Those are the changes I want to notice before installing an update.\n\nThat became\n[aur_ai_security](https://github.com/Cretezy/aur_ai_security), a small Rust\nservice that indexes AUR package versions, uses AI to review each package\nupdate’s Git diff, and serves the results in a web interface.\n\nYou can browse the current results in the\n[live demo](https://aur-security.cretezy.com).\n\nThe project is still early, but the complete index-to-review flow works. This post goes over what it records, how a check works, and the parts that took more iteration than I expected.\n\n## The problem with reviewing only a PKGBUILD\n\nLooking at the current `PKGBUILD`\n\nis a useful start, but it loses the most\nimportant context: what changed?\n\nA package downloading a binary from its established upstream GitHub release is normal. The same package suddenly downloading from an unrelated domain is much more interesting. A new checksum is expected when the version changes. A new repository owner or delivery mechanism deserves attention even if the shell code still looks clean.\n\nThe AUR already stores each package base in Git, so the useful unit of review\nis not just a file. It is a package version, its repository commit, the full\n`PKGBUILD`\n\n, and the diff that introduced it.\n\n## How it works\n\naur_ai_security has three main parts: the indexer, the AI checker, and the web interface used to catalog and review the results.\n\n### Indexer\n\nThe `update-index`\n\ncommand downloads the AUR metadata index and appends newly\nseen package versions to SQLite:\n\n```\ncargo run -p aur_ai_security -- update-index\n```\n\nPackage metadata is scoped to package name and version. The index keeps the AUR package and package-base IDs, submitter, last-modified time, snapshot path, and popularity. Versions present in the latest index are marked current, while old rows remain available for historical checks.\n\nThe package index and check results are currently stored in a SQLite database shared by the CLI and website.\n\n### Checker\n\nThe `check`\n\ncommand selects current versions that have not already been checked\nwith the chosen provider and model. It can be limited to exact package names or\nto packages modified after a timestamp:\n\n```\ncargo run -p aur_ai_security -- check \\\n  --provider codex \\\n  --model gpt-5.6-luna \\\n  --since 24h \\\n  --filter netcatty-bin zed-preview-bin\n```\n\nFor each selected package, the checker:\n\n- clones its AUR Git repository;\n- records the current commit;\n- reads the complete\n`PKGBUILD`\n\n; - builds a commit diff with\n`PKGBUILD`\n\nfirst, followed by the other changed files; - sends that context to the selected AI provider;\n- stores the verdict, explanation, source, diff, commit, provider, and model.\n\nThe project uses [Rig](https://github.com/0xPlaygrounds/rig) for its AI agent\nloop, which lets it support multiple providers without tying the checker to one\nAPI. OpenAI, Anthropic, and OpenRouter are currently supported. The agent has a\nsingle `read_file`\n\ntool so it can inspect other files in the cloned repository\nwhen the diff needs more context.\n\nIt also supports the Codex CLI, making it possible to run checks using a ChatGPT subscription instead of a separate API account. Codex runs from inside the cloned AUR repository with its shell tool and web search disabled.\n\n### Web\n\nThe web application is built with\n[Topcoat](https://github.com/tokio-rs/topcoat), a server-rendered Rust web\nframework, and Tailwind. It provides a searchable catalog of packages and\nchecks, with the source and diff behind each verdict available for review.\n\nIt reads the same SQLite database as the indexer and checker. Run it with:\n\n```\ntopcoat dev --package aur_ai_security_web\n```\n\nFrom there, packages can be searched and their latest assessment, check\nhistory, `PKGBUILD`\n\n, and update diff can be reviewed in the browser.\n\n## paru integration\n\nI also built two experimental branches in my `paru`\n\nfork to bring these checks\ninto the package installation workflow:\n\n[aur-ai-security-remote](https://github.com/Cretezy/paru/tree/aur-ai-security-remote)queries the hosted lookup API for existing assessments;[aur-ai-security-local](https://github.com/Cretezy/paru/tree/aur-ai-security-local)integrates the checker crate directly and runs the configured provider and model locally.\n\nBoth run after `paru`\n\ndownloads the AUR repositories and before it starts any\npre-build commands or package builds.\n\n## Safe is not a score\n\nEach check returns one of three verdicts:\n\n**safe** for ordinary packaging behavior;**suspicious** when a concrete change deserves human review;**dangerous** when there is strong evidence of malicious behavior.\n\nSuspicious and dangerous results require an explanation. Safe results do not need filler text saying that normal packaging looks normal.\n\nThe prompt treats a version and checksum bump from the same upstream source as ordinary, along with using a verified upstream binary to generate completions or metadata. Changes to domains, repository owners, or download mechanisms receive more attention.\n\nNone of these verdicts prove that a package is safe. A model can miss malicious behavior, produce false positives, or trust an upstream binary that has itself been compromised. The project stores the evidence behind each result so it can be inspected; it reviews packaging and supply-chain signals, not the contents of downloaded binaries.\n\n## What is next\n\nThe immediate work is running the checker continuously, adding notifications for dangerous results, and improving the prompt where the models are consistently too noisy or too trusting.\n\nThe goal is not to fully trust AI with deciding whether a package is safe. It is to use it as an early-warning layer: when an update is clearly malicious, I want to know quickly, see the exact source behind the verdict, and be able to address it before more users are affected.\n\n### Who am I?\n\nHello! My name is Cretezy and I am a software developer. I write about programming, personal projects, and more.\n\n[See more posts here.](/)", "url": "https://wpnews.pro/news/reviewing-the-arch-user-repository-with-ai", "canonical_source": "https://cretezy.com/2026/aur-ai-security/", "published_at": "2026-08-02 22:35:13+00:00", "updated_at": "2026-08-02 22:52:47.494917+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-tools", "developer-tools"], "entities": ["Arch Linux", "Arch User Repository", "aur_ai_security", "Cretezy", "Phoronix"], "alternates": {"html": "https://wpnews.pro/news/reviewing-the-arch-user-repository-with-ai", "markdown": "https://wpnews.pro/news/reviewing-the-arch-user-repository-with-ai.md", "text": "https://wpnews.pro/news/reviewing-the-arch-user-repository-with-ai.txt", "jsonld": "https://wpnews.pro/news/reviewing-the-arch-user-repository-with-ai.jsonld"}}