Summary
The release and GPG workflows currently execute third-party GitHub Actions using mutable tag references. These jobs handle sensitive release material, including GPG signing keys, passphrases, and release/publish tokens. If an upstream action tag is moved or the upstream action repository is compromised, the next workflow run could execute attacker-controlled code with access to signing and publishing credentials.
Affected workflow references
Required changes
Pin GitHub Actions to immutable commit SHAs instead of major/minor/release tags, and pin the GoReleaser binary version instead of using latest.
Recommended current pins:
uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
uses: actions/setup-go@4a3601121dd01d1626a1e23e37211e3254c1c06c # v6.4.0
uses: crazy-max/ghaction-import-gpg@2dc316deee8e90f13e1a351ab510b4d5bc0c82cd # v7.0.0
uses: goreleaser/goreleaser-action@5daf1e915a5f0af01ddbcd89a43b8061ff4f1a89 # v7.2.2
Replace:
with:
For .github/workflows/gpginfo.yaml, either pin the existing HashiCorp fork:
uses: hashicorp/ghaction-import-gpg@78437f97569a473e42b227be84d4084c2dfb49ba # v2.1.0
or migrate it to the maintained crazy-max/ghaction-import-gpg action if compatibility allows.
Security rationale
Tag refs such as @v5, @v3, and even exact release tags like @v3.0.0 are mutable Git refs. GitHub Actions resolves them at workflow runtime. If an upstream maintainer account or repository is compromised and the tag is retargeted, this repository will run whatever code the tag points to during the next release workflow execution.
Pinning to a full commit SHA prevents tag retargeting from changing the code executed by the workflow.
This is especially important here because the affected workflows expose:
GPG_PRIVATE_KEYPASSPHRASE- release signing context
GITHUB_TOKEN- release artifact publishing capability
Acceptance criteria
- All
uses: entries in release/signing workflows are pinned to full 40-character commit SHAs.
- GoReleaser binary version is pinned to a fixed release, not
latest.
- Workflow still signs and publishes releases successfully.
- Dependabot/Renovate is configured, if available, to propose SHA-pinned action updates.
GITHUB_TOKEN permissions are minimized to only what the release job needs.
Summary
The release and GPG workflows currently execute third-party GitHub Actions using mutable tag references. These jobs handle sensitive release material, including GPG signing keys, passphrases, and release/publish tokens. If an upstream action tag is moved or the upstream action repository is compromised, the next workflow run could execute attacker-controlled code with access to signing and publishing credentials.
Affected workflow references
.github/workflows/release.yamlactions/checkout@v3actions/setup-go@v3crazy-max/ghaction-import-gpg@v5goreleaser/goreleaser-action@v3.0.0version: latestfor the GoReleaser binary.github/workflows/gpginfo.yamlhashicorp/ghaction-import-gpg@v2.1.0Required changes
Pin GitHub Actions to immutable commit SHAs instead of major/minor/release tags, and pin the GoReleaser binary version instead of using
latest.Recommended current pins:
Replace:
with:
For
.github/workflows/gpginfo.yaml, either pin the existing HashiCorp fork:or migrate it to the maintained
crazy-max/ghaction-import-gpgaction if compatibility allows.Security rationale
Tag refs such as
@v5,@v3, and even exact release tags like@v3.0.0are mutable Git refs. GitHub Actions resolves them at workflow runtime. If an upstream maintainer account or repository is compromised and the tag is retargeted, this repository will run whatever code the tag points to during the next release workflow execution.Pinning to a full commit SHA prevents tag retargeting from changing the code executed by the workflow.
This is especially important here because the affected workflows expose:
GPG_PRIVATE_KEYPASSPHRASEGITHUB_TOKENAcceptance criteria
uses:entries in release/signing workflows are pinned to full 40-character commit SHAs.latest.GITHUB_TOKENpermissions are minimized to only what the release job needs.