>> high-impact npm accounts are now put into a read-only mode for 72 hours when they change their email or use a 2FA recovery code. This delay allows maintainers time to respond and recover the account before their account can be used to start an attack.
I paid $8 for the recently expired email domain of the sole author of NPM package "foreach", so then control to ship any code I wanted to 70k companies was just a support ticket or password reset away. 72 hours would not make a difference here.
Talked to NPM about this when it went viral, and once again all they could say was enabling package signing, even optionally, would discourage inexperienced people from contributing packages as they would be pressured to learn basic security and key management.
Sorry, if you are unwilling to take 10 minutes to learn how to sign your code, you have no business maintaining software releases millions of people depend on. Full stop.
But NPM will not even make it -optional- and rejects all PRs to implement this going back a decade. So no one feels pressured into basic security. Cool.
Github owns NPM. Github has unprecedented access to code analysis tools. Github can run static analysis on nearly everything. Introducing a cooldown period seems like the lowest tech solution to a technological problem I have seen in a longwhile.
Cooldowns have the benefit of being straightforward. It doesn't rely on updating rules, scanning, keeping up with obfuscation techniques, etc. It just stops installs for a period of time after publish.
I think that cooldowns are mostly dumb but they're very cheap to deploy and they do give other approaches (like scanners) more time to adapt/ do their job.
Trusted Publishing pins the publish to the workflow. The next step is to isolate "run untrusted code (`npm build`)" from "publish" in your workflows. Now you have two properties - the publish can only happen from one place and the publish is isolated from untrusted code execution.
I literally am reading this after setting GitHub actions five minutes ago to generate the APK version of my cross platform project for the first time. Great :\
My only use of GitHub Actions specifies permissions that only allow it to write to the issue tracker, so if the program it executes (which is the "gh" program) is malicious then the only damage it can cause is to the issue tracker and not to the repository itself (unless GitHub Actions itself is compromised). Furthermore, there are no private files (I do not host private files on remote services such as GitHub), so they can't steal my files either.
I think one thing that would help is to support mutual TLS, with X.509 certificate chains for authentication. This is more secure than personal access tokens and allows you to issue them to yourself and others without needing to login first, including to specify whatever permissions you want to set (as a subset of the permissions of the issuer) and to make them expire. (You could also store the private keys of one certificate on a separate computer not connected to the internet, and use that to issue another one to yourself to use that one instead, and can use a passworded private key as well (an alternative of 2FA), so you can recover even if your certificate you are using does become compromised, or something deletes it (intentionally or not), and can revoke the ones that are compromised.)
Mutual TLS (and even ordinary TLS) won't solve everything, but in combination with other things, including ability to restrict access to what is needed, and avoiding needing too many dependencies (since, programs that need too many dependencies is also one thing that can cause many problems), and many other things, it can be an additional step to help with security.
It is fascinating how far people will go to do anything else at all other than having authors cryptographically sign their packages like every Linux package manager that matters since 1996.
Linux package managers like debian/apt also ship hundreds of signed NPM packages. In other words the unpaid Linux community has once again solved a problem Microsoft fundamentally failed to. Some things never change.
20 comments
[ 3.1 ms ] story [ 48.6 ms ] thread'what time shall we put here?'
'what's the longest hangover you ever had?'
'let's put 72 hours'
Talked to NPM about this when it went viral, and once again all they could say was enabling package signing, even optionally, would discourage inexperienced people from contributing packages as they would be pressured to learn basic security and key management.
Sorry, if you are unwilling to take 10 minutes to learn how to sign your code, you have no business maintaining software releases millions of people depend on. Full stop.
But NPM will not even make it -optional- and rejects all PRs to implement this going back a decade. So no one feels pressured into basic security. Cool.
I think that cooldowns are mostly dumb but they're very cheap to deploy and they do give other approaches (like scanners) more time to adapt/ do their job.
https://github.blog/changelog/2026-07-28-npm-publish-time-ma...
Is it purely more secure because they can't exfiltrate your secret keys to publish again?
I feel like if your workflow gets pwned you'd be rotating your keys anyways, so I'm not sure if the vendor lock-in is worth it.
I think one thing that would help is to support mutual TLS, with X.509 certificate chains for authentication. This is more secure than personal access tokens and allows you to issue them to yourself and others without needing to login first, including to specify whatever permissions you want to set (as a subset of the permissions of the issuer) and to make them expire. (You could also store the private keys of one certificate on a separate computer not connected to the internet, and use that to issue another one to yourself to use that one instead, and can use a passworded private key as well (an alternative of 2FA), so you can recover even if your certificate you are using does become compromised, or something deletes it (intentionally or not), and can revoke the ones that are compromised.)
Mutual TLS (and even ordinary TLS) won't solve everything, but in combination with other things, including ability to restrict access to what is needed, and avoiding needing too many dependencies (since, programs that need too many dependencies is also one thing that can cause many problems), and many other things, it can be an additional step to help with security.
Linux package managers like debian/apt also ship hundreds of signed NPM packages. In other words the unpaid Linux community has once again solved a problem Microsoft fundamentally failed to. Some things never change.