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 6 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 6 hours ago | parent | prev [-]

How does having a mirror help?

	▲	sublinear 3 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.