That’s a failed analogy. AUR is an end-user build-script repo, not a source/binary/source+binary repo for both devs and sometimes users.

If you e.g. install a CLI tool via cargo, there is at least an implicit tree of trust, with each dependant in a dependency tree doing at least some minimal vetting of dependencies. And the source is all there anyway (barring exceptions like build.rs pulling code or the indirection of proc macros).

The same applies to npm and pypi, although there is no distinction between code and binary given the scripting nature of the languages. but there are binaries shipped with by some pypi packages (e.g. C/C++ compiled libraries). Don’t know about npm.

But, if I’m not mistaken, the py/js tooling wasn’t always there for stuff like full pinning of dep versions like cargo, and that’s a very important technical detail.

With the AUR, there is no trust tree. And often no fixed code (or binaries) to look at (e.g. *-git packages). So the feasibility of doing any sort of global in-tree checking/vetting is not there. On the other hand, source repos are responsible for removing, or at least flagging, malware or otherwise harmful packages once that becomes known.

Incidentally, I commented on both AUR security and cargo trust here and here. So, I will stop blabbing.