> You have to review the source of every PKGBUILD from the AUR you install, full stop
I don't really think this is a solution- the usual workflow for these attacks has been to hide your payload in some dependency. This one is somewhat unusual in that it's just a very lazy `npm install` in the pkgbuild. Pretty much every package repository even outside of AUR has this issue now, and it's not really viable to audit the entire dep chain by hand. Mind you, I don't have a solution either.
> I don't really think this is a solution- the usual workflow for these attacks has been to hide your payload in some dependency. This one is somewhat unusual in that it's just a very lazy `npm install` in the pkgbuild. Pretty much every package repository even outside of AUR has this issue now, and it's not really viable to audit the entire dep chain by hand. Mind you, I don't have a solution either.
This is different though. The attackers of the AUR don't have access to do anything to upstream and any malicious dependency they add would have to be either 1) already built as an official package or 2) also taken from the AUR... in which case the person building it would need to audit the dependency as well.
So you have two "AUR hygiene" principals at play: One, know what software you're even installing, and Two, know that the PKGBUILD does what it says on the tin. If you neglect either of these and YOLO then it's kind of on you.
Arch users should really know that the AUR is something to approach with a massive amount of caution. It's better than "curl bash" from some rando web site, but that's only due to the fact that you can easily audit and diff the payload of the install recipe yourself.
> it's not really viable to audit the entire dep chain by hand
When you `makepkg -s`, makepkg will get the dependencies it can from the vetted and maintained pacman repos. Only the dependencies that are not present there would have to be obtained from the AUR the same way as the package you're currently reviewing: git clone, manually review, makepkg, etc.
Having dependencies in the AUR is not that common in my experience. I think I've had rarely 1 or 2 deps in the AUR; maybe once or twice I had like 6 deps. It can happen, and it's a bit of a chore, but it can be done.
This is an "in addition to" problem though, not an "instead of" problem.
Having code reviewed the PKGBUILD doesn't mean the upstream software is safe to use, having reviewed the upstream software and it's dependency tree doesn't mean the PKGBUILD is safe to use.
Also have realized at some point that reviewing the PKGBUILD and code in github repo still doesn't check whether the github release files are compromised.
Build it yourself or bust