Stream: interviews

Topic: 674: Securing npm is table stakes

Logbot (Jan 29 2026 at 15:00):

As the creator and long-time maintainer of ESLint, Nicholas Zakas is well-positioned to criticize GitHub's recent response to npm's insecurity. He found the response insufficient, and has other ideas on how GitHub could secure npm better. On this episode, Nicholas details these ideas, paints a bleak picture of npm alternatives like JSR, and shares our frustration that such a critical piece of internet infrastructure feels neglected. :link: https://changelog.fm/674

Duncan (Jan 29 2026 at 18:08):

Uh-oh - Seemed like all the Deno references were past tense as if it's a failed endeavour

Jerod Santo (Jan 29 2026 at 19:08):

Yeah that is the gist of the report that Nicholas gave us, sadly

Tim Uckun (Jan 31 2026 at 03:07):

I mentioned this before but....

Why does a package repository have to cost so much? Why not leverage a distributed file system like IPFS or freenet/hyphanet or whatnot. The premise is simple. Each package consists of two part, a manifest and a blob (zip file).

• The manifest is plain text (xml) and is hosted on any https URL.
• The URL could be the private server of the author or a centralized repository or a github/gitlab repo
• The manifest has mandatory fields such as author, dependencies, the binary format, whether the blob is signed etc.
• One mandatory field is the checksum of the blob
• the blob contains the manifest minus (minus the checksum field which is added when the package is published)
• The manifest lists the required permissions to install (like the app store)
• the manifest contains the pre and post install scripts

The blob is stored on a distributed file system using the checksum as the file name.

Anybody can examine the manifest to make sure everything is up to snuff.

The package manager downloads the manifest, resolves dependencies, and downloads the binary. It opens up the binary and compares the manifest in the blob with the published one to make sure everything matches.
The package manager verifies any signatures etc.
The package manager is an interpreter for a very small and limited language which can run pre and post install scripts in the manifest (CDATA sections). The code is run sandboxed and asks the user for permissions if the script attempts to reach out to the internet, access the file system outside of the sandbox etc.

Optionally the package manager can be node in the distributed file system which would make it able to cache the packages for repeat installs.

In an ideal world there would be a crypto currency where the user can earn money for acting as a node and the package maintainer can charge for the packages. Some careful thought can result in a thriving economy of open source packages.

The whole thing would be decentralized so no central authority no corporate control or anything.

Ron Waldon-Howe (Jan 31 2026 at 04:53):

it's now completely infeasibile to offer free compute ( https://drewdevault.com/2021/04/26/Cryptocurrency-is-a-disaster.html ) and there are probably similar pressures making it difficult to offer free storage
even with low cost networking, we don't see a substantial portion of unused network bandwidth donated to tor
it's possibly just too difficult to bootstrap a sustainable socialist/community project like this within the confines of capitalism: eventually one or more of the giants is required in order to fund it

Don MacKinnon (Jan 31 2026 at 18:33):

I’ve been raising these supply chain concerns for ages. It’s really unfortunate that Microsoft doesn’t put more budget towards addressing this. It’s a ticking time bomb over there and so many companies rely on NPM. It’s a bummer that JSR didn’t make it, I had hopes for it.

Ron Waldon-Howe (Jan 31 2026 at 19:48):

to avoid supply-chain attacks, should we be bypassing npmjs.com and referring directly to git repositories + commits/tags per https://kerkour.com/rust-supply-chain-attacks ?
seems like this doesn't accomplish much if we're already using lock files, although it does at least avoid the potential difference between the code I can review and what actually ends up being published

Tim Uckun (Jan 31 2026 at 20:44):

@Ron Waldon-Howe The crypto part is optional and doesn't have to be based on proof of work though. It could be a premined currency like XRP or proof of stake or other much lighter algos. BTW everything I listed already exists. It's just a matter of wiring it up.

Ron Waldon-Howe (Jan 31 2026 at 20:46):

@Tim Uckun yeah, I should have said that I know IPFS isn't cryptocurrency and doesn't have the same perverse incentives, that link was mostly to illustrate the lack of free-to-use community-owned resources (due to perverse incentives in other blockchain projects primarily cryptocurrency)

Tim Uckun (Jan 31 2026 at 21:01):

In a way you would have an incentive to run a node just to serve the cache packages you already downloaded. Certainly most CI and build systems would.

Ron Waldon-Howe (Jan 31 2026 at 21:04):

yeah, even if only 1 in every 100 users of (e.g.) ESLint was providing access to their cache of it, that'd probably take a fair chunk of traffic/burden off npmjs.com

Siddhartha Golu (Feb 05 2026 at 08:07):

Came across npmx.dev the other day, and it looks very promising.

Last updated: Feb 17 2026 at 17:33 UTC