Having to look up all these UUIDs for CircleCI Organization, Project, Pipeline, and contexts is a PITA. You wouldn’t like it either if you had dozens and dozens of packages to migrate to trusted publishing.
It’s painful to be paying for CircleCI but have a second-class experience integrating with npm.
Can you give us a CLI helper tool that looks up all the CLI arguments to pass to npm trust or something?
I did manage to whip up a helper tool pretty quickly with AI, though the npm trust call to npm’s API is 400ing without any error message 
But regardless, it’s a shame how much less convenient npm trust circleci is than npm trust github or npm trust gitlab, since only user slugs for org and repo need to be passed for github/gitlab, and no API calls are needed to look those up.
hey andy. yeah, i will look into if we can make it a bit more straightforward to do it via cli.
Unfortunately, npm is a privately held service, and we are at their mercy wrt how integration works.
Feel free to drop by the discord if you wanna talk nuts and bolts about this. Would love to see what helper tool you have whipped up.
Okay sure, where is the discord? Yeah I’m happy to share the script.
I assumed the decision to put all these UUIDs into the claims presented by the OIDC token was CircleCI’s decision, but maybe it was npm’s. Everything about npm’s trusted publishing API has been a mess so far…I worked through the previous issues but now when npm tries to exchange the token the registry API is saying the package doesn’t exist (it’s a public package 
)
You can join the discord at https://discord.gg/circleci
Re: uuids into claim - that was CCI decision. UUIDs are the best representaiton of unique identifiers, since names of things can change.
The issue is around looking up details. I suspect github is able to do what it does (since its a black box, ii’m guessing) is lookup details like IDs based on the string values and then insert those into their db?
I will be looking at how I can make it easier for people in your situation of having many.
The docs for our site are just being reviewed right now. Here is an example I put together that will accompany them, and is working if this helps. sign-and-publish-examples/npm at main · CircleCI-Public/sign-and-publish-examples · GitHub
talk soon
Sorry for the delay. I don’t use discord much, what channel do you want me to discuss this in?
I suspect github is able to do what it does (since its a black box, ii’m guessing) is lookup details like IDs based on the string values and then insert those into their db?
I don’t think GitHub looking up ids would be of any use. In the trusted publishing config in npm, users only enter the names of GitHub/GitLab resources afaik. For that config to survive renames, npm itself would have to look up and store the underlying ids using the GitHub/GitLab API. Many of these resources are private so GitHub/GitLab would have to give npm some kind of exclusive access for the sake of looking up ids…I really doubt they do that. Probably npm just compares the configured names to claims in the OIDC token from GitHub or GitLab, and it would break if the user renames any resources (meaning they’d just have to update the trusted publishing config in npm).
I guess the only other option would be if GitHub/GitLab include both names and ids in the claims, npm stores the id if the name matches, and then only compares to the stored id until the user changes the trusted publishing config. But to users it would appear to be insecure if npm accepts publishes from renamed resources that no longer match the names visible in the trusted publishing config, so I doubt they do this either. I guess they could update the name in the visible config if the name changes in the token sent over but now I’m reaaaally speculating.
UUIDs are the best representaiton of unique identifiers, since names of things can change
Personally I would be happier with the option to just put the desired names in the trusted publishing config in npm, and have CCI send over names of things in the claims for npm to verify. I rarely rename anything so this would be far more convenient for me.
Hypothetically, the token from CCI could include both UUIDs and names so that npm could give us the choice between entering names or UUIDs in the trusted publishing config.
no worries.
join the circle ci discord (https://discord.gg/circleci) and in general is fine. I’m Mitchell | CCI there.
I think the use of IDs would be to avoid ressurection attacks. I know thats the underlying mechanism for pypi for example (you give the string, it looks up the actual ID and stores it). Can only speculate how npm works.
We went with UUIDs in our claims. While I get you rarely rename things, we are doing things for a broader audience. Again, resurrection attacks are a real concern, so using uuids was partly to defend against this. And UUIDs for resources makes sense for me.
In any case, I know you have a bunch of repos to do. I am putting together a tool.
It works for single use case. It should work for bulk - i am planning to finish testing over the weekend.
But if you want to try it early before the ‘official’ launch, you are welcome to try it out - GitHub - CircleCI-Public/npm-trusted-publishing-tool at add-npm-trusted-publishing-cli · GitHub
Note: once I merge it I intend to publish the bins so you wouldn’t have to build it yourself. But building a go project it pretty straightforward operation.
@jedwards1211 Hey Andy, so tested, it worked for me publishing multiple projects. Sorry if its come too late for you. If it hasn’t, please give it a shot (i’ll go build some bins, but if you are comfy with go it should be easy to just build your own from the repo)
feel free to reach out if you have any issues