What does the Go checksum database at sum.golang.org guarantee that go.sum alone cannot?

## The gap go.sum leaves open `go.sum` is a list of expected hashes, one or two lines per module version. When the go command downloads a module it hashes what arrived and compares it against that list; a mismatch aborts the build. This is a strong guarantee with one specific hole: **the first line has to come from somewhere.** If your very first fetch of `example.com/lib v1.4.0` was served by a compromised mirror, or intercepted, or came from an origin that had been taken over, then the hash of the hostile copy is what lands in `go.sum` — and from then on the file diligently guarantees that you keep getting the same hostile copy. That pattern is called trust on first use, and it is why a lockfile of hashes alone is not a supply-chain control. ## What the checksum database is The checksum database is a public, append-only, cryptographically verifiable log of `module version -> hash` records. The go command reaches it through the `GOSUMDB` setting, whose default is `sum.golang.org`; the log's public key ships inside the toolchain, so a candidate does not have to trust the network to authenticate the log's answers. Whenever the go command is about to add a hash for a module version that is not yet in `go.sum` — typically during `go get` or `go mod tidy` — it first asks the database what hash that version has. If the answer disagrees with what was downloaded, the download is rejected with a security error rather than being written into `go.sum`. The log is more than a lookup table, and the difference is the whole point. Its records are stored in a Merkle tree, and the go command verifies inclusion proofs for the records it fetches against signed tree heads, keeping the tree state it has already seen in the module cache so it can check that later views are consistent extensions of earlier ones. That structure means the operator cannot *retract* or *rewrite* a record, and cannot present a different view of history to one victim than to everybody else without the split becoming detectable. The property is tamper-evidence and global consistency, not secrecy. ## The three things it therefore buys you 1. **Your first fetch is no longer self-trusted.** A poisoned proxy would have to poison the global log too, which it cannot do silently. 2. **Re-tagging is caught.** Once `v1.4.0`'s hash is in the log it is there permanently. A maintainer who force-pushes that tag onto different commits produces bytes that disagree with the logged hash, and every team fetching that version afterwards is stopped — including teams who never had the original in their `go.sum`. 3. **Everyone's `go.sum` agrees.** Two independent teams that fetch the same version end up with the same hash, which is what makes a `go.sum` diff in a code review meaningful. ## The limits, which matter as much The database says nothing about whether code is *good*. A malicious author who publishes malicious code at a brand-new version gets that version recorded in the log like any other; verification passes and the attack succeeds. It is not an identity system: nothing binds a module path to a vetted publisher, and it does not sign on the author's behalf. It also only covers modules the go command actually looks up — set `GOSUMDB=off`, or match a module path with `GOPRIVATE` (or the narrower `GONOSUMDB`), and you are silently back to trust on first use for exactly those paths. ## Living without direct internet access A network with no egress does not have to give the check up. A module proxy is allowed to mirror the checksum database's endpoints as well as module archives, so an internal `GOPROXY` can answer the go command's log queries too, and verification keeps working end to end behind the mirror. That matters when standing up a self-hosted or air-gapped build environment: the tempting shortcut is `GOSUMDB=off` in the build image, and it quietly converts every dependency in the organisation back to whatever the mirror felt like serving on the day it was first ingested. If the mirror genuinely cannot proxy the log, the honest fallback is to do first ingestion of every new module in one controlled place where the database *is* reachable, commit the resulting `go.sum` lines, and treat that file as a reviewed artefact rather than a generated one. ## How to say it in an interview One sentence: `go.sum` protects you from a *change* to a dependency, the checksum database protects you from a *bad first impression* of one. Everything else follows from that.