Does this issue reproduce with the latest release?
What did you do?
Tag a version of a module, say firstname.lastname@example.org.
Set GOPROXY=direct, GOSUMDB=off, then go get email@example.com in another module. This downloads the version into the cache without notifying proxy.golang.org or sum.golang.org and adds a sum to go.sum.
Change something and update the version tag to point to the new change.
Clear GOPROXY and GOSUMDB.
Run go mod verify, observing no security error.
Clean the module cache with go clean -modcache.
Run go list all or any other command that would download the modified version, observing a security error.
The first go mod verify command should report a security error. For each module in the build list not matched by GOPRIVATE or GONOSUMDB (that is, each publicly available module), go mod verify should check the hash of the downloaded module and the hash in go.sum against the checksum database in GOSUMDB, assuming it is not disabled.
In this scenario, that hash won't be in the checksum database, and the lookup should cause sum.golang.org to fetch firstname.lastname@example.org from its origin and return the sum for the modified version. go mod verify would then report a security error because that sum will not match the original sum in the dependent module's go.sum. go mod verify should also report a security error if sum.golang.org returns any error response (most commonly, 404 or 410) or is not available.
This is important for identifying when both go.sum and the contents of the module cache don't match a publicly available version. People in this situation will see their builds work fine, but builds for other developers and CI builds will fail. go mod verify only checks that go.sum matches the contents of the module cache. It will only consult the checksum database if it needs to download something that's not cached.
What did you see instead?
go mod verify reports no security error in step 5.
The text was updated successfully, but these errors were encountered: