An Arch fleet inventory model for third-party package risk
The yyay incident asks a basic inventory question: which machines are allowed to build or install software from a community recipe, and who approved the exact recipe that ran? A list of installed package names is a start, but it does not capture the maintainer, build source, install script, or execution context that made this case dangerous.
Arch fleets need a data model that can answer those questions without collecting a mass of unrelated telemetry. The model should connect a package approval to the evidence used to grant it and to the hosts where it is allowed to run. It should also make removal and investigation possible when a public warning appears.
Record package identity and provenance
For every third-party package, record the package name, source class, upstream URL, AUR maintainer, approved commit, local patch set, package version, artifact hash, and the owner who approved it. An AUR recipe should have a distinct source class from an official repository package even if both eventually produce the same executable.
The PKGBUILD(5) manual describes an install script as a separately named local file. The inventory should therefore include the install script and its hash or reviewed commit alongside the source archive. If the package can download code during install or upgrade, record that behavior and the approval exception.
The record should also include the hosts or host groups allowed to use the package. A developer laptop, a disposable build runner, and a production server have different risk. The approval should say where the recipe may be built and where the resulting artifact may be installed.
Capture the execution boundary
An approval record is incomplete without a statement about privileges and isolation. Was the package built on a clean host? Did the build environment contain SSH keys or package-publishing tokens? Did installation run as root? Which network destinations were reachable? What evidence shows that the install script did not perform an unexpected action?
These fields turn a policy document into a testable claim. The mail-list scan of yyay found a top-level install-script command that fetched remote content and could execute as root. A review that recorded only "source matches upstream" would have missed the execution boundary.
The makepkg(8) and pacman(8) manuals help define the workflow, but the inventory needs the organization's own evidence. It should distinguish a recipe that was merely retrieved from one that was built, tested, installed, and later upgraded. Those states carry different exposure.
Make exceptions expire
Permanent AUR approvals gradually become invisible infrastructure. Give each exception an owner, a reason, a scope, and an expiry. On renewal, compare the current recipe with the approved commit, check the maintainer identity, review install and upgrade behavior, and confirm that the hosts still need the package.
Use a small set of allowed package sources. A helper or dependency that arrives through a local script should be visible in the same inventory as the application it supports. If the policy allows users to search for community packages directly, provide an approved path and teach them to compare the exact package name, maintainer, and source. Popularity is not an approval record.
Removal needs the same discipline. When a package is blocked, record why, which hosts had it, whether it was ever installed, and what replacement path exists. Do not delete the evidence that would let a responder determine whether a root script ran.
Connect inventory to response
An incident such as yyay should be resolvable with a few queries: which hosts have the package, which users can build from the AUR, which credentials were present on those hosts, and which approved recipes have an install script with network access. If those questions require a manual search across spreadsheets, the inventory is not operational.
Add package changes to the same review process used for other third-party dependencies. New install scripts, maintainer changes, source-host changes, and lines that pipe remote content into an interpreter should produce a review task. The alert needs an owner who can block installation and a way to verify that blocked hosts did not retain the artifact.
Incident response also needs a fast path for uncertain execution. A host that ran a root scriptlet should be isolated, its credentials scoped, and its data preserved. A disposable build environment can be destroyed and recreated. A production host usually needs a rebuild decision and a credential rotation record.
Pair internal inventory with external visibility
ZoomEye can add a public view of assets that mention the AUR. The query http.body="Arch User Repository" returned 268 public assets in an all-data observation on 7 November 2026. That number describes public pages, not fleet installations or confirmed compromise.
Use the result to find forgotten developer documentation, public portals, or vendor pages that may describe an AUR workflow. Assign the result to an owner and ask for the internal inventory. The external observation can reveal where a practice is advertised. It cannot replace package records or endpoint evidence.
The combined model is straightforward: public visibility identifies the conversation, the package inventory identifies the software path, and host evidence establishes execution. A mature fleet keeps all three linked to an owner and a review date.
Top comments (1)
The link from approval to artifact hash is the operational hinge. I’d also record the environment identity that produced that hash—base image or package database snapshot, builder identity, and build timestamp—so investigators can distinguish “same recipe” from “same reproducible artifact.” That turns an exception review into a chain of evidence rather than a collection of package metadata.