feat(mcp): bind npm publishing to a tag-restricted environment - #359
Conversation
npm's trusted-publisher form takes an optional environment name and checks it as an OIDC claim, so it only works if the job declares the same one. Adds `environment: npm-publish` to publish-npm and creates that environment restricted to the `v*` tag pattern, so publishing to npm cannot be reached from a branch push. Deliberately not the existing `release` environment: it is scoped to the `main` branch, and this job runs on a tag ref, so pointing npm at it would have rejected every publish. Documents the exact field values for the npm form in dev-docs/CI.md (including choosing the strictest Publishing access option, which is safe because trusted publishers are exempt), and records in SECURITY_ASSURANCE.md that npm publication now holds no credential. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bomly Diff SummaryCompared Overview
Dependency Changes✅ No dependency changes. Vulnerabilities✅ No vulnerability changes. License Changes✅ No license changes. Project Posture✅ No project posture changes ( Policy Findings✅ No policy differences were identified. |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe release workflow now uses a dedicated npm publishing environment. CI documentation defines trusted-publisher settings, and security documentation records OIDC, tag, 2FA, token, and MCP publisher verification controls. ChangesNPM publishing controls
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Follow-up to #339, which merged while this was being written.
Why
npm's trusted-publisher form has an optional Environment name field. npm checks it as an OIDC claim, so it only works if the workflow job declares the same environment — and if you set it on npm without the job declaring it, publishing fails.
It is worth setting. Without an environment, the trust grant is "any run of
release.ymlin this repo may publish to npm". With one, it is "any run ofrelease.ymlthat reaches thenpm-publishenvironment" — and that environment is restricted to thev*tag pattern, so a push to any branch cannot reach npm.The trap this avoids
The obvious choice would be the existing
releaseenvironment. That would have broken every publish:releaseis scoped to themainbranch, andpublish-npmruns on a tag ref, so the deployment would be rejected outright. It also carries a required reviewer and a 5-minute wait timer, which are right for cutting a release but wrong for a step inside one.Hence a separate
npm-publishenvironment, already created on the repo:npm-side settings
Documented in
dev-docs/CI.mdso they are not lore:bomly-dev/bomly-clirelease.ymlnpm-publishnpm publishonly — we do not usenpm stage publish, so the grant stays minimalAlso records in
SECURITY_ASSURANCE.mdthat npm publication now holds no credential of any kind, alongside whymcp-publisheris pinned and signature-verified.Status
bomly-mcp@0.21.1is already live on npm from the one-time manual bootstrap, so the package exists and the trusted publisher can be configured. This PR is what makes the Environment field safe to fill in.🤖 Generated with Claude Code
Summary by CodeRabbit
Security
Documentation