Wes
@notwes.bsky.social
ATX - he/him - 🥂Humans are more important than code - I work at an entertainment company and volunteer my time making art on github
https://github.com/wesleytodd
https://github.com/wesleytodd
Oh sorry, I was drafting an email from my work email and didn't see this. Either one works, but ill go check my personal email now.
November 26, 2025 at 9:15 PM
Oh sorry, I was drafting an email from my work email and didn't see this. Either one works, but ill go check my personal email now.
@posthog.com feel free to reach out, because your remediation is incomplete.
November 26, 2025 at 8:58 PM
@posthog.com feel free to reach out, because your remediation is incomplete.
Like this should not be necessary: posthog.com/blog/nov-24-...
> Their write up highlights how subtle CI workflow choices can create a path from untrusted contributions to package release credentials.
via @socket.dev ☝️ socket.dev/blog/shai-hu...
> Their write up highlights how subtle CI workflow choices can create a path from untrusted contributions to package release credentials.
via @socket.dev ☝️ socket.dev/blog/shai-hu...
Post-mortem of Shai-Hulud attack on November 24th, 2025 - PostHog
At 4:11 AM UTC on November 24th, a number of our SDKs and other packages were compromised, with a malicious self-replicating worm - Shai-Hulud 2.…
posthog.com
November 26, 2025 at 8:34 PM
Like this should not be necessary: posthog.com/blog/nov-24-...
> Their write up highlights how subtle CI workflow choices can create a path from untrusted contributions to package release credentials.
via @socket.dev ☝️ socket.dev/blog/shai-hu...
> Their write up highlights how subtle CI workflow choices can create a path from untrusted contributions to package release credentials.
via @socket.dev ☝️ socket.dev/blog/shai-hu...
The real point is this: bsky.app/profile/jord...
We should not have a system that requires our MASSIVE base of volunteer maintainers to know all of this to secure our supply chain. That is not scalable, nor is it necessary.
We should not have a system that requires our MASSIVE base of volunteer maintainers to know all of this to secure our supply chain. That is not scalable, nor is it necessary.
every option, including "no 2FA at all", *can* be made secure. The problem is that it shouldn't even be POSSIBLE to publish insecurely - and either way, defaults matter.
OIDC and token-based publishing are default insecure, full stop.
OIDC and token-based publishing are default insecure, full stop.
November 26, 2025 at 8:25 PM
The real point is this: bsky.app/profile/jord...
We should not have a system that requires our MASSIVE base of volunteer maintainers to know all of this to secure our supply chain. That is not scalable, nor is it necessary.
We should not have a system that requires our MASSIVE base of volunteer maintainers to know all of this to secure our supply chain. That is not scalable, nor is it necessary.
Had they had an environment setup, with required secondary approves (like we show and suggest in our guides) it likely would have prevented this. That said, all this is complicated so it depends a lot on the details of their setup.
November 26, 2025 at 8:21 PM
Had they had an environment setup, with required secondary approves (like we show and suggest in our guides) it likely would have prevented this. That said, all this is complicated so it depends a lot on the details of their setup.
But even if they had, because of the presence of the other problems they could have just triggered this workflow by using the compromised GH token to push to the repo which would have triggered the release.
November 26, 2025 at 8:20 PM
But even if they had, because of the presence of the other problems they could have just triggered this workflow by using the compromised GH token to push to the repo which would have triggered the release.
for example, one of the "fixes" that doesn't fully fix it from this week: github.com/asyncapi/cli...
Their release still doesn't have an environment: github.com/asyncapi/cli...
Their release still doesn't have an environment: github.com/asyncapi/cli...
ci: attempt at hardening security issue by Shurtu-gal · Pull Request #1909 · asyncapi/cli
Description
Remove bash injection points.
Unsecured context in auto-changeset.yml
Related issue(s)
github.com
November 26, 2025 at 8:19 PM
for example, one of the "fixes" that doesn't fully fix it from this week: github.com/asyncapi/cli...
Their release still doesn't have an environment: github.com/asyncapi/cli...
Their release still doesn't have an environment: github.com/asyncapi/cli...
For this specifically, this suggestion is to put 2FA on the client side. This is clearly not adequate, but in the case of the current supply chain attack they directly targeted the GHA side and could have published *via* these setups because they took over the GH account not the npm one.
November 26, 2025 at 8:16 PM
For this specifically, this suggestion is to put 2FA on the client side. This is clearly not adequate, but in the case of the current supply chain attack they directly targeted the GHA side and could have published *via* these setups because they took over the GH account not the npm one.
IMO all of these things exist because of a failure of @github.com to address this critical gap. So I understand the hesitation to do this stuff. My focus is more on folks, unlike you, who are unaware of the problem and on the platform who needs to make changes to protect us *all* at scale.
November 26, 2025 at 8:12 PM
IMO all of these things exist because of a failure of @github.com to address this critical gap. So I understand the hesitation to do this stuff. My focus is more on folks, unlike you, who are unaware of the problem and on the platform who needs to make changes to protect us *all* at scale.
I disagree that it has to make routine automated publishing hard. We have good ways for this at our fingertips. Yes it needs some "proof of presence" but that can be done in ways that are as low overhead as webauthn like the local publish story does.
November 26, 2025 at 8:09 PM
I disagree that it has to make routine automated publishing hard. We have good ways for this at our fingertips. Yes it needs some "proof of presence" but that can be done in ways that are as low overhead as webauthn like the local publish story does.
This is one of *many* RCE vectors. Some of them are *so important and unchangeable* that we could never get rid of them.
The much more reasonable approach is to ensure malicious automated publish is *hard*.
The much more reasonable approach is to ensure malicious automated publish is *hard*.
November 26, 2025 at 7:53 PM
This is one of *many* RCE vectors. Some of them are *so important and unchangeable* that we could never get rid of them.
The much more reasonable approach is to ensure malicious automated publish is *hard*.
The much more reasonable approach is to ensure malicious automated publish is *hard*.
This is not the root of the problem. So while I would also *love* to see this change, there is a much easier and *direct* fix for the problem we have seen exploited in each of these the past few months.
bsky.app/profile/notw...
bsky.app/profile/notw...
It is beyond frustrating to be in a position to see this coming, trying to do the work to make folks aware of it, and then also to be on the incident response to the impact of it happening again.
Y'all I am tired.
Y'all I am tired.
November 26, 2025 at 7:46 PM
This is not the root of the problem. So while I would also *love* to see this change, there is a much easier and *direct* fix for the problem we have seen exploited in each of these the past few months.
bsky.app/profile/notw...
bsky.app/profile/notw...
We need them to enforce it on OIDC publish or turn OIDC publish off until it can be enforced, and to treat this with the urgency it needs.
I want to be able to stop having this discussion every other week and go into the new year without more supply chain incidents over the holidays.
I want to be able to stop having this discussion every other week and go into the new year without more supply chain incidents over the holidays.
November 26, 2025 at 7:31 PM
We need them to enforce it on OIDC publish or turn OIDC publish off until it can be enforced, and to treat this with the urgency it needs.
I want to be able to stop having this discussion every other week and go into the new year without more supply chain incidents over the holidays.
I want to be able to stop having this discussion every other week and go into the new year without more supply chain incidents over the holidays.
If you are dev impacted, know that it is not your fault this happened.
Feel free to tell @github.com we want them to enforce 2FA on all publishes to @npmjs.bsky.social.
Feel free to tell @github.com we want them to enforce 2FA on all publishes to @npmjs.bsky.social.
November 26, 2025 at 7:31 PM
If you are dev impacted, know that it is not your fault this happened.
Feel free to tell @github.com we want them to enforce 2FA on all publishes to @npmjs.bsky.social.
Feel free to tell @github.com we want them to enforce 2FA on all publishes to @npmjs.bsky.social.
If you are on-call this holiday week (at least in the US) and dealing with your developers being part of the impact, know that we all appreciate your hard work.
November 26, 2025 at 7:31 PM
If you are on-call this holiday week (at least in the US) and dealing with your developers being part of the impact, know that we all appreciate your hard work.
Can this stop being such an uphill battle with people just thinking I am wearing a tinfoil hat or being pedantic?
2FA is just right there, it stops this in it's tracks, and @github.com refusing to enforce it is a massive problem.
2FA is just right there, it stops this in it's tracks, and @github.com refusing to enforce it is a massive problem.
November 26, 2025 at 7:31 PM
Can this stop being such an uphill battle with people just thinking I am wearing a tinfoil hat or being pedantic?
2FA is just right there, it stops this in it's tracks, and @github.com refusing to enforce it is a massive problem.
2FA is just right there, it stops this in it's tracks, and @github.com refusing to enforce it is a massive problem.
It is beyond frustrating to be in a position to see this coming, trying to do the work to make folks aware of it, and then also to be on the incident response to the impact of it happening again.
Y'all I am tired.
Y'all I am tired.
November 26, 2025 at 7:31 PM
It is beyond frustrating to be in a position to see this coming, trying to do the work to make folks aware of it, and then also to be on the incident response to the impact of it happening again.
Y'all I am tired.
Y'all I am tired.
No problem! We have 4 repos in that org (three featured in the blog openjsf.org/blog/publish..., and one to show how we plan to share them across @expressjs.bsky.social repos) that are intended to cover the current landscape. We will update them with more details (and welcome PRs to improve them).
Publishing More Securely on npm: Guidance from the OpenJS Security Collaboration Space | OpenJS Foundation
The OpenJS Security Collaboration Space has been working closely with GitHub’s npm team to understand how new security features affect projects and maintainers, especially as threats and tools keep ev...
openjsf.org
November 25, 2025 at 10:55 PM
No problem! We have 4 repos in that org (three featured in the blog openjsf.org/blog/publish..., and one to show how we plan to share them across @expressjs.bsky.social repos) that are intended to cover the current landscape. We will update them with more details (and welcome PRs to improve them).
It is (partly) separate I agree, the problem is more that *a bunch of resources* went into this less valuable thing instead of the thing that actually solves the problems we have in the real world doing this work.
November 25, 2025 at 10:49 PM
It is (partly) separate I agree, the problem is more that *a bunch of resources* went into this less valuable thing instead of the thing that actually solves the problems we have in the real world doing this work.
And then yeah, all that stuff we are talking about fits into number 2. And that is why we were focused on asking GH/npm folks for changes to address this before they started making changes that forced maintainers to have to consider all this in detail (spending our already precious volunteer time).
November 25, 2025 at 10:47 PM
And then yeah, all that stuff we are talking about fits into number 2. And that is why we were focused on asking GH/npm folks for changes to address this before they started making changes that forced maintainers to have to consider all this in detail (spending our already precious volunteer time).
For single-maintainer projects or ones which are more simple to build/publish, especially if you are not already on CI publish, you should strongly consider just doing local publish. With something akin to this: github.com/npm-pub-2025...
github.com
November 25, 2025 at 10:45 PM
For single-maintainer projects or ones which are more simple to build/publish, especially if you are not already on CI publish, you should strongly consider just doing local publish. With something akin to this: github.com/npm-pub-2025...
For projects with larger contributor bases, or complex needs, I would suggest you follow the example we put out with the GAT, Environment with approvers, and forced 2FA.
github.com/npm-pub-2025...
github.com/npm-pub-2025...
GitHub - npm-pub-2025/ci-publish
Contribute to npm-pub-2025/ci-publish development by creating an account on GitHub.
github.com
November 25, 2025 at 10:45 PM
For projects with larger contributor bases, or complex needs, I would suggest you follow the example we put out with the GAT, Environment with approvers, and forced 2FA.
github.com/npm-pub-2025...
github.com/npm-pub-2025...
And in reply to the “how so”: if you want “better signal” see npx reproduce.
November 25, 2025 at 10:29 PM
And in reply to the “how so”: if you want “better signal” see npx reproduce.
So until we can patch the things that are actually causing rampant malware, i’m sorry, but I’m not going to focus on these theoretical issues.
November 25, 2025 at 10:26 PM
So until we can patch the things that are actually causing rampant malware, i’m sorry, but I’m not going to focus on these theoretical issues.