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)

Comment From: gabyhelp

Similar Issues

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Comment From: seankhliao

that is not a version of go we still support.

Comment From: wwqgtxx

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.

Comment From: wwqgtxx

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

Comment From: FiloSottile

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 https://github.com/golang/go/issues/46136#issuecomment-1985018491.

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.

Comment From: wwqgtxx

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.

Comment From: FiloSottile

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.

Comment From: gopherbot

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

Comment From: dmitshur

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.