Hello, I've been an Arch user for a couple of years now, and using the AUR since day 1. As we all know, in the past months the AUR as been compromised a few times, and though I see things are changing (new AURweb, better security around orphaned packages, etc), I think we might be missing a centralized definition of the different layers, and who is in control of the bytes there.
1. Upstream project: upstream devs
2. AUR platform (aurweb, git, SSH, accounts): DevOps
3. Maintainership transfer: AUR Users, gated by TUs and Devops
4. The PKGBUILD author: a stranger
5. Reactive triage: TUs and reporting users
6. Pre-install diff review: the end user
7. Build isolation: the user, opt-in (devtools, nspawn)
8. Install and runtime: root
Full coverage of layer 1 is not achievable at upstream's scale. Layer 5 works
but is slow by nature, and we are still finding compromised packages from the
earlier waves. Layer 6 is the one I keep coming back to: it is the step users
are told to own ("read the PKGBUILD"), it is correct, and it is the one most
people skip - increasingly so, as the user base shifts away from developers due
to Arch-based systems like CachyOS.
I've seen the suggestion to involve private companies (I'm against that) and to
rely on automated systems (I'm wary of that too). My concern is not automation
as such, it is anything that turns a signal into a verdict and removes the
decision from the user. A tool can help here without doing that.
To that end I've been building TrustSight, a PKGBUILD update vetting tool:
https://github.com/emiliano-go/trustsight/
It is deliberately an instrument, not a judge. It reads AUR PKGBUILD diffs,
applies published detection rules, and reports both what it found and what it
could not examine. It is deterministic, runs entirely locally, never builds or
executes a PKGBUILD, never fetches a URL the package declares, and produces no
verdict - the output is input to ahuman decision. A quiet result explicitly
does not mean "safe". The goal is to make the mandatory diff review faster and
to tell users exactly what to look for (unresolved variables, changed
upstreams, and so on).
That is also the difference from the automated systems: the ruleset is
published and auditable, the result is reproducible and carries its own
coverage gaps, and it never authorizes an update. A human still decides. The
tool just makes that decision cheaper. Docs and the full threat model are at
https://trustsight.org/ and in the repo.
One thing worth flagging while I'm here: a copy of TrustSight was uploaded to
the AUR by someone else, without my involvement. I'll file a deletion request.
A tool that reviews AUR packages should not be
distributed through the channel it reviews - it is circular, and in this case
the upload is unaffiliated and therefore itself an unreviewed package.
I'd welcome feedback, especially on the layer model above and on where a tool
like this should stop.
I invite you to read the full security model, or the docs.
> Emiliano Gandini Outeda
> https://emiliano-go.com
> [email protected]
publickey - [email protected] - 0xF759D6D4.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
