Google engineer Russ Cox announced in a mailing list to golang-dev on Monday that the company has decided that every change to the Go programming language will need to be reviewed by two Google employees before it can be released to users (up from one). The company has decided that every change to the Go programming language will have to be reviewed by two Google employees (up from one) before it can be released to users. But it did not disclose the specific motivation for the decision.
For compliance and supply chain security reasons, Google recently revisited the code review requirements we use in all environments, including internal development and open source. We now need to have two Google employees review every change before it is sent to users, which for most of our tools means committing in Gerrit (“go get” and “gotip download” and go.dev are automatically deployed to read directly from Gerrit).
Cox noted that they will be adding a new Gerrit submission requirement later this month. That is, 2 Google employees must upload or contribute an active Code-Review vote (+1 or +2) before each revision can be submitted; replacing 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 to prevent CL hijacking or sock puppet accounts, and to prevent authors with “approver” status from approving and submitting their own changes to the Go codebase.
Anyone involved in Go development may be granted “approver” rights to review and commit a list of code changes. According to the current Go documentation, when a change is close to a decision, the reviewers vote on it. The Gerrit voting system involves integers in the range -2 to +2:
- +2 Changes are approved for merging. Only Go maintainers can cast +2 votes.
- +1 The change looks good, but reviewers are asking for smaller changes before approving it; or they are not maintainers and can’t approve it, but want to encourage approval.
- -1 This change is not in a good state right now, but is probably fixable. -1 votes will always have notes explaining why the change is unacceptable.
- -2 The change is blocked by the maintainer 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 that the change appears to be largely OK; but the maintainer has not completed the detailed review required for a +2 vote.”
Cox said he plans to add some clarification to the GerritAccess page. Namely, “Each CL requires code review from an approver (Code-Review+2) and the participation of two Google employees; either as a code uploader or as a reviewer vote with at least Code-Review+1. Multiple people are required to ensure that no code can be submitted from a single stolen account Unilaterally submit code. Once a review has received a Code-Review+2 and the necessary Google participation, it can be submitted by any approver. All of these rules are enforced by the Gerrit server.”
In response to the change, Go contributor and computer scientist Alberto Donizetti said in a mailing list that the change effectively limits the Committer community to Google employees.
When questioned whether this change in Go policy makes it pointless for non-Google maintainers to vote for +2 merger approval, Cox denied and said, “We fully expect that CL will continue to accept only non-Google employee Code-Review+2 reviews as it does today.” Adding that any delay in waiting for Code-Review+1 approval after completion of an in-depth Code-Review+2 is expected to be minimal.
Previously, the official Go blog had described their mitigation measures in response to the supply chain attack. TheRegister notes that this addition of a second Google employee to the review extends existing safeguards, a move by Google that may provide an additional layer of protection against threats involving Google’s move may provide an additional layer of protection against threatening situations involving employee defection.
More details can be found on the view mailing list.