为什么 go.sum 包含这么多旧包答案

【问题标题】：Why does go.sum include so many older packages为什么 go.sum 包含这么多旧包
【发布时间】：2021-11-18 06:21:37
【问题描述】：

我一直在研究一组项目，处理更新依赖项，有一件事我没有明确的答案，这就是为什么生成的 sum 文件列出了每个依赖项的这么多旧版本的原因。

在我们的项目中，我们通过旧版本的 golang.org/x/crypto 我们通过 replace 指令解决了带有安全修复程序的软件包版本，但这感觉不太正确，可能会将我们锁定在不安全的软件包版本中。

现在我已经完成并更新了依赖于旧版本 golang.org/x/crypto 的包，并使用 replace 指令循环回包并尝试更新，但我仍然看到列出的旧包。

我想知道这对我们的项目意味着什么，以及我如何才能找到为什么首先包含这些内容？

运行一个简单的 go mod why -m golang.org/x/crypto 表明唯一依赖于的项目 golang.org/x/crypto 是我更新的那个。

【问题讨论】：

Why does 'go.sum' include information for module versions I am no longer using? 和 go.sum files：“go 命令可能需要从依赖项的多个版本加载 go.mod 文件，以便执行最小版本选择。”
尝试运行go mod tidy 命令golang.org/ref/mod#go-mod-tidy
@JimB 感谢您的链接，我在搜索中错过了该链接。那么关于表明crypto的X.Y.Z版本有漏洞的漏洞扫描，这是否意味着只要我的项目包含带有漏洞补丁的更高版本，扫描可能会错误地指示漏洞？
漏洞扫描程序应该检查go.mod 以了解正在使用的确切版本。 go.sum 只是软件包版本的记录，而不是正在编译的内容。看起来你应该能够在不诉诸 replace 的情况下更新加密包，但它对理解 go 依赖项的扫描器应该没有影响。
这取决于扫描仪，但如果您将go.mod 更新为go1.17 可能会有所帮助，这将包括静态验证的所有间接依赖项。

标签： go go-modules

【解决方案1】：

@JimB 在go sum 上提供了一些文档，并附有以下声明

go.sum 文件可能包含一个模块的多个版本的哈希值。 go 命令可能需要从依赖项的多个版本中加载 go.mod 文件，以便执行最小版本选择。 go.sum 还可能包含不再需要的模块版本的哈希值（例如，在升级之后）。 go mod tidy 将添加缺失的哈希，并从 go.sum 中删除不必要的哈希。

go sum 中定义的结果包集来自minimal version selection 进程，这似乎是一个很深的话题。

例如，将"google.golang.org/grpc/metadata" 导入模块，在模块中运行go mod tidy，生成的总和文件的一小部分如下：

github.com/golang/protobuf v1.2.0/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U=
github.com/golang/protobuf v1.3.2/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U=
github.com/golang/protobuf v1.3.3/go.mod h1:vzj43D7+SQXF/4pzW/hwtAqwc6iTitCiVSaWz5lYuqw=
github.com/golang/protobuf v1.4.0-rc.1/go.mod h1:ceaxUfeHdC40wWswd/P6IGgMaK3YpKi5j83Wpe3EHw8=
github.com/golang/protobuf v1.4.0-rc.1.0.20200221234624-67d41d38c208/go.mod h1:xKAWHe0F5eneWXFV3EuXVDTCmh+JuBKY0li0aMyXATA=
github.com/golang/protobuf v1.4.0-rc.2/go.mod h1:LlEzMj4AhA7rCAGe4KMBDvJI+AwstrUpVNzEA03Pprs=
github.com/golang/protobuf v1.4.0-rc.4.0.20200313231945-b860323f09d0/go.mod h1:WU3c8KckQ9AFe+yFwt9sWVRKCVIyN9cPHBJSNnbL67w=
github.com/golang/protobuf v1.4.0/go.mod h1:jodUvKwWbYaEsadDk5Fwe5c77LiNKVO9IDvqG2KuDX0=
github.com/golang/protobuf v1.4.1/go.mod h1:U8fpvMrcmy5pZrNK1lt4xCsGvpyWQ/VVv6QDs8UjoX8=
github.com/golang/protobuf v1.4.2/go.mod h1:oDoupMAO8OvCJWAcko0GGGIgR6R6ocIYbsSw735rRwI=
github.com/golang/protobuf v1.4.3/go.mod h1:oDoupMAO8OvCJWAcko0GGGIgR6R6ocIYbsSw735rRwI=

对版本的每个引用都表示最小版本选择算法图中的一个节点

将以下内容添加到 mod 文件中

replace github.com/golang/protobuf => github.com/golang/protobuf v1.4.3

并运行go mod tidy，protobuf 的结果总和条目将更改为：

github.com/golang/protobuf v1.4.3/go.mod h1:oDoupMAO8OvCJWAcko0GGGIgR6R6ocIYbsSw735rRwI=

因为replace 指令指示替换所有版本，因此依赖关系图中的所有节点都替换为 v1.4.3，这只是简化为包含依赖 v1.4.3 的单个版本

至于我在漏洞扫描器上遇到的问题，它的作者似乎不知道应该如何检查 Golang 的依赖关系，并将模块升级到 1.17，其中 mod 文件中列出了间接依赖关系并没有阻止总和条目将项目标记为漏洞。

【讨论】：