You have GOPROXY="https://proxy.golang.org,direct", which means the go command will fall back to direct fetching if proxy.golang.org fails.

This is a strange one. It seems to be failing very consistently. Offhand the only thing I can think is that gitern.com is blocking the Google egress IPs that proxy.golang.org connects from. You may want to ask them if that rings any bells. I'll try to dig a little more when I get a chance.

cc @hyangah @katiehockman

cc @huumn

I’m not blocking any ips explicitly. If they’re being blocked on my end they’re being blocked by AWS.

All repos are private on gitern which could require additional config for go get?

Edit: Ah gitern only supports git over ssh to the repos. I suspect go get uses http.

Would go-get be falling back to direct for the zipball, which I have manually configured via config to use auth, then failing to find an entry in the sumdb?

@arnottcr gitern does not support git over http currently (only ssh). I think go get defaults to http and might need to be told to use ssh.

The .git suffix causes the toolchain to try http and ssh (maybe git:// too), so i can confirm that part is working.

It would be nice to get meta header support for gitern, but that is out of scope here, and I still think there might be a go-get bug.

For private repositories, please see this instruction.
https://golang.org/cmd/go/#hdr-Module_configuration_for_non_public_modules

@arnottcr I just saw you already tried GOPRIVATE and it works. There is no way sum.golang.org can access private repositories (it shouldn't, right? it's private!) GOPRIVATE is the way to opting out of using proxy.golang.org and also sum.golang.org for the specified modules.

I will close this since this is working as intended.

This ux is really confusing. Can we have the toolchain detect these failurse and suggest GOPRIVATE? We use it at work, and I am familiar with what it does, but it was not clear why go get was failing.

No, especially since I still don't know why it's failing. Connection refused isn't a reasonable error to get for a private repository; it can't possibly know whether we can authenticate without accepting the connection. My best guess is still a misconfiguration on the origin side.

At the same time, there is no point spending time diagnosing it if it's just going to fail later, so I'm not going to investigate any further.

I guess my ask is when the module proxy falls back to direct, can we disable sumdb checking? I get that verification is important, but the ux is confusing, and if proxy.golang.org (or whatever module proxy you have configured) cannot reach out, why would we expect the sum.golang.org to do any better.

Since gitern may be making things more confusing, i am happy to repro with a private github repo.

Automatically disabling sumdb lookup would destroy the security model; any attacker that controlled the network could disable sumdb lookup by blocking access to proxy.golang.org.

Again, this is not a general problem with private modules. For example, I believe GitHub returns a warning about authentication that helps avoid confusion. The problem here is that network connectivity between proxy.golang.org and the origin is broken. There may be some room to improve the error message when sumdb fetching fails after a successful proxy download, but that would need to take into account the user's particular proxy/sumdb configuration and should definitely be discussed in a separate issue.

Automatically disabling sumdb lookup would destroy the security model; any attacker that controlled the network could disable sumdb lookup by blocking access to proxy.golang.org.

If you are concerned about this why even have the ,direct option? IIUC, it will always fail, since packages that do not exist in proxy.golang.org will not have entries in sum.golang.org. If we include ,direct it needs to do something, can you walk me through a ux that does?

Furthermore, if you are concerned with network level interception, you likely have larger problems.

Again, this is not a general problem with private modules. For example, I believe GitHub returns a warning about authentication that helps avoid confusion. The problem here is that network connectivity between proxy.golang.org and the origin is broken. There may be some room to improve the error message when sumdb fetching fails after a successful proxy download, but that would need to take into account the user's particular proxy/sumdb configuration and should definitely be discussed in a separate issue.

The ux for github private repos is not better, but this may be the anti-discovery mechanism at work:

[user@localhost ~]$ go get github.com/arnottcr/private
# cd .; git clone -- https://github.com/arnottcr/private /home/user/go/src/github.com/arnottcr/private
Cloning into '/home/user/go/src/github.com/arnottcr/private'...
fatal: could not read Username for 'https://github.com': terminal prompts disabled
package github.com/arnottcr/private: exit status 128

Also the toolchain disallows the use of github.com/owner/repo.git, so it does not directly translate: (really unsure why this is disallowed)

[user@localhost ~]$ go get github.com/arnottcr/private.git
package github.com/arnottcr/private.git: invalid version control suffix in github.com/ path