fix(ci): JS-DevTools/npm-publish + OIDC claims debug - #10
Conversation
After confirmed-failing attempts with vanilla 'npm publish --provenance' on npm 11.14.1 (ENEEDAUTH despite OIDC env vars), switch to JS-DevTools/npm-publish@v3 which is the action used by zod / vite / other major OSS for OIDC trusted publishing. Battle-tested for this exact flow. Also adds a one-time debug step that decodes the GitHub OIDC token to print the claims (repository, workflow, ref, sub) — if trusted publisher config on npm doesn't exactly match these, that's our smoking gun.
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
📝 WalkthroughWalkthroughThe release workflow is updated to support npm trusted publishing. A new step decodes the GitHub Actions OIDC token and logs JWT claims for validation. The publish invocation switches from an inline npm command to the Changesnpm Trusted Publishing Setup
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Around line 115-118: Replace the mutable tag reference to the third-party
action used in the workflow (the uses entry "JS-DevTools/npm-publish@v3") with a
full commit SHA to pin the action; update the uses value to
"JS-DevTools/npm-publish@<full-commit-sha>" (obtain the SHA from the action
repo), commit that change, and consider adding a note to track updates via
Dependabot or similar so future upgrades are managed safely.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e2920132-9ef7-4ca1-9a71-5fae9b76ce52
📒 Files selected for processing (1)
.github/workflows/release.yml
| uses: JS-DevTools/npm-publish@v3 | ||
| with: | ||
| provenance: true | ||
| access: public |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/release.yml | sed -n '100,130p'Repository: charfeng1/opencode-ralph-loop
Length of output: 1659
🏁 Script executed:
cat -n .github/workflows/release.yml | sed -n '1,150p'Repository: charfeng1/opencode-ralph-loop
Length of output: 6172
🌐 Web query:
GitHub actions security hardening pin action full commit SHA third-party
💡 Result:
Pinning GitHub Actions to a full-length commit SHA is a critical security best practice for supply chain hardening [1][2][3]. Because version tags (e.g., @v4) and branch references (e.g., @main) are mutable, they can be updated or force-pushed by an action maintainer—or a malicious actor who compromises the maintainer's account—to point to different, potentially malicious code at any time [4][5][6]. Why Pinning to a Full Commit SHA is Necessary: - Immutability: A full-length (40-character) commit SHA uniquely identifies a specific state of a repository [5][7]. Once pinned, the code executed by your workflow cannot be altered, ensuring consistency and reproducibility [7][6]. - Mitigation of Supply Chain Attacks: If an action's repository is compromised, pinning prevents your workflows from automatically pulling in injected malicious code [7][2]. An attacker would need to generate a SHA-1 collision to replace the pinned code, which is computationally infeasible [5][2]. - Organizational Policy: GitHub allows administrators to enforce full commit SHA pinning at the organization or repository level [1][2]. When enabled, workflows referencing actions by mutable tags will fail, forcing compliance across the dependency tree [1]. Best Practices for Implementation: - Use Full SHAs: Always use the full 40-character SHA, not a shortened version [5]. - Verify Sources: Ensure the SHA originates from the official action repository, not a fork [5][2]. - Maintainability: To manage updates, use automated dependency management tools like Dependabot or Renovate [1][5][6]. You can include the version tag as a comment in your workflow file to make it easier to track which version the SHA corresponds to (e.g., uses: actions/checkout@a12b34... # v4.1.1) [8][5][6]. - Audit Dependencies: Pinning is one layer of defense; you should also audit the source code of third-party actions and limit their use to trusted publishers [2][3][9]. Note: While pinning is essential, it should be part of a broader security strategy that includes limiting token permissions, using OIDC for secrets, and auditing workflow configurations [10][3][11].
Citations:
- 1: https://www.romainlespinasse.dev/posts/github-actions-commit-sha-pinning/
- 2: https://docs.github.com/en/actions/how-tos/security-for-github-actions/security-guides/security-hardening-for-github-actions
- 3: https://www.truesec.com/hub/blog/tips-for-supply-chain-security-in-ci-cd-mitigating-risks-from-third-party-github-actions
- 4: https://dev.to/kanywst/hacking-github-from-tag-rewrites-to-dangling-commits-where-the-git-protocol-trusts-you-without-2o4h
- 5: https://github.com/ihs7/action-sha-pinned-actions
- 6: https://blog.rafaelgss.dev/why-you-should-pin-actions-by-commit-hash
- 7: https://www.stepsecurity.io/blog/pinning-github-actions-for-enhanced-security-a-complete-guide
- 8: Pin all GitHub Actions to immutable SHA commits for supply chain security github/gh-aw#5691
- 9: https://www.stepsecurity.io/blog/third-party-github-actions-governance-best-practices
- 10: https://www.aikido.dev/blog/checklist-github-actions
- 11: https://dev.to/sahil_kat/hardening-claude-code-in-github-actions-after-the-cvss-94-cve-3id5
Pin this third-party action to a full commit SHA.
The JS-DevTools/npm-publish@v3 action is currently referenced by a mutable version tag. GitHub's security guidance recommends pinning third-party actions to full-length commit SHAs for supply chain hardening, especially in jobs with elevated permissions like this one (which has contents: write and id-token: write). Version tags can be force-pushed or compromised; only full commit SHAs are immutable and cannot be altered retroactively. Consider using a tool like Dependabot to manage updates.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/release.yml around lines 115 - 118, Replace the mutable
tag reference to the third-party action used in the workflow (the uses entry
"JS-DevTools/npm-publish@v3") with a full commit SHA to pin the action; update
the uses value to "JS-DevTools/npm-publish@<full-commit-sha>" (obtain the SHA
from the action repo), commit that change, and consider adding a note to track
updates via Dependabot or similar so future upgrades are managed safely.
1 participant
Vanilla npm publish on npm 11.14.1 returns ENEEDAUTH even with OIDC env vars + --provenance flag. Switch to JS-DevTools/npm-publish@v3 (zod / vite / etc use this for OIDC trust publishing). Adds one-time debug step that decodes the OIDC JWT to show claims being sent — if trust config on npm doesn't match, this will surface the mismatch.
Summary by CodeRabbit