There are about a hundred ways we could skin this cat. And while I think it is way more complicated than just "is it broken or malicious" I agree that fundamentally we need more clear contracts on what the public registry *is for* and what it is not.

It was great working with you on this! As much as I dislike that we had to do this work, I think it is important that we did it so there is a thorough and accurate resource about the current state of things.

I am looking forward to doing that together with partners at @npmjs.bsky.social, @github.com, @openjsf.org, and @openssf.org in the future.

But, as the largest and highest impact package registry on the planet, our community has an important role in also being a leader. I don't believe our current model is working, and I hope we can fix it. But for now, I will just settle for us slowing down and being smart about changes we roll out.

If nothing else, I would like to drive home the point that security is a spectrum and a process. *Not something you "solve" in a single way*.

We need better partnerships across our ecosystem with folks at the @openssf.org and other registries so that we can improve together.

This has been an exceedingly difficult message to put together because of the complexity/gaps in existing workflows, but also because we have had to be sensitive about publicly sharing details that may lead to increased risk of compromise for popular packages that have already moved to TP

We do not recommend critical projects move to this new workflow, but instead focus on hardening their existing workflows. At least until the situation with CI publishing settles and we can all move forward with OIDC publish.

TLDR:

Gaps in design and implementation with the new OIDC Trusted Publisher workflows leave maintainers open to novel and increasingly difficult to detect gaps in their publishing setups.

The new setup really falls apart if you start from “how can I replicate shai hulud or the Nx attack” and follow the trail.

Yep, it’s gaps like this that are where I am positive folks have not fully thought through the threat model for this new publishing method.

We will be publishing a statement soon, and while the audience is broad and so the messaging is not in the weeds enough for folks like us, I would be happy to have this again in the Node.js Security WG for folks in the project that missed our collab summit session on the topic.

The topic is nuanced, and it depends very much on what you were doing *before* you moved to OIDC publish for specifics, and this is not the place for a nuanced discussion like that. I have had such discussions (like at the recent node.js collab summit), and am not the only one with this opinion.

I have, and I wish there were 30 hours in a day and that I didn't have a job to keep up with so I could help *fix* the problems in the new system. Instead I have been using my limited time to organize a community response, while hopefully being sensitive to the risk of impact to our ecosystem.

Agreed that security is *always* a spectrum. I think that most folks repeating this line have not actually dug into the threat model and details of the OIDC/TP implementation enough to realize this, it is just too new for everyone to have gotten up to speed on.

It’s not more safe tho. So just keep that in mind.

Yeah, forgetting to handle an error is always a big, and ESLint is the perfect tool for bug squashing like this!

I can’t link to my tweet from 2016 without logging into my Twitter account. So I’m just gonna have to repeat it here.

const [resp, err] = await thing();

Sorry, didn't mean to imply you were. I am saying that anyone adding one should re-think the problem. I was not following the discussion, but was this brought up when @nodejs.org was considering it?

As long as folks know about this requirement, I think it is alright, but adding an ignore for this seems dangerous.