proxy.golang.org: maintainers mechanism to refresh bad checksum

[StevenACoffman]

cockroachdb version v1.8.5 had been originally tagged for a commit hash that was subsequently removed, and replaced by another commit hash.
Even though the window of time between the two release events was less than 10 minutes, it was enough to get the go mod proxy confused, resulting in errors about mismatched checksums.

To resolve the issue, v1.8.6 was released. Is there a mechanism that maintainers or the community can use to force proxy.golang.org or sum.golang.org to refresh in order to avoid having to do a new release?

This has also happened with github.com/ryancurrah/gomodguard v1.2.1 and I assume other.

What version of Go are you using (go version)?

$ go version
go version go1.16.6 darwin/amd64

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/steve/Library/Caches/go-build"
GOENV="/Users/steve/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/steve/go/pkg/mod"
GONOPROXY="github.com/Khan,github.com/cockroachdb/errors"
GONOSUMDB="github.com/Khan,github.com/cockroachdb/errors"
GOOS="darwin"
GOPATH="/Users/steve/go"
GOPRIVATE="github.com/Khan"
GOPROXY="direct"
GOROOT="/Users/steve/.asdf/installs/golang/1.16.6/go"
GOSUMDB="off"
GOTMPDIR=""
GOTOOLDIR="/Users/steve/.asdf/installs/golang/1.16.6/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16.6"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/steve/Documents/git/districts-jobs/admin-reports/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/s8/3k2blhzd50ldk8c3lld3_p0m0000gn/T/go-build4243746156=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Attempted to build and deploy an application using github.com/cockroachdb/errors v1.8.5:

ENV GOFLAGS="-mod=readonly"
ENV GOPRIVATE="github.com/Khan"
ENV GO111MODULE=on

# Moving outside of $GOPATH forces modules on without having to set ENVs
WORKDIR /src/pkg

# Add go.mod and go.sum first to maximize caching
COPY ./pkg/go.mod ./pkg/go.sum /src/pkg/

RUN go mod download -x
RUN go mod verify

What did you expect to see?

Happy Rainbows

What did you see instead?

Step #0: # get https://proxy.golang.org/github.com/cockroachdb/errors/@v/v1.8.5.mod: 200 OK (0.022s)
Step #0: verifying github.com/cockroachdb/[email protected]/go.mod: checksum mismatch
Step #0: 	downloaded: h1:GV8u+kb+Pb23w4FneavC3BBo/8XbnWqcCGhHKi3foME=
Step #0: 	go.sum:     h1:hOm5fabihW+xEyY1kuypGwqT+Vt7rafg04ytBtIpeIQ=
Step #0: 
Step #0: SECURITY ERROR
Step #0: This download does NOT match an earlier download recorded in go.sum.
Step #0: The bits may have been replaced on the origin server, or an attacker may
Step #0: have intercepted the download attempt.

[dr2chase]

@heschi @hyangah could you give this a look?

[seankhliao]

cc @rsc @FiloSottile as I think this would violate the security guarantees sumdb wishes to provide

[heschi]

sum.golang.org is intended to guarantee that all Go users see the same code for a given module version. There's no way for it to know whether a change to a release was an intentional fix, a mistake, or an attack. Either way, reproducible builds are fundamental goal of the module ecosystem and users should be able to rely on things not changing invisibly.

If you use proxy.golang.org, it will serve you the same data for the version that sum.golang.org saw. The maintainers could also set the tag back to its original content.

[StevenACoffman]

So after a new release happens, even when the consumer's application points to it, older releases are often still flagged as violating the checksum (failing the build) unless library consumers add an explicit exclude for the bad release.

go mod download -x
go mod verify

Is there any way for maintainers to obsolete/redact/etc. a bad old release?

"Pretend v1.8.5 never happened please. We went v1.8.4 and straight to v1.8.6"

[seankhliao]

See the retract directive

[StevenACoffman]

Thanks! I made cockroachdb/errors#83 to apply the retract directive to cockroachdb/errors!