aur-sleuth

What it checks

aur-sleuth is an LLM-powered tool that detects supply-chain attacks in Arch User Repository packages. The threat it targets is malicious code injected into the packaging by a maintainer, by a hijacked maintainer account, or by a swapped upstream artifact. It answers one narrow question: is it safe to run makepkg on this package and install the result? The author is explicit about limits. It is not a general security auditor and not a vulnerability scanner. It does not judge whether the upstream application itself is well written or trustworthy with your data. The audit covers all of the files listed in the source array of the PKGBUILD, along with any other files from the package sources that the auditing LLM decides are interesting. The motivation section points to real cases of subtly malicious AUR packages and argues that open source only delivers its security promise when people can actually audit what they run, something that is hard to do by hand at scale. The README frames the tool as fulfilling the promise of open source, the ability to read the code you run, by making that reading automatic and repeatable. It is a focused instrument rather than a broad defense, and the author is careful to say so up front.

Running the audit

You can run aur-sleuth standalone by passing a package name, which audits it without building or installing. A separate shell wrapper called makepkg-with-sleuthing integrates the check with makepkg. With yay you run a makepkg flag followed by the package name, so the package builds and installs only after it passes the audit. For a local package in a directory that contains a PKGBUILD, the wrapper supports an install flag. You can also set aur-sleuth as the default makepkg for yay using a save flag, after which a normal yay run audits installed or updated packages automatically. If you would rather see results without blocking the install, set an environment variable named AUDIT_FAILURE_FATAL to false. The README warns this matters because false-positive rates depend heavily on the model you use, so a non-fatal mode is useful while you tune expectations. The wrapper design means the audit sits in the normal install path rather than as a separate step you might forget, which is the point: security that runs because it is wired into yay, not because you remember to invoke it. The examples in the README cover the standalone, yay, and local-directory cases so you can pick the one matching your habit.

Results and dashboard

Audit results are browsable on a static dashboard at mgalgs.io/aur-sleuth, which is generated from the audit-reports branch of the repository. The README links a demo that shows the tool catching the tricks in a known malicious google-chrome-stable package that circulated on the AUR. There is also a security considerations section that explains what the tool can and cannot defend against, worth reading before you rely on it. Installation is offered from the AUR itself, which is a nice touch given the tool's subject. The project is written in Shell, and while no license is stated in the metadata provided, the code lives in a public repository where you can inspect the wrapper and the audit logic directly. For Arch users who install from the AUR regularly, aur-sleuth turns a manual trust decision into a repeatable, logged step. The dashboard adds a shared memory of past audits, so a package that failed for one person is visible to others who reach the site. That shared view is what moves the tool from a personal check to something closer to community watch, even though the underlying judgments still come from whichever model each user runs. The shared history makes the tool more useful the more people run it.

Editorial conclusion

aur-sleuth is written in Shell, and its audit dashboard is published from the audit-reports branch of the repository.