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.
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.
One reasonable approach is to increase the scrutiny for new releases based on how many active downloads of the package there are. So for new packages, maybe there will be not a ton of scrutiny, but for things that are downloaded by millions of users, like Axios, there would be significantly more scrutiny per release.
The epidemic of "not my job" and "[we] don't get paid to do that" is a large contributor to why the world is so messed up. I don't know what to call this phenomenon. In the Hawaiian language there is a word Kuleana which means "sacred responsibility" or "sacred task." If more people took on their Kuleana joyfully we would be inviting the ideal [realm] more rapidly.
What you're suggesting is a radical departure from how free software has been distributed historically. That goes well beyond Github and NPM.
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.
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.
This is a blog post by GitHub. what are you suggesting that these employees do? Simply ignore that they exist? Regardless of whether or not you use them, they still exist.
'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 feel like the only way to be wrong for this class of problem is to believe that there's a singular right answer. Just pick something reasonable (like how weekends are a fairly common thing, so don't make it shorter than 48 hours). Start there, then see how much of an issue persists. No matter what, at scale you'll find someone complaining that the number is too little, and people complaining that it's too much. Eventually you just have to tell the complainers to deal with it.
Cyber attacks will frequently happen on a Friday just for this scenario, they anticipate no ones looking over the weekend.
Blocking a maintainer from pushing updates for a full month after changing their e-mail would be obviously absurd. So Github would have to add a way of enabling maintainers to super-uper-duper confirm the change and cut the delay short. Which is likely not currently possible, hence starting with a shorter delay.