Github | Tony Bai

标签 github 下的文章

小厂内部私有Go module拉取方案（续）

六月 18, 2022
3 条评论

本文永久链接 – https://tonybai.com/2022/06/18/the-approach-to-go-get-private-go-module-in-house-part2

自从去年在公司搭建了内部私有Go module proxy后，我们的私有代理工作得基本良好。按理说，这篇续篇本不该存在:)。

日子一天天过去，Go团队逐渐壮大，空气中都充满了“Go的香气”。

突然有一天，业务线考虑将目前在用的gerrit换成gitlab。最初使用gerrit的原因不得而知，但我猜是想使用gerrit强大且独特的code review机制和相应的工作流。不过由于业务需求变化太快，每个迭代的功能都很多，“+2”的review机制到后来就形同虚设了。

如果不用gerrit review工作流，那么gerrit还有什么存在的价值呢。从管理员那边反馈，gerrit配置起来也是比较复杂的，尤其是权限。两者叠加就有了迁移到gitlab的想法。这样摆在Go团队面前的一个事情就是如何让我们内部私有go module代理适配gitlab。

如果你还不清楚我们搭建私有Go module代理的原理，那么在进一步往下阅读前，请先阅读一下《小厂内部私有Go module拉取方案》。

适配gitlab

回顾一下我们的私有Go module代理的原理图：

基于这张原理图，我们分析后得出结论：要适配gitlab仓库，其实很简单，只需修改govanityurls的配置文件中的各个module的真实repo地址即可，这也符合更换一个后端代码仓库服务理论上开发人员无感的原则。

下面我们在gitlab上创建一个foo repo，其对应的module path为mycompany.com/go/foo。我们使用ssh方式拉取gitlab repo，先将goproxy所在主机的公钥添加到gitlab ssh key中。然后将gitlab clone按钮提示框中给出的clone地址：git@10.10.30.30:go/foo.git填到vanity.yaml文件中：

//vanity.yaml
  ... ...
  /go/foo:
     repo: ssh://git@10.10.30.30:go/foo.git
     vcs: git

我门在一台开发机上建立测试程序，该程序导入mycompany.com/go/foo，执行go mod tidy命令的结果如下：

$go mod tidy
go: finding module for package mycompany.com/go/foo
demo imports
    mycompany.com/go/foo: cannot find module providing package mycompany.com/go/foo: module mycompany.com/go/foo: reading http://10.10.20.20:10000/mycompany.com/go/foo/@v/list: 404 Not Found
    server response:
    go list -m -json -versions mycompany.com/go/foo@latest:
    go: mycompany.com/go/foo@latest: unrecognized import path "mycompany.com/go/foo": http://mycompany.com/go/foo?go-get=1: invalid repo root "ssh://git@10.10.30.30:go/foo.git": parse "ssh://git@10.10.30.30:go/foo.git": invalid port ":go" after host

从goproxy返回的response内容来看，似乎是goproxy使用的go命令无法识别：”ssh://git@10.10.30.30:go/foo.git”，认为10.10.30.30后面的分号后面应该接一个端口，而不是go。

我们将repo换成下面这样的格式：

  /go/foo:
     repo: ssh://git@10.10.30.30:80/go/foo.git
     vcs: git

重启govanityurls并重新执行go mod tidy，依旧报错：

$go mod tidy
go: finding module for package mycompany.com/go/foo
demo imports
    mycompany.com/go/foo: cannot find module providing package mycompany.com/go/foo: module mycompany.com/go/foo: reading http://10.10.20.20:10000/mycompany.com/go/foo/@v/list: 404 Not Found
    server response:
    go list -m -json -versions mycompany.com/go/foo@latest:
    go: module mycompany.com/go/foo: git ls-remote -q origin in /root/.bin/goproxycache/pkg/mod/cache/vcs/4d37c02c151342112bd2d7e6cf9c0508b31b8fe1cf27063da6774aa0f53d872f: exit status 128:
        kex_exchange_identification: Connection closed by remote host
        fatal: Could not read from remote repository.

直接在主机上通过git clone git@10.10.30.30:80/go/foo.git也是报错的！ssh不行，我们再来试试http方式。使用http方式呢，每次clone都需要输入用户名密码，不适合goproxy。是时候让personal token上阵了！在gitlab上分配好personal token，然后在本地建立~/.netrc如下：

# cat ~/.netrc
machine 10.10.30.30
login tonybai
password [your personal token]

然后我们将vanity.yaml中的repo改为如下形式：

// vanity.yaml

  /go/foo:
     repo: http://10.10.30.30/go/foo.git
     vcs: git

这样再执行go mod tidy，foo仓库就被顺利拉取了下来。

答疑

1. git clone错误

在搭建goproxy时，我们通常会在goproxy服务器上手工验证一下是否可以通过git成功拉取私有仓库，如果git clone出现下面错误信息，是什么问题呢？

$ git clone ssh://tonybai@10.10.30.30:29418/go/common
Cloning into 'common'...
Unable to negotiate with 10.10.30.30 port 29418: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

这里的错误提示信息其实是很清楚明了的。git服务器端支持diffie-hellman-group1-sha1和diffie-hellman-group14-sha1这两种密钥交换方法，而git客户端却默认一个都不支持。

怎么解决呢？我们需要在goproxy所在主机增加一个配置.ssh/config：

// ~/.ssh/config
Host 10.10.30.30
    HostName 10.10.30.30
    User tonybai
    Port 29418
    KexAlgorithms +diffie-hellman-group1-sha1

    IdentityFile ~/.ssh/id_rsa

有了这条配置后，我们就可以成功clone。

2. 使用非安全连接

有些童鞋使用这个方案后会遇到下面问题：

$go get mycompany.com/go/common@latest
go: module mycompany.com/go/common: reading http://10.10.30.30:10000/mycompany.com/go/common/@v/list: 404 Not Found
    server response:
    go list -m -json -versions mycompany.com/go/common@latest:
    go list -m: mycompany.com/go/common@latest: unrecognized import path "mycompany.com/go/common": https fetch: Get "https://mycompany.com/go/common?go-get=1": dial tcp 127.0.0.1:443: connect: connection refused

首先，go get得到的服务端响应信息中提示：无法连接127.0.0.1:443，查看goproxy主机的nginx access.log，也无日志。说明goproxy没有发起请求。也就是说问题出在go list命令这块，它为什么要去连127.0.0.1:443？我们的代码服务器使用的可是http而非https方式访问。

这让我想起了Go 1.14中增加的GOINSECURE，go命令默认采用的是secure方式，即https去访问代码仓库的。如果不要求非得以https获取module，或者即便使用https，也不再对server证书进行校验，那么需要设置GOINSECURE环境变量，比如；

export GOINSECURE="mycompany.com"

这样再获取mycompany.com/…下面的go module时，就不会出现上面的错误了！

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

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
博客：tonybai.com
github: https://github.com/bigwhite

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

Go是如何缓解供应链攻击的[译]

四月 2, 2022
0 条评论

本文永久链接 – https://tonybai.com/2022/04/02/how-go-mitigates-supply-chain-attacks

这些年来，关于软件供应链的安全问题频发，软件供应链已然成为IT安全领域的一个热点，在前不久的《聊聊Go语言的软件供应链安全》一文中我曾提到过Go在SBOM(软件物料清单)方面给开发人员带来的方便。这两天Go官博又发表了一篇由Go项目安全负责人Filippo Valsorda撰写的文章《How Go Mitigates Supply Chain Attacks》，系统总结了Go语言应对软件供应链方面攻击的“防护秘笈”。笔者觉得文章中提到的这些点是每个Gopher都应该知道的必备知识，于是这里将文章做简单翻译，供大家参考。

现代软件工程基于相互协作，并以重用开源软件为基础。但这也使软件项目成为了供应链攻击的目标，攻击方式就是破坏软件项目的依赖(dependencies)。

尽管知道这些，为了完成项目，我们需要依赖，我们会采取一些流程或技术措施在项目与依赖之间建立一种信任关系。好在，Go的工具链与设计可以帮助我们降低各个阶段的风险。

所有构建都是被“锁定(locked)”的

外部世界的变化，比如项目的某个依赖发布了一个新版本，是不会影响到Go的构建的。

与其他大多数软件包管理器(package manager)所使用的配置文件不同，Go module没有将存储约束列表的文件和锁定特定版本的lock文件分开管理，对任何Go构建作出贡献的每个依赖项的版本完全由main module的go.mod文件决定。

从Go 1.16版本开始，Go命令默认按照这种确定性执行，如果go.mod不完整，构建命令（go build, go test, go install, go run, …）将失败。唯一可以改变go.mod文件（当然构建也会随之改变）的命令是go get和go mod tidy。这两个命令通常不会自动运行或在CI中运行，所以对依赖树的改变必须是主观故意的，我们可以在操作前对这种改变做代码评审。

这对安全非常重要，因为当CI系统或新机器运行时，签入(checked-in)的源码是最终的和完整的，代码将说明什么会被构建，第三方没有办法影响它。

此外，当用go get添加新依赖时，由于最小版本选择的存在，它的传递依赖(transitive dependencies)的指定版本，不是最新版本，也会被添加到go.mod文件中。同样的情况也发生在调用go install example.com/cmd/devtoolx@latest 的情况下，在某些生态系统中，同样的构建发生时会绕过“已锁定”的版本(译注：去获取依赖的最新版本)。但在Go中，example.com/cmd/devtoolx的最新版本将被获取，但其所有的依赖项的版本将取决于其go.mod文件中的设置。

如果一个module被破坏，新的恶意版本被发布，没有人会受到影响，直到他们明确地更新该依赖关系，这种方式为gopher提供了审查变化的机会，并为生态系统提供时间来检测该事件会引发的影响。

版本内容永不改变

确保第三方不能影响构建的另一个关键属性是，module版本的内容是不可改变的。如果一个破坏某依赖项的攻击者可以重新上传该依赖项的一个现有的版本，那么他就可以自动破坏所有依赖该依赖项的项目。

这就是go.sum文件的作用。它包含了对构建有贡献的每个依赖项的加密哈希值的列表。同样，一个不完整的go.sum会导致一个错误，并且只有go get和go mod tidy会修改它，所以对它的任何修改都会伴随着一个主观故意的依赖性的改变。其他的构建将被保证有一套完整的校验和。

这是大多数lock文件的一个共同特征。但Go通过校验和数据库（简称sumdb）领先了一步，sumdb是一个全局性的、仅可附加的(append)、加密验证的go.sum条目列表。当go get需要在go.sum文件中添加一个条目时，它从sumdb中获取该条目，并对sumdb的完整性进行加密证明。这不仅确保了某一module的每一次构建都使用相同的依赖，而且确保了每一个module都使用相同的依赖内容。

sumdb使那些试图用修改过的（例如放置后门的）源码来攻击特定依赖项变为不可能，甚至谷歌自己运维的Go基础设施也做不到。

它将保证你使用的代码与其他使用例如example.com/modulex v1.9.2的人所使用的代码完全相同，并且已经过审查。

最后，我最喜欢sumdb的特点：它不需要module作者的任何密钥管理，而且它与Go module的非中心化特性无缝连接。

VCS是真相之源

大多数项目是通过一些版本控制系统（VCS）开发的。在其他生态系统中，这些项目还需要被再次上传到中心软件包库(译注：比如js生态中的npm)。这意味着有两个账户可能被入侵，一个是VCS主机，另一个是中心软件包库。对后者的攻击使用得更少，也更容易被忽视。这也意味着在上传到中心仓库的版本中更容易隐藏恶意代码，尤其是当源码作为上传的一部分被例行修改时，比如说将其最小化(译注：比如js代码的压缩)。

在Go中，不存在中心包库账户这样的东西。包的导入路径包含了go mod download所需要的信息，以便go命令直接从VCS中获取其module，vcs上的标签定义了module的版本。

我们确实有Go Module Mirror，但那只是一个代理。module作者不需要注册账户，也不需要向代理上传版本。代理使用与go工具链相同的逻辑（事实上，代理运行go module download）来获取和缓存一个版本。由于校验数据库保证一个给定的module版本只能有一个源码树，每个使用代理的人都会看到从代理获取的结果与绕过代理直接从VCS获取的结果是相同的。(如果该版本在VCS中不再可用，或者其内容发生了变化，直接获取将导致错误，而从代理获取可能仍然有效，提高了可用性并保护生态系统免受“左键”问题的影响）。

在客户端运行VCS工具会暴露出一个相当大的攻击面。这也是Go module mirror的另一个作用：代理上的Go工具在一个强大的沙盒内运行，并被配置为支持所有的VCS工具，而默认的是只支持两个主要的VCS系统（git和Mercurial）。任何使用代理的人仍然可以获取使用非默认的VCS系统发布的代码，但攻击者在大多数安装中无法接触到这些代码。

仅构建代码，但并不会执行它

Go工具链的一个明确的安全设计目标是，无论是获取还是构建代码，都不会让代码执行，无论代码是否是不被信任的和恶意的。这与其他大多数生态系统不同，许多生态系统在获取软件包时对运行代码提供了first-class的支持。这些”post-install”的钩子在过去被用作一种最方便的攻击方式：通过受到攻击的依赖攻击开发者的机器，并通过module作者进行蠕虫攻击。

公平地说，如果你要获取一些代码，往往会在不久之后执行，要么作为开发者机器上的测试的一部分，要么作为生产中的二进制文件的一部分，所以缺乏post-install钩子只会减缓攻击者。(在构建过程中没有安全边界：任何有助于构建的软件包都可以定义一个init函数）。然而，它可以成为一个有意义的风险缓解措施，因为你可能正在执行一个二进制文件或测试一个包，而这个包只使用module依赖的一个子集。例如，如果你在macOS上构建并执行example.com/cmd/devtoolx，那么针对Windows的依赖或example.com/cmd/othertool的依赖就不可能危害到你的机器。

在Go中，没有为特定构建提供代码的module对构建没有安全影响(译注：得益于Go 1.17引入的module依赖图修剪)。

“一点复制比一点依赖性好”

在Go生态系统中，最后一个可能也是最重要的软件供应链风险缓解措施，可能也是最没有技术含量的一个：Go有一种拒绝大型依赖树的文化，宁可复制一点也不愿意增加新的依赖关系。这可以追溯到Go的一个谚语：“一点复制比一点依赖性好”。”零依赖”的标签总是被高质量的可重复使用的Go module所自豪地佩戴。如果你发现自己需要一个这样的库，你很可能会发现它不会导致你依赖其他作者和所有者的几十个module。

丰富的标准库和附加module（golang.org/x/…的module）也使之成为可能，这些module提供了常用的高级构建模块，如HTTP栈、TLS库、JSON编码等。

所有这些意味着只需少量的依赖关系就可以建立丰富、复杂的应用程序。无论工具有多好，它都不能消除重复使用代码的风险，所以最有力的缓解措施永远是一个小的依赖树。

img{512x368}