x/build: using proxy.golang.org directly is incompatible with builder's outbound network restriction #33928
Comments
It seems to for some module versions: I think we'll need to open up the firewall just enough for GCS to get through. |
dmitshur
added
NeedsInvestigation
|
As far as I can tell, it's intended behavior on the proxy's side, it applies to some larger zips.
This can be a first order fix. Afterwards, if we want to tighten the firewall more, we can go back to having our own builder-specific intermediate proxy to pass everything through that we can allowlist very narrowly. |
dmitshur
added
NeedsFix
|
Change https://golang.org/cl/192317 mentions this issue: |
|
Sent CL 192317 that implements the first step, the smallest change to return builders to a working state. It will give us more time to work on the next steps. |
Issue golang.org/issue/30612 implemented a restriction on outbound network access to help catch unintended uses of internet in tests. We're currently relying on GOPROXY=https://proxy.golang.org for running tests in module mode in Go 1.13+, but proxy.golang.org can serve some module zip files by 302 redirecting to other URLs. Those URLs may not be accessible due to this builder network restriction. Disable the outbound network restriction as the first step to return builders to a working state. The next step will be implement a long term solution, then we can re-enable the network restriction again. Updates golang/go#33928 Updates golang/go#30612 Change-Id: I1a87b8d107df8806753117fc60a3e795e1e1b182 Reviewed-on: https://go-review.googlesource.com/c/build/+/192317 Reviewed-by: Alexander Rakoczy <alex@golang.org>
|
The aforementioned CL is deployed, so this issue is mitigated for now. I'll remove the Soon label. We can leave this issue open to discuss next steps. This has caused issue #30612 to get re-opened, so we need to find a solution that will allow us to close that again. |
dmitshur
added
NeedsInvestigation
dmitshur
changed the title
|
Change https://golang.org/cl/192341 mentions this issue: |
|
I sent https://golang.org/cl/192341 but sick baby woke up so I can't test it yet. But the fix will be close to that at least. |
Issue golang.org/issue/30612 implemented a restriction on outbound network access to help catch unintended uses of internet in tests. We're currently relying on GOPROXY=https://proxy.golang.org for running tests in module mode in Go 1.13+, but proxy.golang.org can serve some module zip files by 302 redirecting to other URLs. Those URLs may not be accessible due to this builder network restriction. Disable the outbound network restriction as the first step to return builders to a working state. The next step will be implement a long term solution, then we can re-enable the network restriction again. Updates golang/go#33928 Updates golang/go#30612 Change-Id: I1a87b8d107df8806753117fc60a3e795e1e1b182 Reviewed-on: https://go-review.googlesource.com/c/build/+/192317 Reviewed-by: Alexander Rakoczy <alex@golang.org>
And because this uses new-in-Go1.13 http.Header.Clone, restrict all the files to Go 1.13+ and bump the Dockerfile Go version. Fixes golang/go#33928 Change-Id: I147cc4465e393d2c34e59c70edf65f3901a5e132 Reviewed-on: https://go-review.googlesource.com/c/build/+/192341 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
dmitshur
added
NeedsFix
Check out the failures on e.g. https://go-review.googlesource.com/c/build/+/191577 ...
https://storage.googleapis.com/go-build-log/0b9b152e/linux-amd64_c339c8eb.log
That
"connect: no route to hostis because most of our builders are firewalled off so they don't accidentally depend on the network more than expected.Did the Go module proxy start returning redirects to GCS?
/cc @andybons @toothrot @dmitshur @katiehockman @ianlancetaylor
The text was updated successfully, but these errors were encountered: