ci(release): add the 'id-token' permissions#948
Conversation
This is mentioned in the python-semantic-release documentation
There was a problem hiding this comment.
Pull request overview
This pull request adds the id-token: write permission to the release workflow, citing python-semantic-release documentation as the rationale.
Changes:
- Added
id-token: writepermission to the release job in the GitHub Actions workflow
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| permissions: | ||
| contents: write | ||
| id-token: write |
There was a problem hiding this comment.
The id-token: write permission is typically used for PyPI trusted publishing with OIDC tokens, Sigstore signing, or authentication with cloud providers. Based on the workflow steps, none of these features appear to be in use:
- This is a PHP project (composer.json), not a Python package
- The workflow only creates GitHub releases and uploads assets
- No PyPI publishing, Sigstore signing, or cloud authentication is configured
Adding this permission increases the attack surface without apparent benefit. Could you clarify which specific step in this workflow requires the id-token permission? If it's not actively being used, consider removing it to follow the principle of least privilege.
If the documentation recommends this for future features or specific configurations, please verify that those features are actually enabled in your releaserc.toml configuration.
| id-token: write |
|
|
||
| permissions: | ||
| contents: write | ||
| id-token: write |
There was a problem hiding this comment.
The release-dry-run.yml workflow (which uses the same python-semantic-release action) does not include the id-token: write permission. For consistency and to maintain the principle of least privilege, both workflows should have the same permissions unless there's a specific reason for the difference. If id-token is needed for release.yml, consider whether it's also needed for release-dry-run.yml, or vice versa.
This is mentioned in the python-semantic-release documentation