本文永久链接 – https://tonybai.com/2022/10/25/the-modules-that-go-standard-library-depend-on

对于程序员来说，编写的代码依赖标准库是“天经地义”的事情。标准库在程序员眼中就是高质量的代名词，也是最值得信赖的非自己所写的代码，当然更是代码包依赖关系链条上的最后一环，即所有直接或间接依赖的第三方module最终都会依赖标准库。

前两天组内学习rust的小伙伴说rust的标准库还依赖第三方库(注：我对rust了解不深，尚未证实)，这引发了我的一个疑问: Go标准库是否依赖其他modules呢？在这一短篇中，我就来探究一下

注：本文使用的Go版本为Go 1.19。

众所周知，Go于1.11版本引入go modules，如今Go module已经完全替代掉原先的gopath构建模式，成为了Go源码的标准构建模式。

相应的，Go标准库也在Go 1.13版本中采用了Go module构建，加入了go.mod文件，第一版标准库的go.mod文件内容如下：

module std

go 1.12

require (
    golang.org/x/crypto v0.0.0-20190611184440-5c40567a22f8
    golang.org/x/net v0.0.0-20190813141303-74dc4d7220e7
    golang.org/x/sys v0.0.0-20190529130038-5219a1e1c5f8 // indirect
    golang.org/x/text v0.3.2 // indirect
)

我们看到Go标准库的module path为std。不过就像开篇说的那样，很多gopher认为标准库应该是依赖链的末端，但从go.mod文件的内容来看，Go标准库也有自己的依赖。

我们再来看看Go 1.19版本中go.mod的内容：

module std

go 1.19

require (
    golang.org/x/crypto v0.0.0-20220516162934-403b01795ae8
    golang.org/x/net v0.0.0-20220517181318-183a9ca12b87
)

require (
    golang.org/x/sys v0.0.0-20220614162138-6c1b26c55098 // indirect
    golang.org/x/text v0.3.8-0.20220509174342-b4bca84b0361 // indirect
)

我们看到：和Go 1.13版本相比，Go标准库的go.mod将直接依赖和间接依赖(也叫传递依赖)分开放在不同的require block中，这是因为Go 1.17版本增加的module依赖图修剪特性。

但从Go标准库依赖的modules来看，和Go 1.13相比，Go标准库依赖的modules并没有变化。

Go标准库依赖的是什么modules呢？我们看到其依赖的module都在golang.org/x这个路径下，这是Go核心团队自己维护的非标准库module的Canonical import paths的前缀路径。golang.org/x这个前缀路径下的包有不少，如下图所示：

其中，主要的可以被import的功能module包括：

• crypto：额外的密码学软件包
• image：额外的图像处理包
• net：额外的网络相关处理包
• sync：额外的并发同步原语包
• sys：用于进行系统调用的软件包
• text：用于处理文本的软件包
• time：额外的时间处理相关包
• exp：实验性(experimental)的和废弃的(deprecated)软件包

注：exp下面的包尽量不用，或务必谨慎使用，这里实验性包居多，API接口和具体实现变化可能性很大。还有一些是废弃不再维护的。

那Go标准库为什么会直接依赖crypto和net这两个modules呢？

我的理解是网络与密码学是两个变化较快的领域，同时也是两个十分重要的领域，尤其是在如今对安全十分重视的云原生时代。一些新的密码学算法、网络技术规范(RFC)在不断的出现并持续演进，这些技术在未成熟前尚不适合放入标准库，那么在标准库之外由Go核心团队维护一个“与时俱进”的库就十分必要。等成熟后，在标准库中设计并提供稳定接口并引用golang.org/x/abc下的实现就可以很快实现对某成熟网络技术或密码学技术的稳定支持，当年Go 1.6版本对http/2的支持就是这么做的。

那么Go标准库都依赖了哪些具体的包了呢？我们可以看一下\$GOROOT/src/vendor下面的modules.txt：

# golang.org/x/crypto v0.0.0-20220516162934-403b01795ae8
## explicit; go 1.17
golang.org/x/crypto/chacha20
golang.org/x/crypto/chacha20poly1305
golang.org/x/crypto/cryptobyte
golang.org/x/crypto/cryptobyte/asn1
golang.org/x/crypto/curve25519
golang.org/x/crypto/curve25519/internal/field
golang.org/x/crypto/hkdf
golang.org/x/crypto/internal/poly1305
golang.org/x/crypto/internal/subtle
# golang.org/x/net v0.0.0-20220517181318-183a9ca12b87
## explicit; go 1.17
golang.org/x/net/dns/dnsmessage
golang.org/x/net/http/httpguts
golang.org/x/net/http/httpproxy
golang.org/x/net/http2/hpack
golang.org/x/net/idna
golang.org/x/net/lif
golang.org/x/net/nettest
golang.org/x/net/route
# golang.org/x/sys v0.0.0-20220614162138-6c1b26c55098
## explicit; go 1.17
golang.org/x/sys/cpu
# golang.org/x/text v0.3.8-0.20220509174342-b4bca84b0361
## explicit; go 1.17
golang.org/x/text/secure/bidirule
golang.org/x/text/transform
golang.org/x/text/unicode/bidi
golang.org/x/text/unicode/norm

modules.txt是go mod vendor命令生成的，也是项目依赖包的完全列表，包括间接依赖的包。

我们可以通过go mod why命令查询为什么标准库要依赖这些module以及package，以golang.org/x/crypto这个module为例：

$go mod why -m golang.org/x/crypto
# golang.org/x/crypto
crypto/tls
golang.org/x/crypto/chacha20poly1305

我们看到是crypto/tls包依赖了golang.org/x/crypto这个module，但why只会输出标准库中依赖x/crypto module的一个包而已，并非全部。同理我们也可以查看modules.txt某个具体的包为何要被依赖，以golang.org/x/net/dns/dnsmessage为例：

$go mod why golang.org/x/net/dns/dnsmessage
# golang.org/x/net/dns/dnsmessage
net
golang.org/x/net/dns/dnsmessage

我们看到net包依赖了dnsmessage这个包。

综上，我们知道了Go标准库也是会依赖的，但其依赖的module被严格限制在Go核心团队自己维护的golang.org/x下面的少数module，因此我们依然可以完全信任Go标准库，相信后续Go标准库也会一直保证实现的高质量。

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2022年，Gopher部落全面改版，将持续分享Go语言与Go应用领域的知识、技巧与实践，并增加诸多互动形式。欢迎大家加入！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

• 微博：https://weibo.com/bigwhite20xx
• 博客：tonybai.com
• github: https://github.com/bigwhite

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

本文永久链接 – https://tonybai.com/2022/09/10/an-intro-of-govulncheck

2022年9月7日，Go安全团队在Go官博发表文章《Vulnerability Management for Go》，正式向所有Gopher介绍Go对安全漏洞管理的工具和方案。

在这篇文章中，Go安全团队引入了一个名为govulncheck的命令行工具。这个工具本质上只是Go安全漏洞数据库(Go vulnerability database)的一个前端，它通过Go官方维护的vuln仓库下面的vulncheck包对你仓库中的Go源码或编译后的Go应用可执行二进制文件进行扫描，形成源码的调用图(callgraph)和调用栈(callstack)。

vuln仓库下面的client包则提供了访问漏洞数据源(支持多数据源)的接口和默认实现，开发人员可以基于module的路径或ID从漏洞数据库中查找是否存在已知的漏洞。而漏洞项采用OSV, Open Source Vulnerability format格式存储和传输，vuln仓库同样提供了对osv格式的实现包osv。

注：你也可以基于vuln仓库下面的vulncheck包、client包等开发你自己的vulnerability检查前端，或将其集成到你的组织内部的工具链中。

和sumdb、proxy等一样，Go官方维护了一个默认的漏洞数据库vuln.go.dev，如上图所示，该数据库接纳来自知名漏洞数据源的数据，比如：NVD、GHSA等，Go安全团队发现和修复的漏洞以及最广大的go开源项目维护者提交的漏洞。

如果你是知名go开源项目的维护者，当你发现并修复你的项目的漏洞后，可以在Go漏洞管理页面找到不同类型漏洞的提交/上报入口，Go安全团队会对你上报的公共漏洞信息进行审核和确认。

好了，作为Gopher，我们更关心的是我们正在开发的Go项目中是否存在安全漏洞，这些漏洞或是来自Go编译器，或是来自依赖的有漏洞的第三方包。我们要学会使用govulncheck工具对我们的项目进行扫描。

govulncheck目前维护在golang.org/x/vuln下面，按照官博的说法，后期该工具会随同Go安装包一并发布，但是否会集成到go命令中尚不可知。现在要使用govulncheck，我们必须手动安装，命令如下：

$go install golang.org/x/vuln/cmd/govulncheck@latest

安装成功后，便可以在你的Go项目根目录下执行下面命令对整个项目进行漏洞检查了：

$govulncheck ./...

下面是我对自己项目的扫描的结果(扫描时使用的是Go 1.18版本)：

$govulncheck ./...
govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback.

Scanning for dependencies with known vulnerabilities...
Found 9 known vulnerabilities.

Vulnerability #1: GO-2022-0524
  Calling Reader.Read on an archive containing a large number of
  concatenated 0-length compressed files can cause a panic due to
  stack exhaustion.

  Call stacks in your code:
      raft/fsm.go:193:29: example.com/go/mynamespace/demo1/raft.updOnlyLinearizableSM.RecoverFromSnapshot calls io/ioutil.ReadAll, which eventually calls compress/gzip.Reader.Read

  Found in: compress/gzip@go1.18
  Fixed in: compress/gzip@go1.18.4
  More info: https://pkg.go.dev/vuln/GO-2022-0524

Vulnerability #2: GO-2022-0531
  An attacker can correlate a resumed TLS session with a previous
  connection. Session tickets generated by crypto/tls do not
  contain a randomly generated ticket_age_add, which allows an
  attacker that can observe TLS handshakes to correlate successive
  connections by comparing ticket ages during session resumption.

  Call stacks in your code:
      raft/raft.go:68:35: example.com/go/mynamespace/demo1/raft.NewRaftNode calls github.com/lni/dragonboat/v3.NewNodeHost, which eventually calls crypto/tls.Conn.Handshake

  Found in: crypto/tls@go1.18
  Fixed in: crypto/tls@go1.18.3
  More info: https://pkg.go.dev/vuln/GO-2022-0531

... ...

Vulnerability #6: GO-2021-0057
  Due to improper bounds checking, maliciously crafted JSON
  objects can cause an out-of-bounds panic. If parsing user input,
  this may be used as a denial of service vector.

  Call stacks in your code:
      cmd/demo1/main.go:352:23: example.com/go/mynamespace/demo1/cmd/demo1.main calls example.com/go/mynamespace/common/naming.Register, which eventually calls github.com/buger/jsonparser.GetInt

  Found in: github.com/buger/jsonparser@v0.0.0-20181115193947-bf1c66bbce23
  Fixed in: github.com/buger/jsonparser@v1.1.1
  More info: https://pkg.go.dev/vuln/GO-2021-0057

... ...
Vulnerability #9: GO-2022-0522
  Calling Glob on a path which contains a large number of path
  separators can cause a panic due to stack exhaustion.

  Call stacks in your code:
      service/service.go:45:12: example.com/go/mynamespace/demo1/service.NewPubsubService calls example.com/go/mynamespace/common/log.Logger.Fatal, which eventually calls path/filepath.Glob

  Found in: path/filepath@go1.18
  Fixed in: path/filepath@go1.18.4
  More info: https://pkg.go.dev/vuln/GO-2022-0522

=== Informational ===

The vulnerabilities below are in packages that you import, but your code
doesn't appear to call any vulnerable functions. You may not need to take any
action. See https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck
for details.

Vulnerability #1: GO-2022-0537
  Decoding big.Float and big.Rat types can panic if the encoded message is
  too short, potentially allowing a denial of service.

  Found in: math/big@go1.18
  Fixed in: math/big@go1.18.5
  More info: https://pkg.go.dev/vuln/GO-2022-0537

... ...

Vulnerability #9: GO-2021-0052
  Due to improper HTTP header santization, a malicious user can spoof their
  source IP address by setting the X-Forwarded-For header. This may allow
  a user to bypass IP based restrictions, or obfuscate their true source.

  Found in: github.com/gin-gonic/gin@v1.6.3
  Fixed in: github.com/gin-gonic/gin@v1.7.7
  More info: https://pkg.go.dev/vuln/GO-2021-0052

我们看到govulncheck输出的信息分为两部分，一部分是扫描出来的项目存在的安全漏洞，针对这些漏洞你必须fix；而另外一部分(由=== Informational === 分隔的)则是列出一些带有安全漏洞的包，这些包是你直接导入或间接依赖的，但是你并未直接调用存在漏洞的包中的函数或方法，因此无需采取任何弥补措施。这样，我们仅需重点关注第一部分信息即可。

根据漏洞所在的宿主不同，第一部分的信息也可以分为两类：一类是Go语言自身(包括Go编译器、Go运行时和Go标准库等)引入的漏洞，另外一类则是第三方包(包括直接依赖的以及间接依赖的)引入的漏洞。

针对这两类漏洞，我们的解决方法有所不同。

第一类漏洞的解决方法十分简单，直接升级Go版本即可，比如这里我将我的Go版本从Go 1.18升级到最新的Go 1.18.6(2022.9.7日刚刚发布的)即可消除上面的所有第一类漏洞。

而第二类漏洞，即第三方包引入的漏洞，消除起来就要仔细考量一番了。

我们也分成两种情况来看：

• 直接依赖包中存在安全漏洞

如果是项目的直接依赖包的代码中有安全漏洞，这种情况较为简单，根据govulncheck的fix提示，直接升级(go get)到对应的版本即可。

• 间接依赖包中存在安全漏洞

假设我们的project依赖A包，而A包又依赖B包，而govulncheck恰恰扫描出B包存在漏洞，且该漏洞所在函数/方法被我们的项目通过A包调用了。这时我们该如何fix呢？

我们可以直接升级B包的版本吗？不确定！这与go module的依赖管理机制有关，go module正确管理的前提是所有包的版本真正符合semver(语义版本)规范。如果B包没有完全遵守semver规范，一旦单独升级B包版本，这很可能导致A包无法使用升级后的B包而致使我们的项目无法编译通过。在这种情况下，我们应该首先考虑升级A包，如果A包是我们自己可控的基础库，比如common之类的，我们应该先消除A包的漏洞（顺便升级了B包的版本），然后通过升级A包版本来消除这样的漏洞情况。

如果A包并非我们可控的包，而是某个公共开源包，那也要先查找A包是否已经发布了修复B包漏洞的新版本，如果找到了，直接升级A包到新版本即可解决问题。

如果A包没有修复B包的漏洞，那么问题就略复杂了。我们可以尝试升级B包来修复，如果依旧无法修复，那么我们要么给A包提PR，要么fork一份A，自己修复并直接依赖fork后的A。

如果这种间接依赖链比较长，那么修正这样的漏洞的确比较繁琐，大家务必要有耐心地从直接依赖包逐层向下升级依赖包版本。

govulncheck工具的推出丰富了我们对项目进行安全漏洞检查的手段。如果你的项目在github上开源的话，还可以使用github每周security alert来获取安全漏洞信息(如下图所示这样)：

并且github提供了很便利的一键fix的方案。

对于公司内的私有商业项目，不管你之前用什么工具对软件供应链进行安全扫描，现在我们有了govulncheck，建议定期用它扫描一下。

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2022年，Gopher部落全面改版，将持续分享Go语言与Go应用领域的知识、技巧与实践，并增加诸多互动形式。欢迎大家加入！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

• 微博：https://weibo.com/bigwhite20xx
• 博客：tonybai.com
• github: https://github.com/bigwhite

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。