Go限制Committer群体?

polarisxu

共 1869字,需浏览 4分钟

 ·

2022-04-24 03:07

文 | 白开水

出品 | OSC开源社区(ID:oschina2013)

谷歌工程师 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 指出,此次增加第二名谷歌员工的审查则扩大了现有的保障措施,谷歌此举也许可以多提供一层保护措施,防止涉及员工叛变之类的威胁情况发生。
更多详情可查看邮件列表:https://groups.google.com/g/golang-dev/c/K7oGURi0wTM



往期推荐


我是 polarisxu,北大硕士毕业,曾在 360 等知名互联网公司工作,10多年技术研发与架构经验!2012 年接触 Go 语言并创建了 Go 语言中文网!著有《Go语言编程之旅》、开源图书《Go语言标准库》等。


坚持输出技术(包括 Go、Rust 等技术)、职场心得和创业感悟!欢迎关注「polarisxu」一起成长!也欢迎加我微信好友交流:gopherstudio


浏览 16
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报