Google now requires two staff to sign off each Go change

Move is supposed to be double-plus good for supply-chain security

Google is planning to tighten the security around its open source Go programming language by requiring two Google employees to be involved in code changes, where previously only one approver needed to be company-affiliated.

"For compliance and supply chain security reasons, Google recently revisited the code review requirements we use in all settings, both internal development and open source," explained Russ Cox, distinguished engineer at Google, in a note to the golang mailing list on Monday.

"We are now required to have two Google employees review each change before it is shipped to users, which for most of our tools means submitted in [code review system] Gerrit."

Google did not respond to a query about whether any particular incident had motivated this change.

Supply chain security in this context refers to attempts to subvert software modules or libraries, in order to compromise applications utilizing them. Software supply chain attacks have become a serious problem over the past few years and remain an unsolved problem at major package registries like npm, RubyGems, and PyPI.

Go, because of certain design decisions, has some defenses against mischief but remains an attractive target for malware authors. The addition of a second Google employee approval expands existing safeguards and perhaps offers some protection against threat scenarios involving a turncoat employee.

Anyone involved with Go development may be granted "approver" powers to review and submit a list of code changes. Code reviews get voted on in a voting system using integers from -2 to +2:

• +2 The change is approved for being merged. Only Go maintainers can cast a +2 vote.
• +1 The change looks good, but either the reviewer is requesting minor changes before approving it, or they are not a maintainer and cannot approve it, but would like to encourage an approval.
• -1 The change is not good the way it is but might be fixable. A -1 vote will always have a comment explaining why the change is unacceptable.
• -2 The change is blocked by a maintainer and cannot be approved. Again, there will be a comment explaining the decision.

"At least two maintainers must approve of the change, and at least one of those maintainers must +2 the change," the current Go documentation explains. "The second maintainer may cast a vote of Trust+1, meaning that the change looks basically OK, but that the maintainer hasn't done the detailed review required for a +2 vote."

Later this month, said Cox, Google will add a new Gerrit submission requirement that two Google employees have been involved, either by uploading the CL or by adding a positive Code-Review vote (+1 or +2) to each change before submission.

This replaces the Trust+1 scheme put into place in August, 2020. At that point, the existing two-person approval process was expanded to add a "Trust" label in addition to two "Code-Review" labels on CL submissions. That was done to guard against CLs from hijacked or sock-puppet accounts and to prevent authors with "approver" status from approving and submitting their own changes to the Go codebase.

At the moment, the Go project requires "both a code review (Code-Review+2) from an approver and the involvement of a second trusted approver (an additional Code-Review+2, or a Trust+1)."

Cox said he plans to revise the Go documentation language to read:

"Every CL requires both a code review (Code-Review+2) from an approver and the involvement of two Google employees, either as code uploader or as a reviewer voting at least Code-Review+1."

Among those pondering the change, computer scientist Alberto Donizetti, a Go contributor, sounded unhappy with the new security arrangement. "This change effectively restricts the committer group to Google employees," he said in a mailing list reply.

Questioned about whether the Go policy change makes it pointless for non-Google maintainers to cast +2 merge approval votes since two Googlers still need to be involved, Cox said he doesn't quite see it that way.

"We fully expect that CLs will continue to land with only non-Googler Code-Review+2 reviews as they do today," he replied, adding that he expects any delay arising from the wait for a Google Code-Review+1 endorsement after the completion of the in-depth Code-Review+2 will be minimal. ®