Go 限制 Committer 群体？每项更改都需经由 2 名谷歌员工审查

谷歌工程师 Russ Cox 在周一给 golang-dev 的邮件列表中宣布，该公司决定以后有关 Go 编程语言的每项改动都需经由 2 名谷歌员工审查以后（以前为 1 名），才可以面向用户发布。但其并未透露谷歌作出该决策的具体动机。

出于合规性和供应链安全的考虑，谷歌最近重新审视了我们在所有环境中使用的代码审查要求，包括内部开发和开源。我们现在需要让两名 Google 员工在将每个更改发送给用户之前对其进行审核，这对于我们的大多数工具来说意味着在 Gerrit 中提交（“go get”和“gotip download”等工具以及 go.dev 自动部署直接从 Gerrit 中读取）。

Cox 指出，他们将于本月晚些时候增加一个新的 Gerrit 提交要求。即在每项修改提交之前，必须有 2 名谷歌员工上传或贡献一个积极的 Code-Review 投票（+1 或 +2）；以取代目前的 Trust+1 计划：该计划于 2020 年 8 月实施。除了在 CL submissions 上的两个"Code-Review" label 外，还增加了一个"Trust" label。这样做是为了防止 CL 被劫持或傀儡账户，并防止具有"approver"身份的作者批准和提交他们自己对 Go 代码库的修改。

任何参与 Go 开发的人都可能被授予“approver”权力来审查和提交代码更改列表。根据当前的 Go 文档内容，当一项更改接近决策时，审查员会对其进行投票。Gerrit 投票系统涉及 -2 到 +2 范围内的整数：

• +2 更改被批准合并。只有 Go 维护者可以投 +2 票。
• +1 更改看起来不错，但审查者在批准之前要求进行较小的更改；或者他们不是维护者并且无法批准它，但希望鼓励批准。
• -1 这个改动现在的状态并不好，但可能是可以修复的。-1 投票将始终有注释解释为什么更改是不可接受的。
• -2 更改被维护者阻止，无法获得批准。同样，将有一条评论解释该决定。

“至少要有两个维护者同意该更改，且其中至少一名维护者必须 +2 该更改。第二个维护者可能投了 Trust+1 的投票，这意味着更改看起来基本没问题；但维护者还没有完成 +2 投票所需的详细审查。”

Cox 表示，他计划在 GerritAccess 页面上添加一些说明。即，“每个 CL 都需要来自一名 approver 的 code review (Code-Review+2) 和两名 Google 员工的参与；要么是作为代码上传者，要么是作为审查者投票，至少是 Code-Review+1。要求多人确保不能从单个被盗帐户单方面提交代码。一旦审查获得 Code-Review+2 和必要的 Google 参与，它就可以由任何 approver 提交。所有这些规则都由 Gerrit 服务器强制执行。”

针对这一变更，Go 贡献者、计算机科学家 Alberto Donizetti 则在邮件列表中表示，这一变化有效地限制了 Committer 群体，使其只限于谷歌员工。

当被质疑此次 Go 政策的改变是否使会得非 Google 维护者投出 +2 合并批准票毫无意义时，Cox 进行了否认并表示，“我们完全期望 CL 将继续像今天一样只接受非 Google 员工 Code-Review+2 审查”。并补充称，预计在完成深入的 Code-Review+2 之后，因等待 Code-Review+1 的认可而产生的任何延迟将是最小的。

此前，Go 官方博客曾介绍了他们应对供应链攻击的缓解措施。TheRegister 指出，此次增加第二名谷歌员工的审查则扩大了现有的保障措施，谷歌此举也许可以多提供一层保护措施，防止涉及员工叛变之类的威胁情况发生。

更多详情可查看邮件列表。