Upcoming breaking changes for npm v12

aniceperson

didn't know npm was owned by github.. well, that explains things...

Tiberium

I hope GitHub changes their vibecoded badges, what does RETIRED even signify in this context? Why does the preview have to be in ominous red?

TZubiri

Looks good? But doesn't this just change the compromise window from first installation to first run?

cute_boi

They should have added a 1-day age limit by default, so security scanners have some time.

efortis

this release fixes a vulnerability reported 10 years ago https://www.kb.cert.org/vuls/id/319816

Zopieux

Eh, that only took a few dozen actively exploited supply-chain vulns in the span of two years!

heldrida

> The resulting allowlist is written to package.json Couldn’t this effectively result in the same process we get in pre-12 defaults?

karakanb

It is not obvious from the post but it seems like the allow list for the scripts supports whitelisting packages instead of a global setting. This should make it easier to maintain org-wise rules to allow scripts only for specific packages. Is there a linter that could be used for scenarios like this to prevent unsafe default on package manager config?

ComputerGuru

My big question as an OSS dev distributing some precompiled binaries via npm for easy installation: does allowScripts also default to disabled when directly installing a package (globally or otherwise)?

themafia

The "aw geez, enough is enough" release. Finally.

thatmf

> allowScripts defaults to off Nice that they're following pnpm's lead on this after [checks watch]... 18 months?

tuckwat

I bet there have been a hundred different discussions about this inside of NPM since it was disclosed 10 years ago. With Shai Halud it's gotten too big to ignore.

retardedsecguy

npm is basically pnpm now

Pxtl

I would've assumed lockfile-by-default. We're still going with auto-updating?

zarzavat

There's an easy way to stop most supply chain attacks: 1. Publishing users must approve each and every release from a smartphone app. 2. Publishing users must provide verified government ID. The first step prevents the types of attacks where an attacker gets control of a maintainer's computer and publishes a new release. The second step discourages attacks where a user tries to get a malicious package used by others. When combined with the security features that already exist, e.g. delays and automatic scanning, it would make it considerably harder to pull off a successful attack.

SCLeo

I don't get it. How does this help with anything? You pull in a dependency to use it, right?

thrdbndndn

How do you allow scripts for tools installed globally?

beart

Does the allow list in package.json pin to the package version, or only to the package name?

cookiengineer

What a pointless change. If you force every user to just use "--enable-unsecure-feature", guess what will happen? This is not about improving security. This is about shifting blame. A much better alternative would've been the introduction of sandboxes or simulation runs that would output which scripts and programs are running due to unpredictable dependencies. This way the user could check before the actual execution, and maintain an allow list much easier. That could be done via an npm update && npm upgrade workflow where the update generates the list that the user has to manually confirm. Heck, even a chroot would be an improvement, and they're almost pointless these days, considering how good malware got at escaping chroots.

jbverschoor

And when will we get rid of the vendored node_modules, and make it read only?