4 ms·
You shouldn't have any keys anywhere at all. Use OIDC https://docs.npmjs.com/trusted-publishers https://docs.npmjs.com/trusted-publishers Unfortunately you nee
by madeofpalk 11mo ago
You shouldn't have any keys anywhere at all. Use OIDC https://docs.npmjs.com/trusted-publishers https://docs.npmjs.com/trusted-publishers
Unfortunately you need to `npm login` with username and password in order to publish the very first version of a package to set up OIDC.
- c-hendricks 11mo agoA whole single supported CI partner outside their own corporate family. They really planned this out well.
- twistedpair 11mo agoI'm struggling to understand why Trusted Publishers is any better. Let's say you have a limited life, package specific scoped, IP CIDR bound publishing key, running on a private GH workflow runner. That key only exists in a trusted clouds secret store (e.g. no one will have access it from their laptop). Now let's say you're a "trusted" publisher, running on a specific GitHub workflow, and GitHub Org, that has been configured with OIDC on the NPM side. By virtue of simply existing in that workflow, you're now a NPM publisher (run any publish commands you like). No need to have a secret passed into your workflow scope. If someone is taking over GitHub CI/CD workflows by running `npm i` at the start of their workflow, how does the "Trusted Publisher" find themselves any more secure than the secure, very limited scope token?