Hacker News Reader

> it defaults to specifying a semver compatible version in package.json, rather than doing the secure thing and pinning a version

Note that if you have a package-lock.json (which you will by default), it will prevent any surprise updates even within the semver range specified. You have to manually run `npm update` to get the latest versions that match your semver. Personally I think this is the best middle-ground.

This is, unfortunately, not true by default. I had a case where I did `yarn install` and there were updates installed.

To make this work correctly, you need to do `yarn install --frozen-lock-file` or `npm ci`.

It’s absolutely _insane_ that this is the case. Gemfile.lock, Cargo.lock, and every other lock file format that I have used in packaging does this correctly.

It used to be true. npm install used to do what npm ci does. It was super annoying to learn that the hard way.

One of the core issues of NPM style package management is package bloat means you absolutely can't review all release notes for every module in your tree. So you just trust the top level packages, and pray they would mention something if their dependencies change how they themselves work. Practically I rarely see anyone read release updates for even those top level packages, they just update everything and test then send it up to prod is very typical.

If you are cool with that, rad, but it's the pinnacle of the fast food tech ethos literring software right now. Everyone is moving so fast that you barely get to learn something properly or maintain it well enough before it's defunct and we are on to the next thing. I might have a slightly bias view of it, working mostly for agencies I see a lot of projects.

Some orgs are much more in line with GP’s suggestion. Marketing sites may feel low risk and in my view the iteration speed required justifyies having a trusty stack with known good versions to start from. Personally my method of construction is very conservative and I thrive in B2B SaaS environments, where in Consumer front-end orgs I can be seen as a dinosaur at times. I love new and shiny things as much as the next dev, and enough incidents will hopefully create a more conservative culture of using free lunch-looking stuff more cautiously. Race to the bottom dynamics in a sense, lacking any regulation. The expectation is move fast and break things, I get that, because of the first to market/time is money bias/truth. Inexperienced devs won’t have the scars to push back if there are upstream changes to review while their boss expects the feature updates to be live ASAP. I imagine that with decades regulation will force certain processes—not that I want it more than the next dev who loves shiny stuff and delivering results fast/delighting my boss.

Go does this well. It chooses the minimum viable version that satisfies the constraints for each package.

The minor security updates are solved well by periodically running security linters and scanners. There's even a recent GitHub feature for it. That will alert you that you need to update a package.

> Pinning versions means that you will keep using an insecure version of a dependency until you update

Which is why you schedule time each sprint/release to check your dependencies and upgrade them in a controlled fashion.

Have you ever run npm audit on a project more than a week old? My high score is 3k new vulns in a single week…

> I agree that it’s ultimately the developers fault for allowing code to be automatically injected

Let's not do victim blaming here.

This is ultimately the fault of the person deliberately updating their package to break other people's software.

Nah, open source software is "use at your own risk" and there's 0 guarantee for anything. All responsibility lies with the user. If you don't like that responsibility, don't use open source software without reviewing it first.

It’s one side of the coin.

The other is, to do anything at all of practical use in 98% of jobs, day 1 is installing a tonne of OS stuff.

It’s not practical to expect pretty much every dev to inspect 100% of that, even if that’s what they implicitly agree to do in the license.

We're not talking about "a ton of OS stuff," we're talking about NPM packages.

If you have your package manager set up in a way that allows it to automatically upgrade/break your code, that's 100% on you.

I have a medium-sized data science project in Python. Nothing crazy. It's 180 packages, apparently, and 2.9M lines of code (whitespace, comments and all). Charitably let's call it 1m SLOC.

Seriously, you expect anyone to audit all this? It's basically impossible for any solo dev / small org, and as I say, it's not even a big project. A vulnerability is like half a line, or sometimes a typo.

Clearly, very different proposal for a large org, but even then, no small task.

"0 guarantee" might apply to accidental bugs, but a developer maliciously sabotaging their packages?

"Victim blaming" is a little harsh when it's literally a developer not doing their job and letting arbitrary code get inserted into their product.

Do your job and make sure the code that's running is what you expect. There's no valid excuse not to.

> This is ultimately the fault of the person deliberately updating their package to break other people's software.

Ultimately the 2017 Equifax data breach was the fault of the people who hacked into Equifax's website.

We need systems in place to defend against people doing malicious things, but yes ideally individual developers shouldn't be the ones tasked with reviewing all of their dependencies' code.

Operating System provided packages, for example, are generally reviewed by someone other than the author, which can lead to a more secure supply chain.

Rust's cargo-crev review system also seems like a possible solution the problem.

To boost this: it's worth reading about the difference between "npm install" and "npm clean-install". The "ignore-scripts" flag/configuration setting can also be valuable.