7 ms·
The Node.js Ecosystem Is Chaotic and Insecure
- ahmetkun 8y agoWhat else is new?
- joshenglish 8y agoI think this article has seen HN a few times. https://news.ycombinator.com/item?id=16785396 https://news.ycombinator.com/item?id=16785396 https://news.ycombinator.com/item?id=16720011 https://news.ycombinator.com/item?id=16720011 https://news.ycombinator.com/item?id=16900545 https://news.ycombinator.com/item?id=16900545
- tokenizerrr 8y agoAll of these packages are created by Jon Schlinkert (https://github.com/jonschlinkert https://github.com/jonschlinkert). So if you want someone to blame...
- nailer 8y agohttps://github.com/jonschlinkert/is-odd/blob/master/index.js https://github.com/jonschlinkert/is-odd/blob/master/index.js Edit: the original code, even before the float handling, was was a perf optimisation: !!(~~i & 1); Nobody wants to see that in code unless it has a name. Maybe isOdd(). Maybe we should put it on GitHub to save others time. Sure beats copy-pasting from StackOverflow. Original: Did you think of handling floats in your home built isOdd implementation? Thankfully Jon (EDIT: or one of his contributors - doesn't change the point) did. And they added tests. The (flagged) article makes the staggering assumption that "we can't code" because we're not constantly reinventing the wheel. It talks about DRY being taken too far and talks about the functions being replaced as "one liners", when following a couple of links would show they're not. We can code, we're just coding on actual features, not rewriting the same poop.
- fenollp 8y agoNo he did not. https://github.com/jonschlinkert/is-odd/commit/dcc7eeff5be8f8190e2a7e63b76eae2992ad854f https://github.com/jonschlinkert/is-odd/commit/dcc7eeff5be8f...
- Klathmon 8y agoIsn't this evidence that the system is working? Because it's a package, a bug/oversight was found, and it was made more robust. I still wouldn't personally use `is-odd`, but isn't this proof that having something even this trivial as a package can have benefits?
- deleted 8y ago[deleted]
- samb1729 8y agoI find it interesting that the author added an `isInteger` dependency then went on to not use it.
- emodendroket 8y agoI'd say there are very few circumstances where you want to know if a number is odd but could plausibly have floats as an input.
- teliskr 8y agoThe universe is chaotic and insecure
- emodendroket 8y agoMaybe so, but that doesn't really address the concern.
- hungerstrike 8y agoThe article already addressed its own concerns: - Manually audit and lock down your dependencies. - Stop using nonsense dependencies, writing basic code is not reinventing the wheel.
- emodendroket 8y agoExcept that if your dependencies in turn use nonsense dependencies you're back to the problems.
- hungerstrike 8y agoShould we not count dependencies that are comprised of nonsense dependencies as nonsense themselves? In my opinion, fork it and fix it or stop using it. Also, warn others if you have the capacity.
- emodendroket 8y agoleft-pad broke non-trivial projects like Babel, as I recall.
- hungerstrike 8y agoYep, but there’s a big difference with how I treat dev and production dependencies. I wouldn’t use something nearly that large in production. Typically I look at a dependency to see if I could maintain it myself if necessary because it’s always risky to depend on a third-party.
- Klathmon 8y agoOh come on... > Nonsense dependencies are hard if not near impossible to manually audit due to the sheer number of them. Why do you need to audit dependencies you don't use? Don't use `is-odd`, nobody is forcing you too. If you aren't able to audit a 20 line file and determine it's worth to you, then maybe you shouldn't be installing any dependencies at all. The existence of garbage doesn't mean the system is broken, or that the ecosystem is "chaotic and insecure". It means that it's inclusive, and anyone can make a package, no matter how terrible you might think it is.
- johannes1234321 8y agoEven if I don't use is-odd directly one of my dependencies could, and another dependency of mine could use a different version, thus auditing once isn't enough. Of course I'd also have to audit an isOdd function if it were part of the dependent library directly.
- Klathmon 8y agoWhich is why js package managers have evolved to allow you to force a specific version if you want, and allow you to lock the version number of transitive dependencies. But at the end of the day, if a dependency that you want to use uses a poor dependency itself, then you should treat the whole thing as bad. Personally I'm happy that we have such widespread usage of packages in the js ecosystem, because it makes it easier for me to audit things. I can run a command and get the total number of dependencies that something I want to add comes with, the total number of lines of code it includes. I can have scanners that look for malicious packages and identify them quickly and easily (rather than searching the lines of code for a copy-pasted bug or security issue). Every time someone complains about there being "bad" packages on npm, it reads to me like someone complaining that shitty cars exist, and somehow the existence of shitty cars makes all cars bad...
- WkndTriathlete 8y agoThe problem is the number of dependencies and the number of people you are (implicitly) trusting by using those dependencies. It's an overwhelming engineering burden for those industries that are required to do that type of 3rd-party software auditing. When I use Java, I can trust - at an organizational level - large blocks of 3rd-party code (e.g. Spring, Java SDK) and may even be able to get them to assume some liability via agreement if their repositories for their libraries are breached and malicious code is injected. Additionally, because those libraries do so much, I require many fewer other 3rd party libraries that I'm required to audit. When I use JavaScript, I don't necessarily get those advantages. (NodeJS on the server side has an SDK, so this point does not apply there, so this is mostly directed at browser UI development.) Sure, we may use a framework like Angular, but I don't necessarily have confidence that Google has audited the 600+ transitive dependencies that the Angular team has pulled in. Because of this, I don't think that Google is prepared to assume liability in the face of malicious software injection, which means (in industries requiring audits) that we need to track down each one of those 600+ transitive dependencies and audit each one of them.
- vortico 8y agoDoesn't specifying a "version" in your package.json completely solve this problem? Can an author replace a package without changing its version on npm?
- Klathmon 8y ago>Can an author replace a package without changing its version on npm? No, and now both npm and Yarn have lockfiles, meaning you lock in the exact version of all dependencies (including transitive dependencies). The ecosystem saw the issues that were starting to crop up, and fairly quickly created solutions that are now in widespread usage.
- specialist 8y agoI have a great deal of antipathy towards npm and lock files. I don't understand how rerunning shrinkwrap can change the roster. And I don't care enough to spend any more effort trying to figure it out. (Meaning, fresh out of goodwill.) Maybe yarn is better. I kicked its tires; seemed okay. Alas, we have too many (more than zero) nodejs projects to do a clean switch, and I'm tired of pushing rope. But even if yarn is better... I just can't grasp how we got to this point, or how any one involved thought any of this was acceptable, on any level.
- paulddraper 8y agoShrinkwrap < npm lock < yarn lock
- specialist 8y agoBelated thanks to you & Klathmon. Just yesterday I learned about NPM 6.x's new lock files. I'll suspend disbelief and give it another whirl.
- Klathmon 8y agoWell luckily newer versions of npm and all versions of yarn handle the lockfiles for you, no extra effort required at all. If you install something, it will find and lock the dependency versions at install time. When you update that dependency, it will repeat then lock in again. You actually have to go out of your way now to not use lockfiles in the js ecosystem. And if you really do have some js projects, take 30 minutes and look into yarn. Not only is it significantly faster in my experience, but it's also mostly a drop-in replacement and provides some much needed features like the ability to install while offline from a local cache, and interactive upgrade tools.
- Can_Not 8y agoI find this article to be one year late malicious hyperbole and completely useless in redeeming itself with appropriate action items. > Node modules are widespread and ripe for abuse. Most package systems kind of are, especially when they become more useful. For real advice: checkout from npm retire and auditjs (there's also more non free options). You'll likely get some false positives (such as, who would host jQuery on a public/untrusted cdn? or why would you even pass user input into that?), but if a real malware actually showed up, you can find out as part of your CI process. Using the lockfile provided by yarn/npm is also a good way to reduce accidental unnecessary package updates. > Nonsense dependencies are hard if not near impossible to manually audit due to the sheer number of them. No, they are easier to audit. It's a lot easier to verify that leftpad isn't installing a Bitcoin miner than to verify react isn't installing a Bitcoin miner. React is probably the size of 1000 leftpads, too. > Manually audit and lock down your dependencies. No mention of what this is suppose to be. Yarn will lock your dependencies by default. The yarn.lock file will have the exact version locked. I haven't used npm in a while. > Stop using nonsense dependencies, writing basic code is not reinventing the wheel. Yes, writing "basic code" is reinventing the wheel. You have at least 10 free fully tested leftpads available on npm but you expect me to write one more? I'm paid to build the application, not to apply non-sense rules. This outrage over microlibraries needs a bit more substance. Your alternatives are basically "write code that already exists" or "use bigger monolithic libraries", and, to be frank, most of us have used other languages before or worked on multiple projects, and we can decide for ourselves if a function should be in in-housed or npm'ed. For something as basic as leftpad, wasting time writing it is just a waste of time. As a hard rule, this rule is garbage. As a soft rule, it's not very useful, as case by case scenarios vary too wildly in terms of complexity and significance.