21–30 of 59 posts
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.
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.
Earlier quoted context omitted.
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 some…
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.
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.
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.
Earlier quoted context omitted.
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.
I don't think so at all. People go on vacation all the time. This should be 30 days not 3.
Earlier quoted context omitted.
[flagged]
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…
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.
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.
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.
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.
https://github.blog/changelog/2026-07-28-npm-publish-time-ma...