Golang新引入的GODEBUG功能是否在同一个版本中生效？

Golang新引入的GODEBUG功能是否在同一个版本中生效？ Go 1.22 引入了多项强化的 Go 工具链行为。在 Go 1.22 发行说明 - Go 编程语言 中可以看到：

crypto/tls 除非正在使用 TLS 1.3，或者服务器和客户端都支持 extended_master_secret 扩展，否则 ConnectionState.ExportKeyingMaterial 现在将返回一个错误。自 Go 1.20 起，crypto/tls 已支持此扩展。可以使用 tlsunsafeekm=1 GODEBUG 设置来禁用此行为。

默认情况下，如果未通过 config.MinimumVersion 指定，crypto/tls 服务器现在提供的最低版本是 TLS 1.2，这与 crypto/tls 客户端的行为相匹配。可以使用 tls10server=1 GODEBUG 设置来恢复此更改。

默认情况下，在 TLS 1.3 之前的握手过程中，客户端和服务器都不再提供不支持 ECDHE 的密码套件。可以使用 tlsrsakex=1 GODEBUG 设置来恢复此更改。

然而，默认的 go1.22 二进制文件是使用 go1.21 构建的（大多数发行版和官方的 Go 二进制文件），这意味着在检查使用 go1.22 工具链构建的二进制文件时，它们默认都获得了 build DefaultGODEBUG=httplaxcontentlength=1,httpmuxgo121=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1。

这意味着，与发行说明相反，对于任何使用 1.22 工具链的人来说，所有这些强化的行为实际上都未被启用。

“自 1.2N 版起”的行为更改实际上在 “1.2(N+1)” 版中默认启用，这是有意为之的吗？


更多关于Golang新引入的GODEBUG功能是否在同一个版本中生效？的实战教程也可以访问 https://www.itying.com/category-94-b0.html

3 回复

我想我明白它的意思了

当环境变量中没有列出某个 GODEBUG 设置时，其值来源于三个地方：用于构建程序的 Go 工具链的默认值，根据 go.mod 中列出的 Go 版本进行修正，然后被程序中显式的 //go:debug 行覆盖。

所以这些程序都没有使用 1.22 的默认值，因为它们的 go.mod 中列出了 go 1.21。原来如此。看来我可能需要在构建时显式设置 GODEBUG，才能让程序按照我想要的方式工作。

更多关于Golang新引入的GODEBUG功能是否在同一个版本中生效？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


xnox:

Go 1.22 引入了多项强化的 Go 工具链行为。在 Go 1.22 发布说明 中可以看到：

crypto/tls

除非使用 TLS 1.3，或者服务器和客户端都支持 extended_master_secret 扩展，否则 ConnectionState.ExportKeyingMaterial 现在将返回一个错误。自 Go 1.20 起，crypto/tls 已支持此扩展。可以通过 tlsunsafeekm=1 的 GODEBUG 设置来禁用此行为。

默认情况下，如果未通过 config.MinimumVersion 指定，crypto/tls 服务器提供的最低版本现在是 TLS 1.2，这与 crypto/tls 客户端的行为相匹配。可以通过 tls10server=1 的 GODEBUG 设置来恢复此更改。

默认情况下，在 TLS 1.3 之前的握手过程中，客户端和服务器都不再提供不支持 ECDHE 的密码套件。可以通过 tlsrsakex=1 的 GODEBUG 设置来恢复此更改。

然而，默认的 go1.22 二进制文件是使用 go1.21 构建的（大多数发行版以及官方的 Go 二进制文件都是如此），这意味着在检查使用 go1.22 工具链构建的二进制文件时，它们默认都获得了 build DefaultGODEBUG=httplaxcontentlength=1,httpmuxgo121=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1。

这意味着，与发布说明相反，对于任何使用 1.22 工具链的人来说，所有这些强化行为实际上都未被启用。

从“1.2N”版本开始的“行为更改”实际上是在“1.2(N+1)”版本中默认启用的，这是有意为之的吗？

Go 的未来版本（1.22 之后）很可能会在预构建的二进制文件中默认启用这些安全强化更改。这将最终强制执行 Go 1.22 发布说明中描述的更严格的 TLS 要求。

在 Go 1.22 中，GODEBUG 功能的行为确实存在版本差异。当使用 go1.22 工具链构建二进制文件时，默认的 GODEBUG 设置会包含 tls10server=1,tlsrsakex=1,tlsunsafeekm=1 等值，这意味着这些安全强化功能默认是禁用的。这是 Go 团队为了保持向后兼容性而采取的策略。

具体来说，只有当二进制文件使用 go1.23 或更高版本的工具链构建时，这些 GODEBUG 设置才会默认被移除，从而启用安全强化行为。这种设计允许开发者在升级到新版本 Go 时，逐步适应行为变更，避免现有代码因默认行为改变而意外中断。

以下是示例代码，展示如何在 Go 1.22 中显式启用 TLS 1.2 作为服务器最低版本（即禁用 tls10server=1 的默认覆盖）：

package main

import (
    "crypto/tls"
    "fmt"
    "net/http"
)

func main() {
    // 设置 TLS 配置，将最低版本显式指定为 TLS 1.2
    tlsConfig := &tls.Config{
        MinVersion: tls.VersionTLS12,
    }

    server := &http.Server{
        Addr:      ":8443",
        TLSConfig: tlsConfig,
    }

    // 启动 HTTPS 服务器
    fmt.Println("Server starting with TLS 1.2 as minimum version...")
    err := server.ListenAndServeTLS("cert.pem", "key.pem")
    if err != nil {
        fmt.Printf("Server failed: %v\n", err)
    }
}

或者，你可以在运行程序时通过环境变量覆盖 GODEBUG 设置，强制启用新行为：

GODEBUG=tls10server=0 ./your_go_binary

这样，TLS 1.0 和 1.1 将被禁用，服务器最低版本强制为 TLS 1.2。

总结：在 Go 1.22 中，GODEBUG 的默认设置确实会覆盖发行说明中提到的安全强化行为。这是有意为之的兼容性策略，确保现有代码在升级工具链后继续正常工作。要启用新行为，需要显式配置或使用更高版本的工具链构建。

回到顶部