It isn't guaranteed that the list is conclusive.
Always check PKGBUILD and sources, AUR is not to be trusted for the most part. I'm actually more surprised that such compromise hasn't happened earlier.
Always check PKGBUILD and sources, AUR is not to be trusted for the most part. I'm actually more surprised that such compromise hasn't happened earlier.
it happens all the time
Just not always on this scale and doesn't always end up on HN.
Similar to how you don't see every npm supply chain attack or malicious github action or similar on HN.
In general you _have to_ manually review every PKGBUILD update by hand (by diff). Everything else is neglect IMHO. Luckily for most packages this is reasonably doable, IFF you trust the upstream sources they fetch from. (As in: Most packages are a small amount of glue between pacman and a upstream source.)
As consequence AUR packages with AUR dependencies are in general "uh..., lets not do it" cases for me, as on one hand the review overhead can be a pain and on the other hand it's easy to make a mistake overlooking a change in AUR dependencies.
Still the policy which allows relatively easy adoption of orphaned packages is IMHO a problem. A adoption should be treated as a new package which just happen to have the same name. (It can be fine to not have that if arch maintainers "bless" the adoption, but IMHO that would only matter for a view very widely used packages which are candidates to be included in the official repo but aren't for e.g. license reasons.)
> Giving opencode access to bash and malicious input is not very far from piping it right into bash.
It is very far, obviously. If you have N AUR packages, it needs to send `e` and `:q` N times using the pty tool. You can have it ask you for permission everytime and approve (2N times) (note that when you use yay, you have to press enter N times anyway! so this is just N extra enters but in the opencode UI) or you can even automate an interceptor that checks that it only sends e and :q and no other strings.
Don't forgot to also check the applied patch files. Many AUR builds include custom patches to make something work, making this a convenient way add something malicious into the build. An extreme example for patches is ventoy's 1355 line long PKGFILE [0] sourcing lots of patches both from external domains as well from the git server on aur.archlinux.org itself.
[0]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vento...
But in general I would think 4 times about installing any AUR package no longer reasonable reviewable in the parts not either in official packages or the upstream source (including patches, dependencies, etc.).
Sometimes throwing something into an untrusted OCI image you run in a VM (instead of lightweight containers) is just the better option... sadly, also often still painful to setup.
This is like the 3rd or 4th time. It's been ongoing and persistent for the last 2 years with frequent AUR downtime as a result.
The AUR should be deprecated in its current state, simply can't be trusted and is a blemish on an otherwise great distro.