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?
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.
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?
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.