build(deps): Bump actions/setup-go from 6.5.0 to 7.0.0

[dependabot]

Bumps actions/setup-go from 6.5.0 to 7.0.0.

Release notes

Sourced from actions/setup-go's releases.

v7.0.0

What's Changed

• Migrate to ESM and upgrade dependencies by @​priyagupta108 in actions/setup-go#763
• chore(deps): bump @​actions/cache to 6.2.0 by @​philip-gai in actions/setup-go#771

New Contributors

• @​philip-gai made their first contribution in actions/setup-go#771

Full Changelog: actions/setup-go@v6...v7.0.0

Commits

• b7ad1da chore(deps): bump @​actions/cache to 6.2.0 (#771)
• 0778a10 Migrate to ESM and upgrade dependencies (#763)
• See full diff in compare view

[lklimek]

Dependency Review — actions/setup-go 6.5.0 → 7.0.0

Verdict: compatible, but HOLD — this bump newly introduces a HIGH advisory into the action's bundled dist/.

Compatibility (major bump) — no breaking change for us

• action.yml is byte-identical between v6.5.0 and v7.0.0: same using: node24, same inputs, same outputs, cache still defaults true. The major version reflects an internal CommonJS→ESM migration, not a consumer-facing API change.
• Only 2 upstream commits: 0778a10 (ESM migration + dep uplift, Migrate to ESM and upgrade dependencies actions/setup-go#763) and b7ad1da (@actions/cache → 6.2.0, chore(deps): bump @actions/cache to 6.2.0 actions/setup-go#771).
• Our usage is minimal: only the go-version input, zero workflows consume the go-version / cache-hit outputs. All runners are GitHub-hosted ubuntu-*, so node24 is fine.
• CI on this PR already proves it works: "Successfully set up Go version 1.26.5".

Supply chain — clean

• Reproducible build confirmed. Checked out v7.0.0, ran npm ci && npm run build; the regenerated dist/setup/index.js and dist/cache-save/index.js are byte-identical to the committed bundles. No injected payload.
• Inlined wasm/emscripten blobs (crc64 via @azure/storage-blob) are byte-identical to v6.5.0's. No eval(. No new network hosts beyond doc/comment URLs from bundled deps. Every package-lock.json entry resolves to registry.npmjs.org with an integrity hash.
• No CVE/GHSA exists against actions/setup-go itself in either version.

Security finding — HIGH (newly introduced by this bump)

Advisory	GHSA-8r6m-32jq-jx6q — fast-xml-parser repeated-DOCTYPE entity-expansion limit reset (billion-laughs DoS)
Affected	>=5.9.3 <5.10.1 — patched in 5.10.1
Path	setup-go → @actions/cache@6.2.0 → @azure/storage-blob@12.32.0 → @azure/core-xml@1.5.1 → fast-xml-parser@5.9.3
Introduced here?	Yes. v6.5.0 bundles fast-xml-parser@5.8.0, which is below the affected floor. Verified with npm audit --omit=dev at both tags.
Fix available?	No. The advisory was published 2026-07-21, five days after v7.0.0 shipped, and setup-go freezes 5.9.3 into its committed dist/. Only an upstream setup-go rebuild (v7.0.1) resolves it.

Real-world exploitability in our CI is low: the parsed XML comes from the Azure Blob endpoints behind GitHub's Actions cache service, so exploitation requires MITM or a compromised GitHub cache backend, and the impact is a CI job hang/OOM — not RCE or secret disclosure. Additionally, in build.yml, check-generated.yml, e2e.yml and govulncheck.yml, setup-go runs before actions/checkout, so caching silently no-ops there (##[warning]Restore cache failed: Dependencies file is not found) and the affected code path is never reached. Only lint.yml, tests.yml and release.yml exercise it.

Note that Dependabot's github-actions ecosystem does not scan transitive npm advisories inside an action's bundled dist/ — nothing would have flagged this automatically.

Recommendation

Since v7.0.0 is functionally identical to v6.5.0 for our usage, there is no benefit to merging now and a small net-negative on the dependency-security axis. Suggest holding ~1–2 weeks for a v7.0.1 that refreshes fast-xml-parser to >=5.10.1, then merging. Merging now is also defensible given the low exploitability — flagging for a human call rather than auto-merging.

On the red govulncheck check — unrelated to this PR

The failure is GO-2026-6061 in google.golang.org/grpc@v1.82.0 (xDS RBAC engine / HTTP/2 server transport), not a stdlib crypto/tls issue, and not something a rebase fixes — v1.6-dev and this PR head both already carry go 1.26.5, and both still pin grpc v1.82.0. It reproduces identically on the base branch and is call-reachable from cmd/priv_val_server/main.go, abci/server/grpc_server.go and abci/client/grpc_client.go.

#1392 (grpc 1.82.0 → 1.82.1) is the fix and should be merged first — it unblocks govulncheck for this PR and every other open PR.

Pre-existing issues spotted nearby (not blocking, worth a follow-up)

1. .github/actions/bls/action.yml pins actions/setup-go@v2 — an ancient, unmaintained major. Dependabot never bumps it because .github/dependabot.yml only registers directory: "/" for the github-actions ecosystem, which does not cover composite actions under .github/actions/. It also pins Go 1.26.4 (inconsistent with 1.26.5 elsewhere) and uses the disabled ::set-output command.
2. Moving setup-go after actions/checkout in build.yml / check-generated.yml / e2e.yml / govulncheck.yml would make module caching actually work — a free CI speedup.
3. build.yml, e2e.yml, lint.yml, tests.yml and especially release.yml have no permissions: block and fall back to the repo default; an explicit contents: read (plus a narrow grant for GoReleaser in release.yml) would bound the blast radius of any compromised action.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

[lklimek]

Update — govulncheck is now unblockable via rebase

Follow-up to my review above. Confirmed:

• This PR head (467978c) sits on b25cd5c ("chore: bump Go to 1.26.5 (chore: bump Go to 1.26.5 #1395)"), which predates the v1.6-dev merge of build(deps): Bump google.golang.org/grpc from 1.82.0 to 1.82.1 #1392.
• build(deps): Bump google.golang.org/grpc from 1.82.0 to 1.82.1 #1392 (grpc v1.82.0 → v1.82.1, fixing GO-2026-6061) merged at 16:15 UTC as 2e12505; v1.6-dev go.mod now pins google.golang.org/grpc v1.82.1.
• So the red govulncheck is a stale-base artifact, not caused by this actions/setup-go bump — a rebase clears it. If it still fails after the rebase, that would be a genuinely new finding and worth a fresh look.

Requesting a rebase to get a clean signal.

⚠️ Note: clearing CI does not clear the HOLD recommendation in my review above — that rests on GHSA-8r6m-32jq-jx6q (fast-xml-parser@5.9.3 newly pulled into the action's bundled dist/ by v7.0.0, no upstream fix yet). Green CI and the merge decision are independent here; leaving the latter to a human.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

[lklimek]

@dependabot rebase