Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: GOPROXY list feature fails to allow private modules to be downloaded #31818

Closed
amnonbc opened this issue May 3, 2019 · 7 comments
Closed

Comments

@amnonbc
Copy link

@amnonbc amnonbc commented May 3, 2019

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

go version devel +004fb5c Fri May 3 03:49:11 2019 +0000 linux/amd64

Does this issue reproduce with the latest release?

NA

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

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOSUMDB=""
GOOS="linux"
GOPROXY="direct"
GOSUMDB="off"
GOTMPDIR=""
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build237972668=/tmp/go-build -gno-record-gcc-switches"

What did you do?

GOPROXY=https://proxy.golang.org/,direct go build

What did you expect to see?

I expect to see private modules downloaded directly from my company's VCS (which is behind a corporate firewall and not accessible from the internet).
(as described in f30c564)

What did you see instead?

go: downloading gopkg.in/inf.v0 v0.9.1
verifying git.mycompany.com/linux/mymodule@v1.0.0: git.mycompany.com/linux/mymodule@v1.0.0: reading https://sum.golang.org/lookup/git.mycompany.com/linux/mymodule@v1.0.0: 410 Gone

when GOPROXY=direct, then mymodule downloads and builds without problem.

@hyangah

This comment has been minimized.

Copy link
Contributor

@hyangah hyangah commented May 3, 2019

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

@hyangah hyangah changed the title GOPROXY list feature fails to allow private modules to be downloaded cmd/go: GOPROXY list feature fails to allow private modules to be downloaded May 3, 2019
@FiloSottile

This comment has been minimized.

Copy link
Member

@FiloSottile FiloSottile commented May 3, 2019

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

@katiehockman

This comment has been minimized.

Copy link
Member

@katiehockman katiehockman commented May 3, 2019

@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

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented May 3, 2019

@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.

@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented May 3, 2019

@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 rsc closed this May 3, 2019
@hyangah

This comment has been minimized.

Copy link
Contributor

@hyangah hyangah commented May 3, 2019

@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.

@amnonbc

This comment has been minimized.

Copy link
Author

@amnonbc amnonbc commented May 3, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.