Rendered at 18:45:23 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
alpineman 4 hours ago [-]
>> 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.
'what time shall we put here?'
'what's the longest hangover you ever had?'
'let's put 72 hours'
Waterluvian 4 hours ago [-]
A weekend plus a day to deal with things seems like a decent minimum duration when it’s somewhat arbitrary what the right number is.
datakan 3 hours ago [-]
I don't think so at all. People go on vacation all the time. This should be 30 days not 3.
Waterluvian 3 hours ago [-]
That's the usual runaway problem, right? Why not 60 then? People go on sabbaticals! etc etc.
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.
datakan 3 hours ago [-]
There is a big difference between 3 days when someone may be sick or traveling and not looking and 30 which aligns better with 99% of scenarios this may be an issue with. 3 days is absurd. Even password apps with kill switches will default to 7 days.
Cyber attacks will frequently happen on a Friday just for this scenario, they anticipate no ones looking over the weekend.
tredre3 2 hours ago [-]
And 365 days probably aligns with 100% of scenarios. It doesn't mean it's a good idea, because the longer the delay is the more downsides you also get.
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.
Normal_gaussian 2 hours ago [-]
It sounds like we should plot 'count of compromised repos' against 'time taken for maintainer to initiate a resolution', and pick something just after the inflection point.
normie3000 3 hours ago [-]
It's often not the maintainer that removes a poisoned release, it's the npm security team/tools. So unless the whole team takes a month off, we're all safe.
summarybot 3 hours ago [-]
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.
insanitybit 44 minutes ago [-]
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.
lazyasciiart 44 minutes ago [-]
It's certainly the lowest tech piece of their announcements over the last day, as far as I can tell.
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 :\
skipants 3 hours ago [-]
One thing I don't quite get is how trusted publishing is supposed to be more secure. It still allows publishing if they pwn your workflow.
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.
pimterry 2 hours ago [-]
Trusted staged publishing helps a lot: you have to independently pwn the workflow _and_ then complete a separate 2FA flow as a maintainer. The workflow never sees any keys that can publish independently.
insanitybit 43 minutes ago [-]
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.
flyingshelf 3 hours ago [-]
Keys can be reused from anywhere. Trusted publishing means the attacker must trigger the specific workflow on GitHub, which is more difficult and leaves trace of actions on GitHub itself.
3 hours ago [-]
hncsiocp9x 4 hours ago [-]
Been quietly thinking this for years
pluto_modadic 4 hours ago [-]
the bare minimum award, for the only language and only registry where this regularly happens.
hinkley 37 minutes ago [-]
At this rate I'm going to have "npm is by far the worst thing about NodeJS" printed on my gravestone.
torment-nexus 3 hours ago [-]
[flagged]
DiabloD3 6 hours ago [-]
[flagged]
theF00l 5 hours ago [-]
The job can require you to
DiabloD3 5 hours ago [-]
[flagged]
UqWBcuFx6NV4r 5 hours ago [-]
These comments should be removed r from HN, because they in no way actually add to the conversation. They aren’t intelligent, they aren’t insightful, they aren’t actionable, and they don’t invite a genuine reply. All you’re saying is that you happen to not use these technologies yourself – something that I’m sure is only by happenstance – and that you feel superior for it.
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.
DiabloD3 2 hours ago [-]
It very much is actionable.
You might not know this, but the world of software development existed before NPM and Github, and it continues to exist after them. You are not beholden to either of them.
sieabahlpark 4 hours ago [-]
[dead]
anon48293 4 hours ago [-]
> This is a blog post by GitHub. what are you suggesting that these employees do? Simply ignore that they exist?
The buggy, insecure feature that is GitHub actions? Yes, preferably so.
x86a 5 hours ago [-]
This is such a myopic take
baby_souffle 5 hours ago [-]
GitHub actions doesn’t really make you a js shop
rho138 5 hours ago [-]
> Opting out of toxic ecosystems is a valid option
Quick, everyone break out the pitchforks for a valid analysis of a game! /s
'what time shall we put here?'
'what's the longest hangover you ever had?'
'let's put 72 hours'
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.
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.
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.
You might not know this, but the world of software development existed before NPM and Github, and it continues to exist after them. You are not beholden to either of them.
The buggy, insecure feature that is GitHub actions? Yes, preferably so.
Quick, everyone break out the pitchforks for a valid analysis of a game! /s