谷歌工程師 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 指出，此次增加第二名谷歌員工的審查則擴大了現有的保障措施，谷歌此舉也許可以多提供一層保護措施，防止涉及員工叛變之類的威脅情況發生。

本文轉自OSCHINA

本文標題：Go 限制 Committer 群體?每項更改都需 2 名谷歌員工審查

本文地址：https://www.oschina.net/news/190022/google-go-double-sign-off