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.
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.
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.
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.
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.rspulling 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.
But still weaker than Debian packages, for example, while on the other hand the number of dependencies now often goes into the hundreds.
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.
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.