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: falls back to subsequent proxies too early during package resolution #31785

Open
heschik opened this issue May 1, 2019 · 4 comments

Comments

Projects
None yet
5 participants
@heschik
Copy link
Contributor

commented May 1, 2019

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

$ go version
go version devel +f0c383b833 Wed May 1 16:53:19 2019 +0000 linux/amd64

Does this issue reproduce with the latest release?

No, the feature doesn't exist.

What did you do?

$ GOPROXY=https://proxy.golang.org,direct go get -x -v golang.org/x/tools/cmd/goimports

What did you expect to see?

Requests only to the proxy, then a successful build of goimports.

What did you see instead?

One request to the proxy, then a git clone, then alternating between the two until success.

Package to module resolution walks up from the package name looking for a module, and during that walk it's expected to encounter 404s until it finds the actual module path. Those 404s trigger fallback to the next fetch method.

I don't know this code very well but I think this would cause at least two problems: First, the name of the requested package leaks to the subsequent source. If the first source is a corporate proxy and the second is proxy.golang.org, that could be a problem. Second, if the second source is unavailable for some reason, like an offline origin, I suspect the entire go get command will fail.

Marking as a release blocker since this seems to seriously undercut the intended uses of the feature.

@rsc

@heschik heschik added this to the Go1.13 milestone May 1, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented May 8, 2019

See related discussion on CL 173441 (#26334).

@rsc rsc assigned rsc and bcmills and unassigned rsc May 9, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented May 15, 2019

We should also clarify what happens if direct appears earlier in the list: I could imagine someone wanting to prefer to fetch directly, but to fall back to (say) the public proxy if the origin is unavailable.

@bcmills

This comment has been minimized.

Copy link
Member

commented May 16, 2019

We should also clarify what happens if direct appears earlier in the list

I talked with Russ and we decided that the fallback stops at direct, but we won't reject that configuration in order to provide forward-compatibility if we decide to add some sort of “proceed past a broken origin” semantics later.

@gopherbot

This comment has been minimized.

Copy link

commented May 17, 2019

Change https://golang.org/cl/177958 mentions this issue: cmd/go: when resolving packages, try all module paths before falling back to the next proxy

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