-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
retrieving external modules on Go1.15 on s390x appears to have checksum and ECDSA verification issues #40949
Comments
Thank you for this report @justaugustus and welcome to the Go project! There was a crypto/ed25519 s390x issue in #40475 which was spawned a revert in https://go-review.googlesource.com/c/go/+/245497 or 54e75e8 Kindly /cc-ing @mundaym @FiloSottile |
I don't think this has anything to do with I remember @mvdan running into a similar issue. It turned out to be a bug in qemu. Let me see if I can dig that up. |
I was hitting I would suggest to try the latest QEMU version, or at least check what version you're using and seeing if it includes the upstream fix. |
Also, I never ended up filing an issue on this tracker, as we ended up finding that it wasn't a bug in Go at all, like @mundaym said. |
That looks like it explains the tls errors, which is great. Does it also explain the zip checksum error with
|
The QEMU bug was ultimately about hashing, so yeah, I would definitely expect that problem to be caused by the same QEMU bug. |
interesting, I didn't expect system hash functions to be used for go module hash calculations |
Ultimately I'm not sure, but it's a pretty rare problem to encounter, so I'd blame the same QEMU bug unless I have proof pointing in another direction :) |
The conversation in https://bugs.launchpad.net/qemu/+bug/1847232/ seems to indicate that they think it is a bug in vector instruction emulation (the 'vx' instruction set is an instruction set extension for s390x, similar to something like AVX for x86). The poly1305 code (ultimately used by This looks a little different to me. There are a couple of issues in the multiarch/qemu-user-static repo related to s390x, though nothing I can see that exactly matches this (illegal instruction/hanging app). We did make some changes to the |
But yes, if you are able to update qemu that is probably the best place to start. I'd also be interested to see if Go 1.14.x has the same issue if that is easy to try. |
It seems like this is suspected to be a third-party tooling issue (qemu) without any action for the Go team. Also, all of the issues referencing this one have been closed, so I think we can close this one too. Please ping if we should reopen. Thanks. |
It seems like there's a problematic interaction between QEMU, S390x (and RISC-V), and TLS (at least with ECDSA, but possibly other encryption schemes as well). It has something to do with the emulation of certain instructions used in hashing. For some background, see golang/go#40949 and moby/moby#40240. This may be why the presence of the linux/s390x image is somewhat inconsistent with golang Docker images. Anyway, it's causing problems with the sidecar build, so this commit disables S390x builds for the time being (which also allows us to use more specific golang image tags). This shouldn't impact too many (if any) users. The only other option here would be to disable Go proxy verification for S390x builds, which we might consider if S390x images become crucial, but the same bug would probably plague the sidecar images themselves, not just the build process. Signed-off-by: Jacob Howard <[email protected]>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yep! go1.15 as of filing this issue (8/21/20).
What operating system and processor architecture are you using (
go env
)?This is the s390x stage of a multi-arch container build running in Google Cloud Build (
linux/amd64
) usingdocker run --rm --privileged multiarch/qemu-user-static@sha256:c772ee1965aa0be9915ee1b018a0dd92ea361b4fa1bcab5bbc033517749b2af4 --reset -p yes
to configure the environment.go env
OutputWhat did you do?
For background, in the Kubernetes project, we recently switched an image called go-runner, which is essentially distroless/static with some minor modifications to support our logging and exec for our core binaries.
That image's Dockerfile builds the
go-runner
command in agolang:x.y
container and then copies the binary into agcr.io/distroless/static-debian10:latest
image.As we've recently updated to go1.15 on kubernetes/kubernetes (kubernetes/kubernetes#93939, kubernetes/release#1421), I wanted to update this image from go1.13.15 to go1.15 before our tentative release on 8/25.
The work-in-progress PR for this is here: kubernetes/release#1499
What did you expect to see?
All platforms in this container build should have succeeded.
What did you see instead?
Across several debugging runs of the container build, I saw issues with downloading
github.com/pkg/[email protected]
...go: github.com/pkg/[email protected]: Get "https://proxy.golang.org/github.com/pkg/errors/@v/v0.9.1.mod": tls: invalid signature by the server certificate: ECDSA verification failure
With
GOPROXY=direct
go mod download -json
I've tried with various permutations of GOPROXY:
https://proxy.golang.org
(what it was originally explicitly configured with)https://proxy.golang.org,direct
(current go1.15 default)https://proxy.golang.org|direct
(fallback todirect
, new with go1.15)direct
off
When curl-ing the proxy from within s390x build, I get the same values sum-wise:
cc: @dims @liggitt @BenTheElder
The text was updated successfully, but these errors were encountered: