Google plans to tighten security around its open-source Go programming language by requiring two Google employees to be involved in code changes, whereas previously only one approver had to be affiliated with the company.
“For compliance and supply chain security reasons, Google recently revised the code review requirements we use in all contexts, both in-house development and open source,” Russ explained. 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 sent to users, which for most of our tools means that it is submitted in [code review system] Gerrit.”
Google did not respond to questions about whether a particular incident prompted the change.
In this context, supply chain security refers to attempts to hijack software modules or libraries, in order to compromise the applications that use them. Software supply chain attacks have become a serious problem over the past few years and remain an unresolved problem in major package registries such as npm, RubyGems, and PyPI.
Go, due to some design decisions, has some defenses against harm, but remains an attractive target for malware writers. Adding a second Google employee endorsement extends existing safeguards and perhaps provides some protection against threat scenarios involving a defecting employee.
Anyone involved in the development of Go can be granted “approving” powers to review and submit a list of code changes. Code reviews are voted on in a voting system using integers from -2 to +2:
- +2 The change is approved to be merged. Only Go officials can vote +2.
- +1 The change looks good, but either the reviewer is asking for minor changes before approving it, or they’re not responsible and can’t approve it, but want to encourage an approval.
- -1 The change is not good as is but may be fixable. A -1 vote will always have a comment explaining why the change is unacceptable.
- -2 The change is blocked by a manager and cannot be approved. Again, there will be a comment explaining the decision.
“At least two managers must approve the change, and at least one of those managers must +2 the change,” the current Go documentation explains. “The second maintainer can issue a +1 vote of confidence, which means that the change seems fundamentally correct, but the maintainer has not done the detailed review required for a +2 vote.”
Later this month, Cox said, Google will add a new Gerrit submission requirement that two Google employees were involved, either uploading the CL or adding a code review upvote (+1 or + 2) at each modification before submission.
This replaces the Trust+1 program introduced in August 2020. At this point, the existing two-person approval process has been extended to add a “Trust” tag in addition to two “Code-Review” tags on submissions CL. This was done to guard against CLs from hacked or puppet accounts and to prevent authors with “approving” 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 one 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:
“Each CL requires both a code review (Code-Review + 2) by an approver and the involvement of two Google employees, either as code uploaders or as reviewers voting at least Code-Review + 1.”
Among those considering the change, computer scientist Alberto Donizetti, a Go contributor, seems unhappy with the new security feature. “This change effectively limits the group of committers to Google employees,” he said in a response to the mailing list.
Asked if the Go policy change makes it unnecessary for non-Google officials to vote +2 for merger approval since two Googlers still need to be involved, Cox said he doesn’t quite see it. done this way.
“We expect CLs to continue to land with only non-Google Code-Review+2 reviews as they do today,” he replied, adding that he expects any delays. resulting from waiting for a Google Code-Review +1 approval after the Deep Code Review +2 is completed will be minimal. ®