The go command failed to retrieve necessary info from the sumdb - sum.golang.org can't see private modules either.

Can you try to exclude the private modules from verification using GONOSUMDB env vars? https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md#command-client

By the way, I think a better approach for accessing private repos is to use the GONOPROXY env var, instead of relying on the GOPROXY list fallback.

@rsc @FiloSottile

@rsc Looks like GOPROXY=direct implies GOSUMDB=off, is that true and intended?

@FiloSottile Yes I believe this is intended for right now in the early phases of testing. GOSUMDB defaults to sum.golang.org if GOPROXY=https://proxy.golang.org in the Go 1.13 dev branch, but GOSUMDB is still off at tip.

@rsc Looks like GOPROXY=direct implies GOSUMDB=off, is that true and intended?

Yes, and not just true and intended but also documented: https://tip.golang.org/cmd/go/#hdr-Module_authentication_failures.

@amnonbc, you need to set GONOSUMDB to tell the go command which modules not to check (the whole point of the checksum database is to avoid trusting downloads blindly, so this information must originate with you, not some network server that might be intercepted). See the end of https://tip.golang.org/cmd/go/#hdr-Module_authentication_failures, and note that you can set it easily by using the new go env -w command, as in go env -w GONOSUMDB=<patterns>.

@rsc, should we consider a change in authentication logic if the GOPROXY is a list? E.g. if a module was fetched from 'direct' mode because the first proxy (proxy.golang.org) couldn't serve the module. Or, enable authentication at least for modules downloaded from the proxy.golang.org if GOPROXY=<private_proxy>,https://proxy.golang.org.

@rsc Thanks for the explanation, and the awesome work on Modules.