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 some pypi packages do actually distribute binaries (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.

[–] HaraldvonBlauzahn@feddit.org 2 points 3 weeks ago (1 children)

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.

But still weaker than Debian packages, for example, while on the other hand the number of dependencies now often goes into the hundreds.

[–] BB_C@programming.dev 1 points 3 weeks ago

still weaker than Debian

There is a lot of myths that surround what distros actually do, can do, and have the resources to do. We had this discussion in one of the two threads I linked.

[–] brucethemoose@lemmy.world 1 points 3 weeks ago

there is at least an implicit tree of trust, with each dependant in a dependency tree doing at least some minimal vetting of dependencies.

Depends.

Unless every single dependency is version locked, one update or maintainer change can silently compromise the whole chain. Obviously this is a problem for AUR (as Arch is a single rolling release), but it can hit Rust and PyPi in a similar way.

And a strict “version locking” ethos can lead to security problems down the line, too.

Also, in this case, they exploited PKGBuild an npm, yes. But I think that was just out of convenience. It’s easy to sneak some malware downloader into a long Rust dependency chain, even if it’s technically all open code.