Go version

go 1.24.0

Output of go env in your module/workspace:

go env 
AR='ar'
CC='clang'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='clang++'
GCCGO='gccgo'
GO111MODULE='auto'
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/Users/pierre.gimalac/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/pierre.gimalac/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/zp/m8h1x16s30g3f656sxsdt7rm0000gp/T/go-build2391666502=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/Users/pierre.gimalac/go/src/github.com/DataDog/datadog-agent-dev/go.mod'
GOMODCACHE='/Users/pierre.gimalac/go/pkg/mod'
GONOPROXY='github.com/DataDog'
GONOSUMDB='github.com/DataDog,go.ddbuild.io'
GOOS='darwin'
GOPATH='/Users/pierre.gimalac/go'
GOPRIVATE='github.com/DataDog'
GOPROXY='binaries.ddbuild.io,proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/pierre.gimalac/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.24.0'
GOWORK='/Users/pierre.gimalac/go/src/github.com/DataDog/datadog-agent-dev/go.work'
PKG_CONFIG='pkg-config'

What did you do?

I'm working on a codebase with a go.work file containing the following directives:

go 1.23.6

toolchain go1.23.6

godebug tlskyber=0

When using Go 1.23.x, everything works fine, but whenever I use 1.24.x go errors due to tlskyber not being a recognized setting.

Using godebug default=go1.23 didn't change anything.

I know the documentation https://go.dev/doc/godebug says:

It is an error to list a godebug with an unrecognized setting.
[...]
Starting in Go 1.21, the Go toolchain treats a //go:debug directive with an unrecognized GODEBUG setting as an invalid program.

But I was not expecting it to apply to settings which have been removed in previous versions.

Since my installed toolchain is more recent than the toolchain directive, it's not automatically downgrading to 1.23.6, despite the go.work using a godebug directive specific to go 1.23.

In practice this kind of seems like a breaking change, as something working with go 1.23 completely fails with 1.24... I feel like removed setting could be ignored, or warn without actually failing.

What did you see happen?

Any go command fails with 

go: error loading go.work:
go.work:9: unknown godebug "tlskyber"

What did you expect to see?

Either the toolchain should downgrade to 1.23.6, or maybe warn about the godebug directive being deprecated and ignore it (without failing).

Comment From: mateusz834

The name was changed see CL 630775

CC @FiloSottile

Comment From: gabyhelp

Related Issues

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

Comment From: FiloSottile

The name was changed see CL 630775

It wasn't quite a name change, we removed tlskyber and introduced a new different (similar and related) GODEBUG.

How to handle removed GODEBUGs is an interesting question, and indeed the current behavior doesn't feel right. Maybe it should depend on whether the GODEBUG was removed because the new behavior is now mandatory (hopefully an increasingly common occurrence) or because the new behavior was removed (this unusual case)?

Comment From: JunyangShao

CC @matloob

Comment From: dmitshur

I’m not familiar with the specifics of why the tlskyber godebug was added in Go 1.23 and removed in 1.24, but I’ll note that https://go.dev/doc/godebug includes:

GODEBUG settings added for compatibility will be maintained for a minimum of two years (four Go releases). Some, such as http2client and http2server, will be maintained much longer, even indefinitely.

If it were removed in Go 1.27 instead, would that have been enough to help with this, or would the same problem apply when Go 1.28 is released?

Comment From: pgimalac

If it were removed in Go 1.27 instead, would that have been enough to help with this, or would the same problem apply when Go 1.28 is released?

In my specific case it would have helped as we're just using it as a temporary workaround to avoid firewalls blocking requests when the new algorithm is used, but that might not be the way godebug directives are used in general.

My take is that if a godebug setting is dropped in some Go version, but the new behavior matches what the setting is set to, then the new version should not hard fail to compile. In my case, the default behavior in Go 1.24 is that X25519Kyber768Draft00 is disabled, which matches the behavior when using godebug tlskyber=0, so it shouldn't error.

In the other case (eg. if I were explicitly setting godebug tlskyber=1), then it's fair to error, and explain that the required behavior is not supported by Go 1.24.

Comment From: matloob

I think it's helpful for maintenance to be able to completely remove a setting once it's retired.

I discussed this with @rsc. We think that in this case we should have kept the setting, and removed it in 1.27, but just ignored its value. I can send a CL to add it back.

Comment From: pgimalac

I can send a CL to add it back.

If you can do that (for Go 1.24.x) it'd be very nice ! Thanks a lot !

Comment From: gopherbot

Change https://go.dev/cl/662655 mentions this issue: cmd/go: add tlskyber godebug back but with no effect