crypto: remove in Go 1.27 GODEBUGs introduced in Go 1.23 and earlier

[FiloSottile]

We have never decommissioned GODEBUGs before, so I am improvising the process a bit. The docs just say

GODEBUG settings added for compatibility will be maintained for a minimum of two years (four Go releases).

I propose that we pre-announce in the Go 1.26 release notes the removal in Go 1.27 of the following GODEBUGs:

• tlsunsafeekm introduced in Go 1.22.
• tlsrsakex introduced in Go 1.22.
• tls10server introduced in Go 1.22.
• tls3des introduced in Go 1.23.
• x509keypairleaf introduced in Go 1.23.
• x509negativeserial introduced in Go 1.23.

Of these, only x509negativeserial feels like it might break folks without a workaround.

tlskyber was introduced in Go 1.23 and removed in Go 1.24, which broke folks and was going to be reintroduced #72111, but it looks like CL 662655 never landed, so I'm not sure what we should do now.

x509usepolicies was introduced in Go 1.22, but switched only in Go 1.24, so it has to wait for Go 1.28.

tlsmaxrsasize was introduced in Go 1.22, but it's more of a knob than a compatibility GODEBUG, so I think it's here to stay.

/cc @golang/security

[mateusz834]

There was an issue about a GODEBUG that we have mistakenly removed, and it caused build failures. I don't remember the conclusion of it, but is this something that we should be worried about? i.e. we might cause build failures with this removal. It is possible that that is fine, but i don't think we ever have made a intentional GODEBUG removal, or if there is a policy about that.

EDIT: It was in the description 😄 #72111.

[gabyhelp]

Related Issues

• proposal: crypto/x509: remove x509sha1 GODEBUG in Go 1.24 #62048
• crypto/tls: Using GODEBUG=tlsrsakex=1 behaves inconsistently between Go 1.22 and master #68528 (closed)

Related Documentation

• Go, Backwards Compatibility, and GODEBUG > GODEBUG History > Go 1.23
• Go, Backwards Compatibility, and GODEBUG > GODEBUG History > Go 1.22

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

[FiloSottile]

Of these, only x509negativeserial feels like it might break folks without a workaround.

Yeeeah, nevermind, there are enough hits on a GitHub search that I suspect it will take quite a bit longer to flush this one out.

The others were essentially just soft-landings to tie changes to the go.mod version, but I doubt anyone is relying on them.

[gopherbot]

Change https://go.dev/cl/701875 mentions this issue: cmd/go: link to go.dev/doc/godebug for removed GODEBUG settings

[aclements]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— aclements for the proposal review group

[aclements]

Proposal meeting notes:

• We're good with pre-announcing the removal of these with the intent to remove them in 1.27.

• @griesemer will file an umbrella issue for formalizing the GODEBUG removal process. It'll definitely start with a pre-announcement, so this proposal doesn't have to block on that, but we'll work out the details of how to actually remove a GODEBUG in a new issue.

• @rolandshoemaker mentioned we've removed x509sha1, and that pre-announcement process worked well. There was significant push back from the community, and working around it was complex enough, leading us to delay its removal, and it ultimately landed better than it otherwise would have.

[aclements]

Based on the discussion above, this proposal seems like a likely accept.
— aclements for the proposal review group

The proposal is to announce the impending removal of the following compatibility GODEBUGs in 1.26, and to remove them in 1.27:

• tlsunsafeekm introduced in Go 1.22.
• tlsrsakex introduced in Go 1.22.
• tls10server introduced in Go 1.22.
• tls3des introduced in Go 1.23.
• x509keypairleaf introduced in Go 1.23.

The technical process for removing a compatibility GODEBUG will be decided in a separate issue.