聊聊Go语言的软件供应链安全

本文永久链接 – https://tonybai.com/2022/03/14/software-supply-chain-security-in-go

Go 12岁生日以及Go 1.18 beta1发布的博文中,Go核心团队技术负责人Russ Cox都提到了2022年Go团队将关注Go软件供应链安全,并在Go中为软件供应链提供相关工具。

提到供应链,我们立马想到的它是制造业的存在,在软件开发领域中很少提及。但是近几年,软件领域安全问题频发,使得“供应链”一词在软件开发领域浮出水面,逐渐成为热词。那么,到底啥是软件供应链呢?Go对软件供应链安全的支持现状又是怎样的呢?本文我就来简单梳理一下。

1. 什么是软件供应链?

怎么理解软件供应链呢?

传统供应链的概念可以理解为一个由各种组织、人员、技术、活动、信息和资源组成的将商品或服务从供应商转移到消费者手中的过程,这一过程从原材料开始,将其加工成中间组件乃至最终转移到消费者手中的最终产品。参考这一概念,软件供应链可以理解为软件和系统的从生产到交付全过程,是一套自动化、标准化及规模化的持续交付的流水线。通过设计和开发阶段,将生产完成的软件产品通过软件交付渠道从软件供应链运输给最终用户。

如今,人们最关心的就是软件供应链的安全问题。根据软件供应链的定义,软件供应链安全可以被理解为软件生产的整个过程中软件设计与开发的各个阶段来自编码过程、工具、设备、供应商以及最终交付渠道所共同面临的安全问题。

那究竟有哪些安全问题呢?作为专注于设计与实现的开发人员,我们更加专注于编码构建这一环节。在确定安全问题之前,我们先将前面的软件供应链的广义理解抛开,建立一个更为狭义的理解,即将软件供应链单纯视为以商业组件与开源组件等第三方组件的供应链条。在这一狭义的理解下,我们再来探讨安全问题的来由。

在开源软件兴起之前,一个公司开发出的软件大多数都是经由公司招募的专职开发者一行一行码出来的,语言标准库、C运行时库、系统原生库等集成在编程语言工具和OS层面的组件除外。

开源软件兴起后,无论是大厂巨头,还是小厂初创,都会基于大量的开源软件包来构建自己的产品。这些开源软件包呈现出多样化、复杂化的趋势。并且涉及的领域也十分广泛:从应用级库/包、开发工具、到中间件、到数据库、甚至操作系统以及设备固件。据Forrester 2021年发布的报告数据显示,开源代码占软件代码的比例从2015年到2019年的五年时间内几乎翻了一倍,如下图。

2020年,这一比例更是上升到75%

开源软件包、组件与工具的广泛采用让企业的开发效率大幅提升的同时,也让软件供应链的风险不断增加。风险主要体现在下面几个方面:

  • 安全风险

开源软件正在呈现指数级增长。根据美国国家计算机安全中心(NCSC)公开的数据显示由世界最大的源代码管理平台GitHub托管的公共存储库数量从2009年2月的46000个激增到2020年1月的2800万个。由于开源软件之间的关联依赖关系变得日益复杂,开发人员很难对其依赖的开源包/组件的所有依赖链上的包/组件做出安全评估,这样一旦依赖链上的某一开源包/组件出现未知的安全漏洞,将会导致所有与之存在依赖关系的其他软件系统出现同样的漏洞,漏洞的攻击面将会由点及面呈现出爆炸式的放大效果。并且,即便很快发现安全漏洞,开源软件包的问题修复时间也较长,一般多在1天到一周甚至更多。甚至存在具有非法目的开发者故意预留后门的安全缺陷,攻击者通过将恶意代码注入为全球软件供应链提供组件的开源项目中,借助开源软件的“高信任度”和影响力,通过感染软件供应链的“上游”组件加速向“下游”扩散,从而产生更大的破坏性。

  • 知识产权风险

主要体现在对开源许可证的理解与是否在许可证的要求下使用开源软件包/组件。一旦误用,便会给企业带来知识产权上的风险,甚至风险发生,导致企业的真实损失。

  • 断供风险

由于国际政治原因以及大国博弈,一些大国通过实行严密的技术封锁,建立完善的出口管制法律制度体系,将本国的软件、硬件和技术列入出口管制清单,这回直接导致软件供应链的完整性遭遇严重的挑战。目前在我国,这已经是发生过的事实了。

对于聚焦系统实现环节的开发者而言,安全风险始终是主要考虑的供应链风险。那么,通过哪些手段可以降低软件供应链的安全风险呢?我们继续向下看。

2. 软件供应链的安全风险控制

在软件供应链风险控制这方面,不得不说,软件强国美国走在了世界的前面:

  • 美国政府在2008年颁布《国家网络安全综合倡议》(CNCI),要求在产品、系统和服务的整个生命周期内综合应对国内和全球供应链风险。
  • 2009年奥巴马政府发布的《美国网络空间安全政策评估报告》将ICT供应链安全纳入国家安全范畴。
  • 2012年,美国国土安全部发布首个国家层级的战略报告《全球供应链安全国家战略》,提出安全和高效两大目标。
  • 2013年,美国国家标准和技术研究院(NIST)发布《联邦信息系统与机构供应链风险管理实践》。
  • 2016年,国家网络安全促进委员会发布《加强国家网络安全—促进数字经济的安全与发展》。
  • 2017年,美国国土安全部发布《供应链风险管理计划》
  • 2018年,美国白宫发布《联邦信息技术供应链风险管理改进法案》。
  • 2019年,特朗普签署《确保信息通信技术与服务供应链安全》行政令,禁止交易、使用可能对美国的国家安全、外交政策和经济构成特殊威胁的外国信息技术和服务。
  • 2021年,美国商务部发布《确保信息和通信技术及服务供应链安全》的最新规则生效,对美国国家或公民构成不可接受之风险的外国对手的信息通信技术和服务(ICTS)交易所进行识别、评估和风险消除程序,从而决定是否禁止交易。
  • 2021年5月12日,美国总统拜登发布《关于改善国家网络安全的行政命令》的14028号政令,明确要求联邦政府采取行动,迅速提高软件供应链的安全性和完整性。

我们重点关注一下2021年拜登的《关于改善国家网络安全的行政命令》行政令,该行政令的大多内容都致力于提高软件供应链的安全性,并特别要求政府软件应包含机器可读的软件物料清单(Software Bill Of Materials, SBOM)

什么是SBOM?它被定义为“包含构建软件使用的各种组件的详细信息和供应链关系的正式记录”。它不仅应该详细说明交付的组件,还应该详细说明用于交付软件的工具和框架。SBOM是开启软件开发透明和开放时代的基础。通过机器可读的SBOM,软件的消费者可以得知哪个版本的软件包可能会影响其产品的安全性,而无需依赖软件供应商的安全警报与补丁,并且基于SBOM,消费者能够实施自己的安全控制方案,这些控制方案还可以自动化执行。SBOM使得整个行业在享受开源带来的便利和效率的同时,还可以对安全风险进行更为有效的控制与治理。

美国国家电信和信息管理局(NITA)在14028号政令的要求下,在2021年7月12日发布了《SBOM的最低要素》,该文档为各开发工具的组织和厂商提供了SBOM数据格式的参考。

软件供应链安全的上下文的铺垫有些长!下面我们来聚焦一下Go,看看Go语言在降低软件供应链安全风险方面都提供了哪些支持。

3. Go对软件供应链安全的支持情况

在GOPATH时代,Go即便想在降低软件供应链安全方面为开发者提供一些帮助可能也做不好,甚至是做不到。但Go module的引入扭转了这个局面。

1.13版本开始,Go命令在构建Go应用时会将其依赖的module版本信息嵌入到可执行程序中,同时从1.13版本开始,我们可以通过go version -m命令读取这些嵌入在可执行文件中的应用的module依赖信息。下面是一个例子:

// sbom1.go

package main

import (
    "time"

    "go.uber.org/zap"
)

func main() {
    logger, _ := zap.NewProduction()
    defer logger.Sync()
    url := "http://tonybai.com"
    logger.Info("failed to fetch URL",
        // Structured context as strongly typed Field values.
        zap.String("url", url),
        zap.Int("attempt", 3),
        zap.Duration("backoff", time.Second),
    )
}

使用[Go 1.13, Go 1.17]集合中的Go版本编译上述例子后,可以通过go version -m读取依赖module列表信息:

// 基于go 1.13.6编译sbom1.go
$go build sbom1.go

// 读取依赖module列表信息
$go version -m sbom1
sbom1: go1.13.6
    path    command-line-arguments
    mod demo1   (devel)
    dep go.uber.org/atomic  v1.7.0  h1:ADUqmZGgLDDfbSL9ZmPxKTybcoEYHgpYfELNoN+7hsw=
    dep go.uber.org/multierr    v1.6.0  h1:y6IPFStTAIT5Ytl7/XYmHvzXQ7S3g/IeZW9hyZ5thw4=
    dep go.uber.org/zap v1.21.0 h1:WefMeulhovoZ2sYXz7st6K0sLj7bBhpiFaud4r4zST8=

我们看到:读取的列表信息中不仅包含了sbom1.go的直接依赖module的版本信息,还包括了zap包的传递依赖的module的版本信息,也就是说通过这份信息,我们可以看到sbom1的所有第三方依赖的版本,换句话说对于sbom1的使用者而言,sbom1的构成信息是公开透明的。

如果使用[go 1.11, go 1.12]集合中的Go版本编译上述例子,使用go 1.13及以上版本的go version -m查看可执行文件的依赖module信息是不会成功的:

$go version -m sbom1
sbom1: could not read Go build info from sbom1: not a Go executable

上述嵌入到可执行文件中的依赖module列表信息,就是SBOM的一部分。当然按照上面提到的美国行政令对SBOM的要求:不仅应该详细说明交付的组件,还应该详细说明用于交付软件的工具和框架,仅嵌入这些信息还不够。

于是Go 1.18版本又扩展了嵌入以及可被go version -m读取的信息范围,我们使用go 1.18rc1版本编译上面的sbom1.go并用go version -m读取得到的结果如下:

// go 1.18rc1
$go build sbom1.go
$go version -m sbom1
sbom1: go1.18rc1
    path    command-line-arguments
    dep go.uber.org/atomic  v1.7.0  h1:ADUqmZGgLDDfbSL9ZmPxKTybcoEYHgpYfELNoN+7hsw=
    dep go.uber.org/multierr    v1.6.0  h1:y6IPFStTAIT5Ytl7/XYmHvzXQ7S3g/IeZW9hyZ5thw4=
    dep go.uber.org/zap v1.21.0 h1:WefMeulhovoZ2sYXz7st6K0sLj7bBhpiFaud4r4zST8=
    build   -compiler=gc
    build   CGO_ENABLED=1
    build   CGO_CFLAGS=
    build   CGO_CPPFLAGS=
    build   CGO_CXXFLAGS=
    build   CGO_LDFLAGS=
    build   GOARCH=amd64
    build   GOOS=darwin
    build   GOAMD64=v1

我们看到应用程序的构建信息也被嵌入到最终的可执行文件中了。

当然,除了通过go version命令可以读取Go应用的SBOM信息外,Go还在标准库中提供了API用于读取Go应用可执行文件中嵌入的SBOM信息,看下面例子:

// readsbom.go
package main

import (
    "debug/buildinfo"
    "fmt"
)

func main() {
    info, err := buildinfo.ReadFile("./sbom1")
    if err != nil {
        fmt.Println("read buildinfo error:", err)
        return
    }

    fmt.Printf("%#v\n\n", info)
    for _, d := range info.Deps {
        fmt.Printf("%#v\n", *d)
    }
}

运行这段例子:

$go run readsbom.go
&debug.BuildInfo{GoVersion:"go1.18rc1", Path:"command-line-arguments", Main:debug.Module{Path:"", Version:"", Sum:"", Replace:(*debug.Module)(nil)}, Deps:[]*debug.Module{(*debug.Module)(0xc000026180), (*debug.Module)(0xc0000261c0), (*debug.Module)(0xc000026200)}, Settings:[]debug.BuildSetting{debug.BuildSetting{Key:"-compiler", Value:"gc"}, debug.BuildSetting{Key:"CGO_ENABLED", Value:"1"}, debug.BuildSetting{Key:"CGO_CFLAGS", Value:""}, debug.BuildSetting{Key:"CGO_CPPFLAGS", Value:""}, debug.BuildSetting{Key:"CGO_CXXFLAGS", Value:""}, debug.BuildSetting{Key:"CGO_LDFLAGS", Value:""}, debug.BuildSetting{Key:"GOARCH", Value:"amd64"}, debug.BuildSetting{Key:"GOOS", Value:"darwin"}, debug.BuildSetting{Key:"GOAMD64", Value:"v1"}}}

debug.Module{Path:"go.uber.org/atomic", Version:"v1.7.0", Sum:"h1:ADUqmZGgLDDfbSL9ZmPxKTybcoEYHgpYfELNoN+7hsw=", Replace:(*debug.Module)(nil)}
debug.Module{Path:"go.uber.org/multierr", Version:"v1.6.0", Sum:"h1:y6IPFStTAIT5Ytl7/XYmHvzXQ7S3g/IeZW9hyZ5thw4=", Replace:(*debug.Module)(nil)}
debug.Module{Path:"go.uber.org/zap", Version:"v1.21.0", Sum:"h1:WefMeulhovoZ2sYXz7st6K0sLj7bBhpiFaud4r4zST8=", Replace:(*debug.Module)(nil)}

我们看到,通过debug/buildinfo包查看到的Go应用的SBOM信息与使用go version -m查到的信息是完全一致的。

当然Go对软件供应链安全的支持措施还不仅这些,有了依赖module列表以及构建信息后,开发者还需要检测工具来检查这些“供应链上的组件”是否有安全风险。Go核心团队已经建立了Go vulnerability(漏洞) database,作为后续检测工具的漏洞数据库源。总体来说,Go核心团队对软件供应链安全提供的支持措施还在进行中(WIP),以后甚至会在go命令中提供单独的子命令来对供应链上的组件实施检测。

业界也有一些第三方的供应链安全检测工具,比如国内的“悬镜安全”就开源了一款用Go实现的软件组成分析工具OpenSCA-cli,它可基于漏洞数据库对各种语言实现的软件的供应链上的组件进行安全检测。

4. 小结

现在看来,Go之所以积极推动SBOM的落地是因为美国法律的要求。

针对美第14028号行政命令,美国的NIST发布了《开发者验证软件的最低标准指南(Guidelines on Minimum Standards for Developer Verification of Software)》。这份指南建议采取以下措施对软件进行安全验证:
- 威胁建模以寻找设计层面的安全问题
- 自动测试以保证一致性,并最大限度地减少人力投入
- 静态代码扫描,寻找最重要的漏洞
- 启发式工具来寻找可能存在的硬编码密钥
- 使用内置的检查和保护措施
- 使用”黑盒”测试用例
- 基于代码的结构测试用例
- 历史测试用例
- 模糊测试(Fuzzing)
- 网络应用程序扫描器,如果适用的话
- 解决包含的代码(库、包、服务)。

从这里也可以看到Go 1.18加入对Fuzzing的原生支持,看来很大可能也是为了响应这一指南。

5. 参考资料

  • 软件供应链安全现状与发展对策 – https://zhuanlan.zhihu.com/p/442772376
  • 悬镜安全发布的《2021软件供应链安全白皮书》,关注公众号iamtonybai,发送关键字“2021软件供应链”即可获得该白皮书。
  • Thoughtworks雷达25期 – https://www.thoughtworks.com/content/dam/thoughtworks/documents/radar/2021/10/tr_technology_radar_vol_25_cn.pdf

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

img{512x368}

img{512x368}
img{512x368}
img{512x368}

我爱发短信:企业级短信平台定制开发专家 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
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

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

为什么有了Go module后“依赖地狱”问题依然存在

本文永久链接 – https://tonybai.com/2022/03/12/dependency-hell-in-go

如果所有Gopher都抛弃GOPATH构建模式,拥抱Go module构建模式;如果所有legacy Go package作者都能为自己的legacy package加上go.mod;如果所有Go module作者都严格遵守语义版本(semver)规范,那么Go将彻底解决“依赖地狱”问题

但现实却没那么乐观!Go中的“依赖地狱问题”依然存在。这一篇我们就来聊聊Go中依赖地狱的“发作场景”、原因以及解决方法。

1. 什么是“依赖地狱(dependency hell)”?

“依赖地狱”问题不是某种编程语言独有的问题,而是一个在软件开发和发布领域广泛存在问题维基百科对该问题的广义诠释是这样的:

当几个软件包对相同的共享包或库有依赖性,但它们依赖于不同的、不兼容的共享包版本时,就会出现依赖性问题。如果共享包或库只能安装一个版本,用户可能需要通过获得较新或较旧版本的依赖包来解决这个问题。反过来,这可能会破坏其他的依赖关系。

在软件开发构建领域,我们会面对同样的“依赖地狱”问题。文字总是很难懂,我们用更为直观的示意图来说明什么是软件构建过程中的“依赖地狱”问题,大家先看看下面这个示意图:

我们看到在这幅图中:包P1依赖包P3 V1.5版本,包P2依赖包P3 V2.0版本,App同时依赖包P1和包P2。于是问题出现了:构建工具在构建App这个应用时需要决策究竟要使用包P3的哪个版本:V1.5还是V2.0?当然这个问题存在的一个前提是:App中只允许包含包P3的一个版本

如果P3的V1.5与V2.0版本是不兼容的版本,那么构建工具无论选择包P3的哪个版本,App的构建都会以失败告终。开发人员只能介入手工解决,解决方法无非是将P1对P3的依赖升级到V2.0,或将P2对P3的依赖降级为V1.5版本。但P1、P2多数情况下是第三方开源包,App的开发人员对P1、P2包的作者的影响力有限,因此这种手工解决的成功率也不高。

“依赖地狱”(又称为“钻石依赖”问题)由来已久,几十年来各种编程语言都在努力解决这一问题,并也有了几种可以帮助到开发者的不错的方案。我们先来看看Go语言的解决方案。

2. Go的解决方案

在GOPATH构建模式时代,Go构建工具是无法自动解决上述“依赖地狱”问题的。Go 1.11版本引入Go module构建模式后,经过几年的打磨,Go module构建模式逐渐成熟,并已经成为Go构建模式的标准。

Go module构建模式是可以部分解决上述“依赖地狱”问题的。Go module解决这个问题的思路是:语义导入版本(sematic import versioning)即在包的导入路径上加上包的major version前缀。关于“语义导入版本”的详细介绍,可以参考我的极客时间专栏“Go语言第一课”的相关内容。

使用“语义导入版本”后,Go解决上面那个问题的方案如下图:

我们看到:Go通过打破“App中只允许包含包P3的一个版本”这个前提实现了P1和P2各自使用自己依赖的版本。但这样做的前提是P1和P2依赖的P3版本的major版本号是不同的。在Go中,由于采用语义导入版本机制,major版本号不同的module被视为不同的module,即使它们源于同一个repository(比如上面的源于同一个P3的v1.5和v2.0就被视为两个不同的module)。

当然这种解决方案是有代价的!第一个代价就是构建出来的app的二进制文件size变大了,因为二进制文件中包含了多个版本的P3的代码;第二个代价,可能也算不上代价,更多是要注意的是不同版本的module之间的类型、变量、标识符不能混用,我们以go-redis/redis这个开源项目举个例子。go-redis/redis最新大版本为v8.11.4,没有启用go.mod时的版本为v6.x.x,我们将这两个版本混用在一起:

package main

import (
    "context"

    "github.com/go-redis/redis"
    redis8 "github.com/go-redis/redis/v8"
)

func main() {
    var rdb *redis8.Client
    rdb = redis.NewClient(&redis.Options{
        Addr:     "localhost:6379",
        Password: "", // no password set
        DB:       0,  // use default DB
    })
    _ = rdb
}

Go编译器在编译这段代码时会报如下错误:

cannot use redis.NewClient(&redis.Options{…}) (value of type *"github.com/go-redis/redis".Client) as type *"github.com/go-redis/redis/v8".Client in assignment

即redis v8下的Client与redis Client并非一个类型,即使它们的内部字段相同,也不能混用在一起。

那么,是不是说有了Go module构建机制后,“依赖地狱”问题就彻底从Go开发中被移除了呢?不是的。“依赖地狱”问题依旧存在,下面我们就来看看哪些情况下还会出现此类问题。

3. 哪些情形下“依赖地狱”依旧存在

1) 依赖不带go.mod的legacy Go包

如今Go语言引入Go module已经多年了,但Go社区仍然存在大量legacy的Go包尚未增加go.mod文件。对于这样的go包,Go命令的处理策略大致是这样的:

  • 对于尚未打tag的go包,那么就按等同于v0/v1的方式处理

go命令将go包缓存在本地mod cache时,会合成一个go.mod文件,比如:

// $GOMODCACHE/cache/download
go.starlark.net
└── @v
    ├── list
    ├── list.lock
    ├── v0.0.0-20190702223751-32f345186213.mod // 这里是合成的go.mod
    ├── v0.0.0-20200821142938-949cc6f4b097.info
    ├── v0.0.0-20200821142938-949cc6f4b097.lock
    ├── v0.0.0-20200821142938-949cc6f4b097.mod // 这里是合成的go.mod
    ├── v0.0.0-20200821142938-949cc6f4b097.zip
    ├── v0.0.0-20200821142938-949cc6f4b097.ziphash
    ├── v0.0.0-20210901212718-87f333178d59.info
    └── v0.0.0-20210901212718-87f333178d59.mod // 这里是合成的go.mod
  • 对于已经打了tag的go包且tag的major版本号<2,那么也按等同于v0/v1的方式处理

go命令将这样的go包缓存在本地mod cache时,同样会合成一个go.mod文件,比如:

// $GOMODCACHE/cache/download
pierrec
|-- lz4
|   |-- @v
|   |   |-- list
|   |   |-- v1.0.1.info
|   |   |-- v1.0.1.lock
|   |   |-- v1.0.1.mod // 这里是合成的go.mod
|   |   |-- v1.0.1.zip
|   |   |-- v1.0.1.ziphash
  • 对于打了tag且tag的major版本号>=2的,Go命令将包下载到mod cache中后,同样会为该go包合成一个go.mod文件,该文件名vX.Y.Z+incompatible.mod,比如下面这个例子:
// $GOMODCACHE/cache/download
pierrec
|-- lz4
|   |-- @v
|   |   |-- list
|   |   |-- v2.6.1+incompatible.info
|   |   |-- v2.6.1+incompatible.lock
|   |   |-- v2.6.1+incompatible.mod // 这里是合成的go.mod
|   |   |-- v2.6.1+incompatible.zip
|   |   `-- v2.6.1+incompatible.ziphash

以上三种情况下,合成的.mod文件中的module root path都是不带vN后缀的,无论是否打tag,也不论tag major版本是否>=2,以v2.6.1+incompatible.mod为例,其内容如下:

// v2.6.1+incompatible.mod
module github.com/pierrec/lz4

我们看到,该合成的mod文件中也不包含这个legacy包自身所依赖的第三方包的require代码块。那么依赖lz4这个legacy包的项目如何确定lz4的第三方依赖的版本呢?并且lz4依赖的第三方包的版本记录在哪里呢?我们以app依赖github.com/pierrec/lz4为例,看下面示意图:

go mod命令在做依赖分析时,会根据源码中的import github.com/pierrec/lz4确定lz4的版本,由于没有vN后缀,go命令会找lz4的v2以下的源码中的go.mod,但lz4在这之前都没有添加go.mod,于是只能按照legacy的模式去确定lz4的版本,这里确定的是v2.6.1+incompatible,go命令将其作为app module的直接依赖:

require github.com/pierrec/lz4 v2.6.1+incompatible

之后go命令还会对lz4的依赖做分析,并将其记录到app module的go.mod中,作为indirect依赖:

require github.com/frankban/quicktest v1.14.2 //indirect

将直接依赖的legacy包的第三方依赖记录在自己的go.mod中是为了满足基于go.mod的可重现构建的要求

好了!我们了解了go命令处理legacy go包的方式,再来看看如果出现“钻石依赖”情况下,Go命令是如何处理的?直接给结论,如下图:

在这幅图中,我们让P1依赖lz4的v1.0.1版本,让P2依赖lz4的v2.6.1+incompatible版本,这两个版本都是legacy(未添加go.mod)下打的tag。那么当app既依赖P1又依赖P2时,go命令会如何选择lz4的版本呢?Go命令简单粗暴的选择了同时满足P1和P2的最小版本:v2.6.1+incompatible。这里Go似乎做了一个假设:legacy包的新版本一定是向前兼容老版本的。对于lz4这个包来说,这个假设是正确的,我们对App的构建与执行不会遇到问题。

但是一旦这个假设不成立,比如:lz4的v2.6.1是一个不兼容v1.0.1的发布,那么App的构建将遇到错误。这种情况go命令是无能为力了,只能进行手工干预!那怎么干预呢?无非以下几种手段:

  • 提issue督促P1作者将对lz4的依赖升级到最新v2.6.1版本

这种手段效率低不说,很可能P1的author根本就不会搭理你。

  • fork一个P1,自己修改,然后让App依赖你fork后的P1

这种手段可行,但后续就要自己维护一个fork的P1,无形中给自己增加了额外的负担。

  • vendor下来,自己修改,在vendor目录下维护

这种手段也可行,但后续只能使用vendor模式构建,且要自己维护一个本地的P1,同样也给自己增加了额外的负担。

那就没有更好的方法了么?真没有!从legacy项目到拥抱go module的项目的过渡过程注定是坎坷的。

2) 采用go module机制的依赖包的冲突问题

看完legacy包后,我们再来看依赖是采用go module机制的包的冲突问题。有了对上面例子理解的基础,理解下面的例子的就更容易了,我们来看下面示意图:

这个例子也很简单,P1和P2都依赖module P3,分别依赖P3的v1.1.0版本和v1.2.0版本,和之前的例子一样,App既依赖P1,也依赖P2,这样就构成了图中右侧的“钻石结构”。不过,Go module的另外一个机制:最小版本选择(MVS)可以很好的解决这个依赖问题,关于MVS的详情,同样可以参考我的极客时间专栏“Go语言第一课”的相关内容。

MVS机制同样是基于语义版本之上的,它会选择满足此App依赖的最小可用版本,这里P3的v1.1.0版本与v1.2.0版本的major版本号相同,因此按照语义版本规范,他们是兼容的版本,于是go命令选择了满足app依赖的最小可用版本为v1.2.0(此时P3的最高版本为v1.7.0,Go命令没有选择最高版本)。

不过理论约定与实际常常脱节,一旦P3的author在发布v1.2.0时没有识别出与v1.1.0的不兼容change,那么这种情况下,不兼容v1.1.0的P3版本会导致对P1包的构建失败!这就是采用go module机制的依赖包时最常见的“依赖地狱”问题。

可以看到,这个问题的根源还是在于go module的author。识别不兼容的change难吗?也不难,但的确繁琐,费脑子。那么作为module author, 如何尽量避免未按照语义版本规范发布版本号兼容实则不兼容的module版本呢?

Go社区的作法分为两类:

  • 极端作法:
    • 不发布1.0版本,一直在0.x.y,不承诺新版本兼容老版本;
    • 每次发稍大一些的版本都升级major版本号,这样既避免了繁琐的检查是否有不兼容change的问题,也肯定不会给社区带去“依赖地狱”问题。
  • 常规作法:
    • 检查是否有不兼容change,只有在存在不兼容change的情况下,才升级major版本。

Go官博曾经发表过一篇名为《Keeping Your Modules Compatible》的文章,以告诉大家如何检查新的change中是否有不兼容的change。文中还提到Go团队已经开发了一个名为gorelease的工具来帮助Go开发者检测新版本与旧版本之间是否存在不兼容的变化(当然,工具也很可能不能完全扫描出来不兼容性change),大家可以在这里查看gorelease的详细用法

4. 未来畅想

近几年成长时候也很迅猛的Rust语言在面对“依赖地狱”这一问题上似乎走到了Go的前面,在《How Rust Solved Dependency Hell》一文中大致讲解了Rust解决这一问题的方案。其原理大致是利用的名字修饰,即同一个依赖的两个不兼容的版本可以共存与一个Rust应用中,每个版本中的标识符在应用中都是独一无二的,Rust通过包名、版本号等作为名字修饰以达到此目的。

那么,未来Go module是否能做到这点呢?笔者认为是可行的,并且是兼容于现在go module的机制的。Go module的引入,实则也是一种“namespace”的概念,具备像Rust那样解决问题的基础。但Go团队是否要这么做就是另当别论了,因为一旦Go语言世界像本文开篇中所提到的那样,那么现有机制也可以很好地解决“依赖地狱”问题。


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

img{512x368}

img{512x368}
img{512x368}
img{512x368}

我爱发短信:企业级短信平台定制开发专家 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
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats