Hacker News Reader

Comment by jmadsen | Hacker News Reader

I'm more of a back-end dev who doesn't know all the ins and outs of the actual software used - can someone explain to me why this is an npm problem, and not an excessive dependencies problem?

I thought npm was simply a package manager - I don't see anything in the article that is specific to npm, except he happens to say that word.

View on HN

It's kind of an excessive dependencies problem, except exacerbated by two things. One is Javascript's poor stdlib. This means that not only are you tempted to include lots of little packages to do basic things, but so are all of the big packages that you include to do big things for you, and all of the packages they include, etc. Often there are a bunch of different packages for doing the same basic things, and nobody agrees on which one, so you may end up with 5 different packages that do the same thing required by various packages you use.

Two is that much of it is expected to be served to the browser, so it's minified. Who audits that the minified code is actually the same as the published Github code?

At least in Ruby and Python, the code from Rubygems/Pip should exactly match that version on Github. Not that anyone necessarily audits that either, but at least it's easier.

In Ruby, the exact same problem applies since you can publish gems in one version and tag them in another - in the very same fashion as the article describes.

What makes npm particularly bad, is that JS has such a teribad stdlib. When you need to write your own lpad() at some point its easier to include a stupid little package that has dealt with all the edge cases you don't want to care about. So you end up with way more third party deps than a kitchen sink type language.

Otherwise, yes this is a fundamental dependency issue.

but that has nothing to do with npm.

that's the same for any javascript package manager - yarn or bower would be the same.

npmjs.com is the repository both yarn and npm use—this is about npmjs.com the repository, not npm the package manager per se.

that makes it a lot clearer, thanks!

You can actually pad your strings now https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

could we actually take a snapshot of npm’s top used but relatively inert libraries every 6 months or so and freeze them? (call it UserlandJS 2018a, 2018b, etc) and then have a separate dependency manager that only downloads those frozen libraries we include. Userland Package Manager or something. this would approach a stdlib without much effort and we would have more of a chance to catch up on malicious security stuff since there are commonly agreed upon frozen versions that everyone can pore over.

im a total noob at security, please attack/modify this idea if it has any value?

discussing on twitter here https://twitter.com/swyx/status/949946224043610112

You could arguably come up with something similar for backends. It's just a story of a malicious and sneaky dependency.

exactly.

I question all these comments by people singling out npm as the root of the problem. doesn't sound to me like they fully understand the issue.

npm isn't the root of the problem, it's just a particularly popular example of it. Sort of like how Intel isn't really the root of that other problem, just the implementer of speculative execution with the biggest market share.

Nobody is singling out NPM. The issue is the current JavaScript ecosystem and that happens to be provided through NPM, so you can use "NPM" as a shorthand for "the way JavaScript developers these days use NPM to depend on a gazillion trivial packages with totally unknown provenance".

why not just say "excessive dependencies" and be correct, succinct and perfectly clear?

Because that is the symptom. The problem is that the ecosystem encourages excessive dependencies. You can say "the way the ecosystem encourages huge dependency trees" if you like.

The first problem is excessive dependencies. Just one word: Left-pad. That is a library on its own, for that one simple problem. The JS ecosystem encourages that for any problem, no matter how small it is, you import some existing lib. So at the end of the day you have 100+ dependencies on a project that is only slightly larger than a "hello world" page.

The next problem is that npmjs is "free for all". Imagine anyone could easily add new packages to the debian repo. Sure, I don't expect the debian folks to audit every new addition or update to existing packages, but there is at least some chain of trust, plus there is some incentive to not have malware ridden packages in your distro because it hurts your credibility. A distro is both, an infrastructure and content provider. npmjs is just the infrastructure, so it takes some more messups for people to consider moving away from it.

It's not specific to npm. It's a problem that generally applies to all of these package managers that introduce code that you have not personally reviewed into your site.

I think the important part is that it’s a package manager commonly used for front end development, so the malicious code runs directly in the browser. It could have been bower or something else but npm is the probably the most popular choice these days.

The root of the problem is that a dependency can be downloaded and installed from only it's minified/obfuscated form, and without any verification that the code matches what is in the non-minified/obfuscated codebase. This is just exploited through people being dependency-happy and that no one really verifies that a package isn't doing more than what is advertised.

This same problem would exist if any server-side dependency repositories allow for code to be delivered in a pre-compiled form without any verification, similar to npmjs.

I guess it's not npm per se, but js crowdsourcing factor multiplies the attack surface by large powers of ten. In other languages, having the security libs centralized and vetted "might" (you'd need an decent amount of work to ensure that it is safe) avoid getting MITM'd so easily.

Reply on news.ycombinator.com