> You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates.

But isn’t that also the case for every browser extension, VSCode extension, nuget package, Cargo crate, python package, npm package, etc? (Unless you are running them somewhere without internet access or without access to anything you don’t mind being public?)

Maybe it’s not the case for aur, but the others could theoretically be improved with better permissions, sandboxing, etc. I guess browser extensions basically have those options, even if no “normal” users use them.

Unfortunately 99.99% of people can’t or don’t have the time to review everything. :-(

I guess distro packages where there are trusted maintainers, or places like the iOS App Store where there are both permissions and somewhat of a review process, are the safest.

▲

codemac an hour ago | parent | next [-]

> isn’t that also the case for every browser extension, VSCode extension, nuget package, Cargo crate, python package, npm package

Yes, and all of those have supply chain hacks in them, and have happened within the last year? In this specific case, it's a malicious npm package being installed with official npm tooling in the PKGBUILD.

The advantage to the AUR is just that you can reasonably review every PKGBUILD for what you're installing, they are very simple bash scripts. It'd be great if more people would donate resources to help verify and validate AUR scripts, but the AUR specifically exists for packages that the trusted users and devs of arch don't have time to personally maintain.

	▲	DavideNL 4 minutes ago \| parent [-]
		Curious, in this specific case: if people DID review the PKGBUILD, what exactly would they recognize to spot these packages were compromised ?

▲

Tharre an hour ago | parent | prev [-]

Some of these have corporate backing and/or better funding and thus more manpower to review things, but yeah it essentially applies to all of them. It's no accident that there's news about a new npm package being compromised every other week.

Ultimately, the way we're doing permissions on the OS level is fundamentally broken on desktop OSes, and we're increasingly feeling the effects of that. Ideally everything should be sandboxed by default, and only given access to it's own files, instead of everything the user has.

But we're a long way away from that, and that's not something a single project could enforce.