Google engineer Russ Cox announced in a mailing list to golang-dev on Monday that the company has decided that every future change to the Go programming language needs to be reviewed by 2 Google employees (previously 1) before it can be released to users. But it did not disclose the specific motives of Google's decision.
Due to compliance and supply chain security concerns, Google recently revisited the code review requirements we use in all environments, including internal development and open source. We now need to have two Googlers review each change before sending it to users, which for most of our tools means committing in Gerrit (tools like "go get" and "gotip download" and go.dev auto-deployment reads directly from Gerrit).
Cox noted that they will be adding a new Gerrit submission requirement later this month. i.e. 2 Googlers must upload or contribute an active Code-Review vote (+1 or +2) before each revision is submitted; to replace the current Trust+1 program: which was implemented in August 2020. In addition to the two "Code-Review" labels on CL submissions, a "Trust" label has been added. This is done to prevent CL from being hijacked or puppet accounts, and to prevent authors with "approver" status from approving and committing their own changes to the Go codebase.
Anyone involved in Go development may be granted "approver" authority to review and submit code changelists. According to the current Go documentation , when a change is close to a decision, reviewers vote on it. The Gerrit voting system involves integers in the range -2 to +2:
- +2 Changes were approved to be merged. Only Go maintainers can vote +2.
- +1 Change looks good, but reviewers are asking for minor changes before approving; or they're not maintainers and can't approve it, but want to encourage approval.
- -1 This change is in a bad state right now, but it might be fixable. A -1 vote will always have a comment explaining why the change is not acceptable.
- -2 Changes are blocked by maintainers and cannot be approved. Again, there will be a comment explaining the decision.
" At least two maintainers must agree to the change, and at least one of them must +2 the change. The second maintainer may have voted Trust+1, which means the change looks mostly OK; but the maintenance The authors have not completed the scrutiny required for +2 voting. ”
Cox said he plans to add some clarification to the GerritAccess page. That is, "Each CL requires a code review (Code-Review+2) from an approver and participation from two Googlers; either as a code uploader or as a reviewer vote, at least Code-Review+ 1. Require multiple people to ensure that code cannot be unilaterally submitted from a single compromised account. Once a review gets Code-Review+2 and the necessary Google participation, it can be submitted by any approver. All these rules are enforced by the Gerrit servers. ”
In response to the change, Go contributor and computer scientist Alberto Donizetti said on the mailing list that the change effectively limited the Committer community to only Google employees.
When questioned whether this change in Go policy would make senseless a +2 merge approval vote from non-Google maintainers, Cox denied it, saying, "We fully expect CL will continue to accept only non-Googlers as it does today. Staff Code-Review+2 Review". It added that it is expected that after completing the in-depth Code-Review+2, any delays due to waiting for Code-Review+1 approval will be minimal.
Previously, the Go official blog introduced their mitigations against supply chain attacks . TheRegister pointed out that the addition of a second Google employee to scrutiny expands existing safeguards, and Google's move may provide an additional layer of protection against threats such as employee mutiny.
See the mailing list for more details .