ci: pin GitHub Actions to full commit SHAs - #1646
Conversation
Every external action in `.github/` is now referenced by a 40-character commit SHA with the release tag as a trailing comment, so a compromised or retagged upstream release cannot silently change what runs in CI. 78 `uses:` refs across 15 files are covered; in-repo `./.github/...` composite-action and reusable-workflow refs are left as tags since they are not a supply-chain surface. Each SHA was resolved from the tag the workflow already floated on and re-verified against the GitHub API, so this is behaviour-preserving. Two exceptions worth calling out: - `pnpm/action-setup@v4` is pinned to v4.3.0, not v4.4.0. Upstream's `v4.4.0` tag points at the same commit as `v5.0.0`, while the floating `v4` tag still resolves to v4.3.0 — pinning to v4.4.0 would silently jump a major. - `actions/checkout@v3` and `actions/create-github-app-token@v1` are pinned at their latest v3/v1 SHAs rather than bumped to v4/v2, keeping this change to pinning alone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
PR SummaryLow Risk Overview
There is still no Dependabot Reviewed by Cursor Bugbot for commit acef336. Bugbot is set up for automated code reviews on this repo. Configure here. |
Package ArtifactsBuilt from 4b05e8f. Download artifacts from this workflow run. JS SDK ( npm install ./e2b-2.38.1-pin-actions-to-sha.0.tgzCLI ( npm install ./e2b-cli-2.16.2-pin-actions-to-sha.0.tgzPython SDK ( pip install ./e2b-2.37.0+pin.actions.to.sha-py3-none-any.whl |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit d694898. Configure here.
| steps: | ||
| - name: Filter changed paths | ||
| uses: dorny/paths-filter@v3 | ||
| uses: dorny/paths-filter@0e4a8c6effa4802afeda77dc8d303f8176d7dfad # v3.0.4 |
There was a problem hiding this comment.
Invalid paths-filter SHA breaks CI
High Severity
dorny/paths-filter has no v3.0.4 release or commit at this SHA. GitHub cannot download the action, so change detection fails in four workflows and blocks their downstream checks.
Additional Locations (2)
Reviewed by Cursor Bugbot for commit d694898. Configure here.
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — mechanical CI hardening PR pinning GitHub Actions refs to commit SHAs, no logic changes.
Extended reasoning...
Overview
This PR touches only .github/actions/build-cli/action.yml and 14 workflow files under .github/workflows/, replacing every floating tag reference (e.g. @v4, @v3) on third-party GitHub Actions with a pinned 40-character commit SHA plus a trailing # vX.Y.Z comment. No workflow logic, trigger conditions, permissions, secrets usage, or job structure is changed — only the uses: lines are rewritten.
Security risks
This is itself a security-hardening change (protects against a compromised/retagged upstream action silently changing behavior in CI), not a risk-introducing one. I verified that every action@sha # version pin in the resulting files is internally consistent — the same action+version always maps to the same SHA everywhere it appears, and the two cases with two different SHAs for the same action (actions/checkout at v3.7.0 vs v4.4.0, actions/create-github-app-token at v1.12.0 vs v2.2.2) correspond to genuinely different pre-existing major versions used in different files, matching the PR description. I could not reach api.github.com from this sandbox to independently re-verify each SHA against the tag it claims, so I cannot confirm the resolution was correct at the byte level, but the change is structurally sound and behavior-preserving by construction (no version bumps, comments retained).
Level of scrutiny
Low-to-medium. This is CI-only config with no effect on runtime/production code paths, but it does touch the supply chain for release and publish workflows (publish_packages.yml, release.yml) which have write/publish permissions. The change is mechanical and uniform across files (78 refs, same pattern each time), which lowers risk of a subtle logic bug, but a determined reviewer with GitHub API access should still spot-check a handful of the higher-privilege pins (checkout/create-github-app-token in the publish workflows) against upstream tags before merging.
Other factors
No SDK/CLI package is touched, so the missing changeset is expected and correct per the PR description. No outstanding review comments need addressing (only automated changeset-bot and cursor bot summary comments are present). The PR description proactively flags the two version-pin nuances (pnpm/action-setup and the deliberate non-bump of checkout/create-github-app-token majors), which matches the diff.
The Dependabot changeset workflow was the one place already pinned, at v3.0.4's predecessor v3.0.3, leaving the repository with two SHAs for the same action. Move it to v3.0.4 to match every other workflow. Its comment justified the pin as being "rather than floating on `v3`", which no longer distinguishes it now that every action is pinned; the note about the `pull_request_target` trigger is the part still worth keeping, so it is rewritten to say why that makes this pin more sensitive than most. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
Every external action in
.github/is now referenced by a 40-character commit SHA with the release tag as a trailing comment, so a compromised or retagged upstream release cannot silently change what runs in CI — this covers 78uses:refs across 15 files, leaving in-repo./.github/...composite-action and reusable-workflow refs as-is since they are not a supply-chain surface. Each SHA was resolved from the tag the workflow already floated on and re-verified against the GitHub API, so the change is behaviour-preserving; all 15 files were also re-checked as valid YAML.Two pins are worth a reviewer's attention:
pnpm/action-setupis pinned to v4.3.0, not v4.4.0. Upstream'sv4.4.0tag points at the same commit asv5.0.0, while the floatingv4tag we were on still resolves to v4.3.0 — pinning to v4.4.0 would have silently jumped a major.actions/checkout@v3andactions/create-github-app-token@v1are pinned at their latest v3/v1 SHAs rather than bumped to v4/v2, keeping this PR to pinning alone; bumping those majors is a good follow-up.A second commit unifies
dorny/paths-filter, which was the one action already pinned (at v3.0.3 in the Dependabot changeset workflow) and would otherwise have left the repo carrying two SHAs for the same action; its comment justified the pin as being "rather than floating onv3", which no longer distinguishes it now that everything is pinned, so it is rewritten to keep only the still-relevantpull_request_targetwarning.One gap this PR does not close: there is no
.github/dependabot.ymlin the repo, so nothing will keep these SHAs current and they will drift away from upstream security fixes — adding agithub-actionsecosystem entry (which understands SHA pins with version comments and bumps both) is worth doing separately. No SDK or CLI package is touched, so no changeset is needed.🤖 Generated with Claude Code