Hacker News Reader

Comment by chipotle_coyote | Hacker News Reader

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

View on HN

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

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.

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.

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

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

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

No, 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.

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

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

Reply on news.ycombinator.com