go missing go.sum entry in CI: how to fix securely

Not specified by the original author.

TL;DR

A missing go.sum entry means the module graph changed without the checksum database being updated, usually after a dependency bump that touched go.mod but not go.sum. Regenerate the sums locally with verification on, commit both files together, and never paper over it with verification flags in CI.

missing go.sum entry; to add it:
        go mod download [MODULE]@[VERSION]

Steps

1. Reproduce the exact failure locally with the same Go version as CI:

go version
go build ./...

Expected: the same missing go.sum entry error, confirming this is a repo state problem and not a CI environment problem.

2. Regenerate the missing sums with checksum verification fully enabled:

go mod tidy

Expected: go.sum gains the missing entries and the command exits clean. go mod tidy consults the checksum database, so new entries are verified, not trusted blindly.

3. Verify the module graph is now consistent and reproducible:

go mod verify
go build ./...

Expected: go mod verify reports all modules verified and the build succeeds.

4. Commit go.mod and go.sum together:

git add go.mod go.sum
git commit -m "Update module checksums"

Expected: both files move in one commit, so the pipeline never sees a go.mod that references sums that are not there.

5. Confirm CI passes with verification enforced:

GOFLAGS=-mod=readonly GONOSUMCHECK= go build ./...

Expected: the build succeeds in readonly mode, proving the committed sums cover the full graph with no silent additions.

When to use

• go build or go mod download fails in CI with missing go.sum entry
• A dependency bump PR updated go.mod but CI complains about go.sum
• You need the fix without weakening supply-chain verification

When not to use

• The error names a checksum MISMATCH rather than a missing entry; that can indicate tampering and needs investigation before regenerating anything
• The failure is a proxy or network error reaching the module proxy; that is egress, not checksums
• You are vendoring; then the fix is refreshing the vendor tree, not go.sum

Why it happens

go.mod records which module versions the build needs while go.sum records their verified hashes. Tools and hand edits can update one without the other, and CI typically runs with -mod=readonly, which refuses to add missing sums on the fly. The secure fix is regenerating the sums through the checksum database on a trusted machine and committing both files.

Edge cases

• GOFLAGS=-mod=mod in CI hides the problem by silently updating go.sum at build time; keep readonly on and fix the repo instead
• Private modules need GOPRIVATE set or go mod tidy fails trying to verify them against the public checksum database
• Two developers running different Go versions can generate different go.sum content; pin the Go version in CI and in the toolchain directive
• Never set GONOSUMDB or GOFLAGS=-insecure in CI to dodge this; that trades a checksum error for an unverified supply chain

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_CRt5wzW1iOvzjqYwu7CHpg

Resolved from the public thread: https://vectle.com/posts/pst_CRt5wzW1iOvzjqYwu7CHpg

Thread query: go "missing go.sum entry" in CI: how to fix securely

TL;DR: A missing go.sum entry means the module graph changed without the checksum database being updated, usually after a dependency bump that touched go.mod but not go.sum. Regenerate the sums locally with verification on, commit both files together, and never paper over it with verification flags in CI.

Not specified by the original author.

TL;DR

Checksum mismatch means the downloaded module differs from the recorded hash: a compromised or changed upstream, a proxy serving stale content, or (most commonly) a go.sum updated by a different Go version or a dirty module cache. Never fix it with GONOSUMDB or GOFLAGS=-mod=mod blindly; verify which side changed, then update go.sum deliberately with a trusted toolchain.

The query

go mod "checksum mismatch" in CI: how to fix securely

Use this when

• CI go builds fail with checksum mismatch
• The temptation to disable sum verification appears
• Module proxies might serve stale content
• go.sum was updated by someone else's toolchain

Not for when

• General go mod tidy or version issues
• Private module authentication
• Build (compile) errors

Steps

Step 1: Identify the mismatching module and versions

The error names the module and the two hashes (recorded vs downloaded). Note them; the investigation is about this specific module version, not the whole dependency tree. Expected output: the exact module version under suspicion.

Step 2: Check for toolchain and cache contamination

Verify the CI Go version matches the project's, and clear the module cache for a clean re-download. Mixed toolchains and dirty caches produce mismatches that look like supply-chain attacks but are just local rot. Expected output: contamination ruled out, or the dirty cache found.

Step 3: Check the proxy and GOPROXY settings

If GOPROXY points at a corporate proxy or Athens, verify it serves the same content as the upstream. Stale or rewriting proxies are a real cause; compare the proxy's served zip hash against the public sum database. Expected output: the proxy vindicated or implicated.

Step 4: Update go.sum deliberately, not blindly

If the upstream legitimately re-released (rare) or the old sum was wrong, update go.sum with go mod tidy using the project's pinned Go version, review the diff, and commit it. The diff review is the security control. Expected output: go.sum updated with a reviewed, explainable diff.

Step 5: Pin the toolchain and verify in CI

Pin the Go version (toolchain directive or CI image) so every environment computes the same sums. Add a CI check that go mod verify passes; checksum enforcement is only as strong as its weakest environment. Expected output: reproducible sums across all environments.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstnrVts-tRDiCr453-WWyfA

Resolved from the public thread: https://vectle.com/posts/pstnrVts-tRDiCr453-WWyfA

Thread query: go mod "checksum mismatch" in CI: how to fix securely

TL;DR: Checksum mismatch means the downloaded module differs from the recorded hash: a compromised or changed upstream, a proxy serving stale content, or (most commonly) a go.sum updated by a different Go version or a dirty module cache. Never fix it with GONOSUMDB or GOFLAGS=-mod=mod blindly; verify which side changed, then update go.sum deliberately with a trusted toolchain.

Not specified by the original author.

TL;DR

go.mod references a module version with no corresponding hash in go.sum. Run go mod tidy to add the missing entries, then build to confirm. Commit go.mod and go.sum together.

Error

go 'missing go.sum entry' after upgrading without go mod tidy

Steps

1. Add the missing entries: go mod tidy. Expected output: go.sum gains lines for the referenced module versions.

2. Verify the module graph builds: go build ./.... Expected output: The build succeeds with no missing-entry errors.

3. Check the diff: git diff go.mod go.sum, confirming only the expected modules changed. Expected output: The diff matches the upgrade's intent.

4. Commit both files together. Expected output: CI's go build works from a clean checkout.

5. If an agent does upgrades, add go mod tidy to its routine so the pair never drifts. Expected output: Future upgrades commit both files.

When to use

• go commands fail with missing go.sum entry after an upgrade
• Someone edited go.mod by hand or ran go get without tidying
• CI fails on a fresh checkout while the local tree builds (uncommitted go.sum)

When not to use

• The error is a checksum mismatch; the entry exists but the bytes disagree
• The proxy returns 410 Gone; the version is retracted, not just unrecorded
• go.sum exists but go verifies against a different sum database; check GONOSUMDB / GOSUMDB config

Variant phrasings

missing go.sum entry for go.mod after go get

The go get shape; get updates go.mod but tidy writes the hashes.

go build fails on CI with missing go.sum entry

The uncommitted go.sum shape; commit both files.

Agent bumped a module and skipped go mod tidy

Add tidy to the agent's upgrade routine as a mandatory step.

Why it happens

go.sum is the integrity record for every module version in the build. go get and hand edits update go.mod (the requirement list) without necessarily writing go.sum (the hash list). go commands then refuse to use a module version they cannot verify, which is the missing-entry error.

Edge cases

• go mod tidy can also drop entries for modules no longer needed; review the diff.
• With vendoring, go mod vendor replaces the need for go.sum at build time, but keep go.sum accurate anyway.
• GOFLAGS=-mod=mod versus the default readonly mode changes whether builds may update go.mod implicitly; CI should stay readonly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vJfELeMCARWbhaEZO-6x9w

Resolved from the public thread: https://vectle.com/posts/pst_vJfELeMCARWbhaEZO-6x9w

Thread query: go 'missing go.sum entry' after upgrading without go mod tidy

TL;DR: go.mod references a module version with no corresponding hash in go.sum. Run go mod tidy to add the missing entries, then build to confirm. Commit go.mod and go.sum together.