ci: grant release.yml write scopes at the job level, not top level#98
Merged
Conversation
release.yml declared contents/id-token/attestations write at the top level, so
OpenSSF Scorecard's Token-Permissions check scored 0 ("detected GitHub workflow
tokens with excessive permissions") — a top-level write applies to every job.
Move the three write scopes onto the single pack-push job that uses them and keep
the top-level token read-only (contents: read). Behaviour is unchanged (the one
job gets exactly the same permissions), but the workflow now follows the
least-privilege shape the check rewards. English and French maintainer notes kept
in sync.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_014W1zrcBNy3jEs8ngAQKwZg
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes OpenSSF Scorecard's Token-Permissions check, which scored 0 ("detected GitHub workflow tokens with excessive permissions"). The only offender was
release.yml, which declaredcontents/id-token/attestations: writeat the top level — a top-level write applies to every job, which the check flags as excessive.release.ymlhas a single job (pack-push), so the three write scopes are moved onto that job and the top-level token is left read-only (contents: read). Behaviour is identical; the workflow now follows the least-privilege shape (top-level read, writes granted per job) the check rewards.dependabot-automerge.ymlalready follows this pattern (top-level read, job-level write genuinely needed forgh pr merge --auto) and is left untouched.Note: confirmation comes from the next
scorecardrun onmain. The top-level write was the 0-driver, so this should lift the check substantially (job-level writes are the documented remediation).Type of change
Changes
release.yml: top-levelpermissionsset tocontents: read;contents: write,id-token: write,attestations: writemoved onto thepack-pushjob (comments preserved).maintainers/workflows/release.{en,fr}.md: "Permissions & security" section updated to note the top-level-read / per-job-write structure.Testing
dotnet build FirstClassErrors.sln— not relevant (workflow-config change only; no solution code touched).dotnet test FirstClassErrors.sln— not relevant.release.ymlparses as YAML and that the effective permissions are unchanged for thepack-pushjob. The release workflow itself runs only on version tags, so it is not exercised by this PR (its logic is rehearsed separately byrelease-dryrun).Documentation
doc/updateddoc/README.fr.md) updated if user-facing behavior changedrelease.en.md/release.fr.md) were kept in sync with the permission restructure.Related issues
None.
🤖 Generated with Claude Code
https://claude.ai/code/session_014W1zrcBNy3jEs8ngAQKwZg
Generated by Claude Code