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

x/crypto/sha3: no longer compatible with Go 1.18 after v0.24.0 #68147

Closed
nekohasekai opened this issue Jun 24, 2024 · 9 comments
Closed

x/crypto/sha3: no longer compatible with Go 1.18 after v0.24.0 #68147

nekohasekai opened this issue Jun 24, 2024 · 9 comments
Labels
FixPending Issues that have a fix which has not yet been reviewed or submitted. NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@nekohasekai
Copy link

Go version

go version go1.22.4 darwin/arm64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/sekai/Library/Caches/go-build'
GOENV='/Users/sekai/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/sekai/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/sekai/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.22.4/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.22.4/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.4'
GCCGO='gccgo'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/62/0rdd_81n5jbf6j4w3pcmwycr0000gn/T/go-build3068982710=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

I am updating golang.org/x/crypto to v0.24.0. Many third-party libraries and other x libraries also depend on this version.

What did you see happen?

It fails to compile with Go 1.18:

# golang.org/x/crypto/sha3
sha3/xor.go:25:10: undefined: subtle.XORBytes

What did you expect to see?

Since many third-party libraries and other x libraries actually still compile under Go 1.18, and the go mod for x/crypto still use Go 1.18, it would be nice if crypto treated this as a bug.

subtle.XORBytes looks like a public version of the internal function crypto/cipher.xorBytes , if you don't want to copy a compat version of the old code for Go 1.18 you can linkname to it (I know linkname shouldn't be used, but maybe ok for older Go versions)

@gopherbot gopherbot added this to the Unreleased milestone Jun 24, 2024
@seankhliao
Copy link
Member

that is not a version of go we still support.

@seankhliao seankhliao closed this as not planned Won't fix, can't repro, duplicate, stale Jun 24, 2024
@wwqgtxx
Copy link

wwqgtxx commented Jun 24, 2024

This reply is too arrogant. Since the go.mod of x/crypto is written in 1.18, it should be guaranteed to compile normally under 1.18.

@wwqgtxx
Copy link

wwqgtxx commented Jun 24, 2024

Perhaps we should ask @FiloSottile, who caused the compilation problem, what his attitude is on this.

@FiloSottile
Copy link
Contributor

We indeed don't support such old versions of Go. We put a lot of effort into making it possible to upgrade Go without breakage, partially so we don't have to worry about supporting older versions.

It's true the go.mod says Go 1.18 though, which probably shouldn't. It caused confusion in #68035, too, and #68011 would have gotten a hint if the go.mod version was higher.

This is really an instance of #47802, in general, but was not flagged by vet due to #46136 (comment).

Questions for @golang/release: is there a policy on how to bump go.mod versions of x/ repos?

@wwqgtxx maintainers have a thankless job, please don't attack them just because you don't appreciate a response.

@wwqgtxx
Copy link

wwqgtxx commented Jun 24, 2024

Maybe my wording is not appropriate, I apologize in advance, but it is not what the maintainer should do to ignore the three issues including this one.

Regarding this issue, either the go version number in x/crypto should be increased, or conditional compilation should be used to maintain normal compilation.

If the official compatibility policy for old versions has not been discussed internally, at least this issue should be kept open instead of being closed rudely.

@FiloSottile
Copy link
Contributor

the go version number in x/crypto should be increased

Yes, that's what we are discussing now, but again please be considerate and keep the conversation on the topic rather than on individual's actions you disagree with, unless strictly necessary. I promise it will lead to better outcomes anyway.

@FiloSottile FiloSottile reopened this Jun 24, 2024
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/594256 mentions this issue: all: bump go.mod version and drop compatibility shims

@seankhliao seankhliao added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 24, 2024
@dmitshur
Copy link
Contributor

dmitshur commented Jun 24, 2024

Questions for @golang/release: is there a policy on how to bump go.mod versions of x/ repos?

@FiloSottile There isn't something written down beyond the Go release policy, but that policy suggests general golang.org/x modules (e.g., with user-facing importable packages) need to continue to support the current and previous major Go versions (with some exceptions like the one for x/build). That's 1.22 and 1.21 at this time. So it's fine to update the x/crypto module to use Go 1.20 language semantics by now, since all supported Go versions can handle that, and the 1.22/1.21 trybots should pass.

@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. FixPending Issues that have a fix which has not yet been reviewed or submitted. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jun 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FixPending Issues that have a fix which has not yet been reviewed or submitted. NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants