I know everyone say “use at your own risk,” but in practice that’s not how regular users are using npm, PyPi, AUR, Cargo and such. They’re not manually reviewing every little update to a deluge of dependencies.
…I’m guilty of this.
I don’t know a perfect solution, but it feels like this can’t go on, as package hijacking is en vogue now.
Containerization to contain damage is good, I guess, but still.
I know everyone say “use at your own risk,” but in practice that’s not how regular users are using npm, PyPi, AUR, Cargo and such.
This won’t work any more in the future. Linux is too big and the Internet, or the world as a whole has become an too unfriendly place.
It is like that I once lived in a small village in Belgium in a shared house and I loved that we never needed to lock the door, even when we were away. But you can’t do that in a big city.
Well, as a Linux user, you can’t run untrusted code from strangers. Which is what AUR and PyPy is. As a normal user, you should run only checked code from your distribution. And when you develop software, you need to check the credentials and signatures of upstream software and their developers.
Good luck with checking all dependencies as a developer, bonus points for JavaScript. You’ve just become a 98% less effective. But seriously, how would you check everything? And if you stumble upon malicious code, would you even recognize it?
Some of this can be alleviated by not using the latest version of everything. Granted that’s not always possible, say if updating to fix a vulnerability or bug fix. Stable distros will have some insulation from this at least since there will be more time to discover the issue.
That’s a failed analogy. The 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 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.
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.
Which is the case with Cargo.lock. You can even lock the toolchain itself with rust-toolchain.toml. There a reason why uv developers knew what good practices to implement in their quest to fix python tooling 😉.
one update or maintainer change can silently compromise the whole chain.
That’s another failed analogy. There is no orphaning and total randos taking over in crates.io (same for npm/pypi I would assume). The owner himself must hand over or give permissions to a specific person/account. That’s another implicit chain of trust that doesn’t exist in AUR.
Nothing is fail-proof of course, as the xz incident showed.
I don’t follow npm incidents closely, but the cases I saw involved the legit owners/maintainers themselves, who were either compromised, or genuinely doing the compromising themselves 🤣.
Arch is a single rolling release
This is largely irrelevant to the discussion.
hit Rust and PyPi in a similar way.
It won’t be similar for the all the reasons stated.
And a strict “version locking” ethos can lead to security problems down the line, too.
That’s where language implementation compat guarantees, audit tooling (cargo audit et al) and good tooling in general, together with a good semver story in the ecosystem itself, ALL come together to make this largely not a problem.
This works well enough in the crates.io ecosystem.
From what I hear, npm has the audit tooling part covered. But it’s failure in all the other aspects that’s making the situation unattainable.
As with pypi, there is the pain point of python minor release updates breaking shit all the time. But beyond that, I don’t know enough to give an informed take (other than that uv is a blessing for those who don’t want to get their hands really dirty in that ecosystem).
And again, these details and differences are very relevant.
It’s easy to sneak some malware downloader into a long Rust dependency chain, even if it’s technically all open code.
As of now, the number of successful supply chain attacks (where a chain of real dependants exists) in the crates.io system is ZERO.
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.
I know everyone say “use at your own risk,” but in practice that’s not how regular users are using npm, PyPi, AUR, Cargo and such. They’re not manually reviewing every little update to a deluge of dependencies.
…I’m guilty of this.
I don’t know a perfect solution, but it feels like this can’t go on, as package hijacking is en vogue now.
Containerization to contain damage is good, I guess, but still.
This won’t work any more in the future. Linux is too big and the Internet, or the world as a whole has become an too unfriendly place.
It is like that I once lived in a small village in Belgium in a shared house and I loved that we never needed to lock the door, even when we were away. But you can’t do that in a big city.
Well, as a Linux user, you can’t run untrusted code from strangers. Which is what AUR and PyPy is. As a normal user, you should run only checked code from your distribution. And when you develop software, you need to check the credentials and signatures of upstream software and their developers.
Good luck with checking all dependencies as a developer, bonus points for JavaScript. You’ve just become a 98% less effective. But seriously, how would you check everything? And if you stumble upon malicious code, would you even recognize it?
Nobody sane should be installing js code in their systems. Nor having node or even npm installed.
Yes I know well that JavaScript development practices are unsustainable.
And at some point, chickens will come home to roost.
For my part, I focus on minimalist, well defined systems, both as a user and developer. And trust where it is reasonable - not by default.
Exactly, I wouldn’t know what I was looking at probably. We don’t really learn malicious programming at uni.
Some of this can be alleviated by not using the latest version of everything. Granted that’s not always possible, say if updating to fix a vulnerability or bug fix. Stable distros will have some insulation from this at least since there will be more time to discover the issue.
That’s a failed analogy. The 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 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.
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.
Which is the case with
Cargo.lock. You can even lock the toolchain itself withrust-toolchain.toml. There a reason whyuvdevelopers knew what good practices to implement in their quest to fix python tooling 😉.That’s another failed analogy. There is no orphaning and total randos taking over in crates.io (same for npm/pypi I would assume). The owner himself must hand over or give permissions to a specific person/account. That’s another implicit chain of trust that doesn’t exist in AUR.
Nothing is fail-proof of course, as the
xzincident showed.I don’t follow npm incidents closely, but the cases I saw involved the legit owners/maintainers themselves, who were either compromised, or genuinely doing the compromising themselves 🤣.
This is largely irrelevant to the discussion.
It won’t be similar for the all the reasons stated.
That’s where language implementation compat guarantees, audit tooling (
cargo auditet al) and good tooling in general, together with a good semver story in the ecosystem itself, ALL come together to make this largely not a problem.This works well enough in the
crates.ioecosystem.From what I hear,
npmhas the audit tooling part covered. But it’s failure in all the other aspects that’s making the situation unattainable.As with
pypi, there is the pain point of python minor release updates breaking shit all the time. But beyond that, I don’t know enough to give an informed take (other than thatuvis a blessing for those who don’t want to get their hands really dirty in that ecosystem).And again, these details and differences are very relevant.
As of now, the number of successful supply chain attacks (where a chain of real dependants exists) in the
crates.iosystem is ZERO.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.