new | show | ask | jobs Github

I_am_tiberius 7 hours ago

I guess you should never use the latest versions of libraries.

▲

kaelwd 7 hours ago | parent | next [-]

Everyone needs to switch to pnpm and enable https://pnpm.io/settings#minimumreleaseage

Pnpm also blocks preinstall scripts by default.

▲

loloquwowndueo 6 hours ago | parent | next [-]

Nah - dependency cooldown is all the rage but it’s only effective if you have some noncompliant canary users. Once everyone is using it it will cease to be effective because nobody will be taking the first step/risk until everybody does.

▲

moebrowne 5 hours ago | parent [-]

The point of the cooldown is to allow time for vendor scans to complete and for compromised packages to be pulled. It's not about waiting for an end user to notice they've been compromised.

> Meanwhile, the aforementioned vendors are scanning public indices as well as customer repositories for signs of compromise, and provide alerts upstream (e.g. to PyPI).

https://blog.yossarian.net/2025/11/21/We-should-all-be-using...

▲

loloquwowndueo 4 hours ago | parent [-]

Depending on “security vendors” to do scans of every single update seems naive and over optimistic to me, but hey - everyone’s jumping on the bandwagon regardless of what I think so I guess we’ll see soon.

▲

limaho 3 hours ago | parent | next [-]

Don't "security venders" detect and report most of these types of attacks already today?

	▲	loloquwowndueo 3 hours ago \| parent [-]
		Do they? :)

▲

moebrowne an hour ago | parent | prev [-]

What's the alternative?

▲

thepill 6 hours ago | parent | prev [-]

Or bun

▲

Ygg2 7 hours ago | parent | prev | next [-]

But you also need the latest versions to avoid zero-day attacks.

▲

cesarb 2 hours ago | parent | next [-]

Or an old enough version. For one of the most damaging zero-day vulnerabilities in the Java ecosystem (log4shell), you were vulnerable if you were in the latest version, but not vulnerable if you were using an old enough version.

▲

lpribis 5 hours ago | parent | prev | next [-]

99% of releases do NOT fix zero-days. But 100% of releases have a small risk of introducing a backdoored build-script.

There's nothing wrong with pinning dependencies and only updating when you know for sure they're fixing a zero-day (as it will be public at that point).

▲

zelphirkalt 5 hours ago | parent | prev | next [-]

Zero-day on frontend has not really a y effect, except on one user at a time. Zero-day on a server though ... perhaps we arrive at the conclusion to not use the JS ecosystem on the server side.

▲

nalekberov 6 hours ago | parent | prev [-]

do zero-days even care about versions?

	▲	Ygg2 2 hours ago \| parent [-]
		They care how long you take to patch your versions. Delaying patching by 7 days will affect it.

▲

sublinear 7 hours ago | parent | prev [-]

Not sure if you're serious, but if so I agree that people should take the time to set up their own package mirrors. Not just for npm but all other package managers as well.

This is why it's so important to get to know what you're actually building instead of just "vibing" all the time. Before all the AI slop of this decade we just called it being responsible.

▲

prmph 5 hours ago | parent | next [-]

Exactly, there is no easy solution to these problems.

The solutions that are effective also involve actually doing work, as developers, library authors, and package managers. But no, we want as much "convenience" as possible, so the issues will continue.

Developers and package authors should use a lockfile, pin their dependencies, be frugal about adding dependencies, and put any dependencies they do add through a basic inspection at least, checking what dependencies they also use, their code and tests quality, etc.

Package managers should enforce namespacing for ALL packages, should improve their publishing security, and should probably have an opt-in verified program for the most important packages.

Doing these will go a long way to ameliorate these supply chain attacks

▲

moebrowne 5 hours ago | parent | prev [-]

How does having a mirror help?

	▲	sublinear 2 hours ago \| parent [-]
		Maintaining a package mirror is a shared responsibility beyond just the software dev teams. The packages and their publishers need to be approved to be added to the mirror, testing needs to occur, and updates are delayed until the newer version is added to the mirror. The network team would block npm and force all machines to use this mirror. All this would have mitigated this incident in the event that an npm install was done during the window of this update being rolled out and unpatched. The npm install would continue as normal on the last known good version and the newer vulnerable version would simply not exist on the mirror.