Post

1. Never manually enter your GitHub or npm password; use a Passkey instead. 2. Enable npm 2FA for both authorization and publishing. 3. Use trusted publishing and remove all npm CI tokens. 4. Only invite maintainers who follow these security practices.

Kevin Deng@sxzz.dev

All the packages affected by this attack had not enabled trusted publishing and provenance. - The top four packages were all impacted. - More than half of the top ten packages were affected. github.com/sxzz/npm-top...

11 reposts38 likes

It was a phishing email that hijacked the 2FA? You are implying that the maintainer did not follow these practices? Also: Trusted publishing wouldn’t have made any difference in this case Provenance would only have helped if one would refuse any non-provenance versions

So I came up with four rules, each adding a tile to the roof of security. There’s no single, universal rule that can block every kind of attack.

Passkeys can protect against phishing emails—users simply cannot grant account authentication under an unofficial domain, unless they manually type in their password.

This is the direction we’re working toward, but that doesn’t mean our current efforts are meaningless. For example, taze already detects provenance downgrades and issues warnings.

Wes@notwes.bsky.social

Wouldn't have stopped this. I have said it before and will say it again...trusted publishing and provenance are useless on their own. They tell you nothing and protect you from nothing. In this case, since it was phishing, they would have just changed the npm setting and been off to the races.

That said, the guide in the post here to what to do is GREAT. Everyone should go and do those (but you have to do all of them, cant leave out the 2fa one).

It is great but it feels that it implies that the lack of those steps was what brought this about, which isn’t correct. And I kind of remember a Slack thread about the provenance and OIDC and such 😜