Nicholas Zakas

that it's almost impossible to protect our users if some malicious package gets in the dependency tree somehow.

Yeah.

So my read on the changes that they made was that it was pushing more responsibility onto maintainers.

So eliminating the kind of older style tokens, I can understand fine-grained tokens are way more secure.

That makes sense.

But then limiting the lifetime of those tokens, they went through a bunch of iterations.

I think they finally landed on like 90 days later.

That alone, if you're doing token-based publishing, now you need to remember to update your tokens every 90 days, or you have to implement some sort of automation to do it for you on top of whatever else you're already doing.

And the response to that was, well, if you use trusted publishing,

the OpenID Connect feature that they have in GitHub Actions, then you don't need to actually store a token anymore.

It's generated on the fly and you can just publish using that.

And that sounds

great like it's a good solution to not just have a token laying around yeah somebody can use kind of a lock-in thing though right it's kind of a lock-in thing well it is i mean number one that's great if you're on github or gitlab also supports it but what if you're not on either of those platforms right

Like not every company in the world that's publishing NPM packages is using GitHub.

You know, they might have private repositories that might be publishing directly from their internal repositories and not having stuff out on GitHub or GitLab.

And then the other problem is that there's no two-factor authentication for trusted publishing.

And as a result, the OpenJS Foundation even came out and just said, for critical packages, we recommend that you don't use trusted publishing.

Because if somebody is able to get access to your GitHub repo, all of a sudden, they're going to be able to publish your packages and you won't know until it's too late.

So...

Trusted publishing is the beginning of a good solution.