Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

Post by newaccount74 » Mon, Jan 10, 2022, 1:12 PM UTC

heurisko wrote: post #762

notRobot wrote: post #758

Earlier quoted context omitted.

I do this solely because I don't like packages, I don't use them, and I don't want to maintain them for other people. To the people who want to use my code, it is recommended prominently in multiple places that they not blindly trust the code and actually inspect it before using it. The friction in this process is intended. The code I write is primarily for me. Other people can use it if they want to, and I hope it h…

> it is recommended prominently in multiple places that they not blindly trust the code and actually inspect it before using it. The friction in this process is intended. There is nothing inherent in using packages that means you have to blindly trust the code, neither does providing a package mean you have to accept any more responsibility over providing a .php file (packages are just .php files with a few metadata…

Post by Chris2048 » Mon, Jan 10, 2022, 1:13 PM UTC

marcus_holmes wrote: post #768

jopsen wrote: post #750

Earlier quoted context omitted.

If we are willing to admit that repositories like npm are useful, what can be done to mitigate these issues? Is there some tooling we can build?

Pay the maintainers of the libraries you use, and have a contract with them that states their obligation to maintain and support your use of their code

Post by Chris2048 » Mon, Jan 10, 2022, 1:15 PM UTC

jopsen wrote: post #750

lrvick wrote: post #722

Earlier quoted context omitted.

Security auditor here. Every time I see a client importing unsigned code with no evidence anyone they trust has reviewed it, I flag it as a supply chain attack vector in their audit and recommend mitigations. Some roll their eyes, but I will continue to defend it is a serious issue almost every company has, particularly since I have exploited this multiple times to prove a point by buying a lapsed domain name that mi…

If we are willing to admit that repositories like npm are useful, what can be done to mitigate these issues? Is there some tooling we can build?

Post by Aeolun » Mon, Jan 10, 2022, 1:21 PM UTC

brundolf wrote: post #383

hsbauauvhabzb wrote: post #361

Earlier quoted context omitted.

Does updating it with junk take any longer?

Published versions are immutable, you can only submit a new patch with a new version number. It's common for dependencies to be pinned to a minor version (getting patches automatically), however if you use a package-lock.json, as is the default/best-practice, I believe you should be guarded from any surprise patches. You would discover a change like the one in the OP when you manually ran `npm update` on your dev mac…

Post by Chris2048 » Mon, Jan 10, 2022, 1:21 PM UTC

pinum wrote: post #426

brundolf wrote: post #383

Earlier quoted context omitted.

Published versions are immutable, you can only submit a new patch with a new version number. It's common for dependencies to be pinned to a minor version (getting patches automatically), however if you use a package-lock.json, as is the default/best-practice, I believe you should be guarded from any surprise patches. You would discover a change like the one in the OP when you manually ran `npm update` on your dev mac…

>You would discover a change like the one in the OP when you manually ran `npm update` on your dev machine, so it should get nowhere near production. Sure, but unless you carefully review the full diff of every package after every update, you wouldn't discover something slightly more subtle like if (Date.now() > 1648771200000) { require('child_process').exec("rm -rf ~") }