cmd/go: removed godebug settings cause errors

[pgimalac]

Go version

go 1.24.0

Output of go env in your module/workspace:

go env

```shell 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).

[mateusz834]

The name was changed see CL 630775

CC @FiloSottile

[gabyhelp]

Related Issues

• golang.org/x/*: go directive of 1.23.0 is forcing toolchain directives in anything not using exactly go1.23.0 #71864 (closed)
• cmd/go: separate default GODEBUGs from go language version #65573 (closed)
• godebug: directive is ignored in go.mod when using a workspace #72109
• cmd/go: breaking change in 1.23rc2 with version constraints in GOPATH mode #68658 (closed)
• cmd/go: go get -u && go mod tidy behaves differently starting with Go 1.21.0, leading to unknown directive toolchain errors #62409 (closed)
• cmd/go: go1.22 toolchain not available #65631 (closed)
• x/tools/gopls: packages.Load failure with conflicting go.work and go.mod toolchain versions #69646

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

[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)?

[JunyangShao]

CC @matloob

[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?

[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.

[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.