Stream: friends

Topic: 111: npm under siege (what to do about it)

Logbot (Oct 03 2025 at 17:00):

Over the past two months, we’ve seen some of the most serious supply chain attacks in npm history: phishing campaigns, maintainer account takeovers, and malware published to packages with billions of weekly downloads. What is going on?! What can we do about it? Our old friend, Feross Aboukhadijeh, joins us to help make sense of it all. :link: https://changelog.am/111

Kilian Kluge (Oct 04 2025 at 19:25):

Unless I missed it, it wasn't mentioned in the episode: https://docs.zizmor.sh/ is an open source static analysis tool for GitHub Actions that will flag (and sometimes even auto-fix) common vulnerabilities like code injection via template expansion or the pull_request_target trigger discussed in the episode.

It's running as a GitHub Action itself, so it's straightforward to adopt, and most issues an initial run surfaces are usually quick to fix.

Ron Waldon-Howe (Oct 04 2025 at 23:06):

In the long long ago, in the before times, Docker Hub had verified builds
You would register your source code repository with Docker Hub, and your source forge (GitHub, GitLab, etc) would notify Docker Hub via webhook whenever you made a commit
Then Docker Hub would use it's own compute resources to fetch your code, build your Dockerfile, and store the resulting image in the Hub
No custom CI on your part, no possibility that the image contains things that were not in the source code repository
Then cryptocurrency came and ruined everything, by chasing all the free compute away: https://drewdevault.com/2021/04/26/Cryptocurrency-is-a-disaster.html

Ron Waldon-Howe (Oct 04 2025 at 23:07):

I really really wish there was a way to have verified packages in npm, crates, gems, etc where the package repository performed the build using its own trusted resources and directly from the source code without any tampering

Ron Waldon-Howe (Oct 04 2025 at 23:10):

Well, I suppose if package authors paid the central repository to help finance the compute resources, then the repository would be able to build the packages directly from source code and mark them as verified
So, we end up with "verified" being a paid indicator, as on social networks, but with actual functional differences instead of just being a weird flex

Tim Uckun (Oct 05 2025 at 00:17):

I don't understand why this is such a hard problem. Here is my simple easy solution.

1. use an immutable global distributed file system (i.e IPFS, freenet, etc )
2. For every package there are two files. One is a manifest/descriptor second is the actual zip file.
3. The manifest is a json or yaml or whatever which contains the package, info, deps, and metadata about the package. It's designed to be plaintext and indexable. Can be served from an https url or IPFS. You host it on your own domain.
4. The manifest contains the hash of the package (zip file) which you can use to retrieve from the distributed store.
5. The package contains the manifest (except the hash of course) which you can verify against the index to ensure you have the right package.
6. If the package contains source code a search is done of the source code and a prompt is created which details whether or not the code is accessing the file system, what directories it's seeking, what URL's it's reaching out to etc. Needless to say this has to be language specific.
7. Packages can be signed. They could even be encrypted if you want.

This would be completely decentralized and packages would be cached by your laptop or CI server.

We need to get away from having all of our packages and source code hosted by one corporation or another.

Ron Waldon-Howe (Oct 05 2025 at 02:36):

1-5 and 7 don't offer any protection of a package is tampered with prior to publication, which we've seen with some of the npm malware

I agree that they seem to be good general improvements, nevertheless

Can 6 be solved without also solving the (unsolvable) Halting Problem? We might have some control regarding build-time / publish-time capabilities, but some of the malware we've seen tampered with runtime behaviour, too

Ron Waldon-Howe (Oct 05 2025 at 02:38):

Perhaps we're back to the issue of trust, and having to develop chains of trust, something like https://github.com/crev-dev/cargo-crev but for any programming language ecosystem?

Ron Waldon-Howe (Oct 05 2025 at 02:42):

GPG key signing parties, anyone? :P

Tim Uckun (Oct 05 2025 at 04:59):

I don't think anything is going to solve the problem of a malicious actor completely but steps and six and seven can effectively minimize this problem. Step 6 is basically code review. If code can be examined then we can isolate certain system calls such as file io, network access etc and present a report the user saying "this package contacts the URL xyz" or "this package attempts to open a file in directory xyz" etc. Step seven can ensure trust by checking a signature.

In my scenario packages are urls. http://microsoft.com/os/some_package/2.1.3 for example. Each version would be a unique URL. If the URL is an IPFS url or a namecoin URL or something like that then it's immutable which is even better. When you pull up that URL you get a manifest you can examine which details the author, package version, dependencies, public keys etc. In it there is an entry which is the hash of the zip file. You pull up the zip file using the hash from ipfs or freenet. You can then open the zip file and compare the manifest inside of it with the manifest you pulled to ensure you are getting the right version of the software.

As you pointed out it's not perfect in that people could camp on domain misspellings, post malicious binaries, etc. I guess for that we need additional layer of protections from the OS like requiring permissions before accessing external directories, pausing apps that consume too much CPU, etc.

Dustin (Oct 05 2025 at 10:03):

@Tim Uckun can you explain what vulnerabilities in existing centralized package registries your solution solves? I’m not following

Dustin (Oct 05 2025 at 10:35):

If I’m understanding correctly it sounds like early steps towards (the now abandoned) Pyrsia https://youtu.be/ec8vvD1SG-s?si=uUqQUFWBN-SDUk69

Tim Uckun (Oct 05 2025 at 21:09):

1. Centralized control of repositories.
2. Mutability of published packages.
3. language dependence. My proposal is a system for delivering trusted binaries and being able to index metadata without having the whole package stored.
4. as a bonus it would get people (and CI servers) to host a distributed file system which would help the whole world.

Finally. Under ideal circumstances you should be able to put a price on your published code. Ideally there would be some crypto which is premined like XRP so transactions are cheap and fast and don't require a lot of computation. You publish your library and if people want to use it they can pay a tiny amount for it. Of course ideally they would be being paid to run the file system node (i.e Storj or Filecoin) so it would balance out by and large.

Ron Waldon-Howe (Oct 05 2025 at 21:38):

In the container and infrastructure ecosystem, it's increasingly popular to sign artefacts using cosign: https://github.com/sigstore/cosign
But that's another step in the publication process
It seems like the solutions in this space all introduce friction for good faith sharing, and additional friction for consumption

Jerod Santo (Oct 07 2025 at 17:12):

@Kilian Kluge hadn't heard of zizmor, thanks for sharing!

Nabeel S (Oct 16 2025 at 04:10):

I just received this email today. ECR Login Renewal is an open source tool I wrote a long time ago. Sounds very shady.
image.png

Last updated: Oct 16 2025 at 05:39 UTC