Raised by the automated reviewer on #142 when actions/checkout was bumped from v2 to v4, and deferred there because pinning a single step in isolation would not have changed the actual security posture. Recording it so the idea is not lost in a merged pull request's review thread.
The concern
Workflows reference actions by moving tag (actions/checkout@v4, actions/upload-artifact@v4, and so on). A tag can be repointed by whoever owns the action, so the code executing in CI can change without any pull request to this repository. Pinning to an immutable commit SHA removes that, and is the hardening measure GitHub itself recommends.
Why it was not done in #142
Two reasons, both still true:
- Partial pinning buys nothing. Actions are referenced by tag throughout this repository, so pinning one step would leave every other entry point unchanged.
- The largest surface is not in this repository.
.github/workflows/test.yml delegates to psake/.github/.github/workflows/ModuleCI.yml@main — a moving ref on a different repository, which in turn runs its own actions. Pinning here while the shared workflow floats on @main addresses the smaller half of the problem.
Scope to decide
- Whether to pin at all, given the maintenance cost (a SHA pin is unreadable without a trailing
# v4.2.2 comment, and needs updating for every action release).
- Whether to enable Dependabot for the
github-actions ecosystem, which raises pull requests to bump pins and makes the cost manageable. This is the usual prerequisite for pinning being sustainable.
- Whether to coordinate with the
psake/.github repository so the shared ModuleCI.yml is pinned too, and whether callers should reference it by tag rather than @main. That part needs an org owner.
Not blocking v1.0.0
Deliberately unmilestoned. This is repository and organization infrastructure, not part of the shipped module's public API, so it does not gate the 1.0.0 release and can land at any point.
Related
Raised by the automated reviewer on #142 when
actions/checkoutwas bumped fromv2tov4, and deferred there because pinning a single step in isolation would not have changed the actual security posture. Recording it so the idea is not lost in a merged pull request's review thread.The concern
Workflows reference actions by moving tag (
actions/checkout@v4,actions/upload-artifact@v4, and so on). A tag can be repointed by whoever owns the action, so the code executing in CI can change without any pull request to this repository. Pinning to an immutable commit SHA removes that, and is the hardening measure GitHub itself recommends.Why it was not done in #142
Two reasons, both still true:
.github/workflows/test.ymldelegates topsake/.github/.github/workflows/ModuleCI.yml@main— a moving ref on a different repository, which in turn runs its own actions. Pinning here while the shared workflow floats on@mainaddresses the smaller half of the problem.Scope to decide
# v4.2.2comment, and needs updating for every action release).github-actionsecosystem, which raises pull requests to bump pins and makes the cost manageable. This is the usual prerequisite for pinning being sustainable.psake/.githubrepository so the sharedModuleCI.ymlis pinned too, and whether callers should reference it by tag rather than@main. That part needs an org owner.Not blocking v1.0.0
Deliberately unmilestoned. This is repository and organization infrastructure, not part of the shipped module's public API, so it does not gate the 1.0.0 release and can land at any point.
Related
actions/checkoutv2 → v4 bump where this came up (review thread)