undefined | Better HN

0 pointschipotle_coyote10y ago0 comments

I think the article's thesis is essentially that every dependency your project pulls in -- which includes all the dependencies your dependencies pull in -- is a point of potential failure. I understand the "don't re-invent the wheel" defense, but the Node/JavaScript ecosystem tacitly encourages its users to build vehicles by chaining together dozens of pre-made wheels, all of which depend on more wheels, and each and every one of those wheels has a small but non-zero chance of exploding the next time you type "npm update."

(And, y'know, maybe it's because I'm not a JS programmer, but the notion of looking for a module to implement a string padding function would never have even occurred to me.)

0 comments

nv-vn10y ago

Worse yet, a backdoor or legitimate bug in any of these module could leave huge exploits in the entire Node.js ecosystem.

lmm10y ago

A backdoor or legitimate bug in any line of custom code could leave huge exploits in your system. A widely-used published module is likely to be much more reliable, at least on average.

moistgorilla10y ago

Except when you are using a library like boost or pandas you know the people behind it know what they are doing. When you are importing from a thousand different package authors any one of those people could be incompetent and/or malicious and screw up your entire code base.

smokeyj10y ago

Worse yet, the OS is compromised. This is why I hand roll all my encryption libraries. /s

cyphar10y ago

Riiiight. Because cryptography is identical to an 12-line string padding function.

1 more reply

joantune10y ago

The problem is not that, the problem is depending on unreleased versions, instead of simply depending on the version that was written when u wrote your code.

a Git submodule like approach would be much better

j / k navigate · click thread line to collapse