3 ms·
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
by chipotle_coyote 11y ago
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.)
- joantune 11y agoThe 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
- nv-vn 11y agoWorse yet, a backdoor or legitimate bug in any of these module could leave huge exploits in the entire Node.js ecosystem.
- smokeyj 11y agoWorse yet, the OS is compromised. This is why I hand roll all my encryption libraries. /s
- cyphar 11y agoRiiiight. Because cryptography is identical to an 12-line string padding function.
- fastball 11y agoI think that was smokeyj's point... the left-pad module is not going to have a "backdoor". nv-vn was creating a bit of a straw man, as no example or particular scenario in this article involved crypto.
- cyphar 11y agoNo, I disagree with smokeyj drawing a false parallel to encryption to try to justify why you should use an external dependency for 12 lines of code -- because "you should never roll your own crypto" is not applicable here.
- smokeyj 11y agoI just used crypto as a random example. I could have said "this is why I write my own input sanitation library" or "HTTP" library. My point is OSS is a collaborative effort by often times anonymous contributors. Therefore there will always be a risk of bugs or back doors - regardless of the distribution mechanism. In my opinion any criticism against micro packages is equally valid against large packages. There's no guarantee that a pull request would receive any more scrutiny than a external dependency. I mean look at heart bleed. Surely this doesn't mean that OSS is broken, but rather stricter security protocols should be in place. My 2 cents.
- lmm 11y agoA 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.
- moistgorilla 11y agoExcept 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.