Google now requires two staff to sign off each Go change
(2022/04/05)
- Reference: 1649143393
- News link: https://www.theregister.co.uk/2022/04/05/google_go_double_sign_off/
- Source link:
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 [1]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] [2]Gerrit ."
[3]
Google did not respond to a query about whether any particular incident had motivated this change.
[4]
[5]
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 [6]certain design decisions , has some defenses against mischief but [7]remains an attractive target for [8]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.
[9]
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 [10]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 [11]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.
[12]Mandiant shareholder sues to block $5.4b Google deal
[13]Any fool can write a language: It takes compilers to save the world
[14]Deutsche Bank seeks options as sanctions threaten Russian dev unit
[15]Google unrolls search features to tackle misinformation
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."
[16]
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 [17]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. ®
Get our [18]Tech Resources
[1] https://groups.google.com/g/golang-dev/c/K7oGURi0wTM
[2] https://www.gerritcodereview.com/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YkwTUhE0XmBnG@JpBN0ziQAAAI4&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YkwTUhE0XmBnG@JpBN0ziQAAAI4&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YkwTUhE0XmBnG@JpBN0ziQAAAI4&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://go.dev/blog/supply-chain
[7] https://unit42.paloaltonetworks.com/the-gopher-in-the-room-analysis-of-golang-malware-in-the-wild/
[8] https://michenriksen.com/blog/finding-evil-go-packages/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YkwTUhE0XmBnG@JpBN0ziQAAAI4&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://go.dev/doc/contribute
[11] https://github.com/golang/go/issues/40699
[12] https://www.theregister.com/2022/04/04/mandiant_google_lawsuit/
[13] https://www.theregister.com/2022/04/04/compiling_the_future/
[14] https://www.theregister.com/2022/03/04/deutsche_bank_russia_dev_unit/
[15] https://www.theregister.com/2022/03/31/google_misinfo_features/
[16] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YkwTUhE0XmBnG@JpBN0ziQAAAI4&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[17] https://groups.google.com/g/golang-dev/c/K7oGURi0wTM/m/QCc1MgHtAQAJ
[18] https://whitepapers.theregister.com/
"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 [1]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] [2]Gerrit ."
[3]
Google did not respond to a query about whether any particular incident had motivated this change.
[4]
[5]
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 [6]certain design decisions , has some defenses against mischief but [7]remains an attractive target for [8]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.
[9]
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 [10]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 [11]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.
[12]Mandiant shareholder sues to block $5.4b Google deal
[13]Any fool can write a language: It takes compilers to save the world
[14]Deutsche Bank seeks options as sanctions threaten Russian dev unit
[15]Google unrolls search features to tackle misinformation
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."
[16]
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 [17]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. ®
Get our [18]Tech Resources
[1] https://groups.google.com/g/golang-dev/c/K7oGURi0wTM
[2] https://www.gerritcodereview.com/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YkwTUhE0XmBnG@JpBN0ziQAAAI4&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YkwTUhE0XmBnG@JpBN0ziQAAAI4&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YkwTUhE0XmBnG@JpBN0ziQAAAI4&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://go.dev/blog/supply-chain
[7] https://unit42.paloaltonetworks.com/the-gopher-in-the-room-analysis-of-golang-malware-in-the-wild/
[8] https://michenriksen.com/blog/finding-evil-go-packages/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YkwTUhE0XmBnG@JpBN0ziQAAAI4&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://go.dev/doc/contribute
[11] https://github.com/golang/go/issues/40699
[12] https://www.theregister.com/2022/04/04/mandiant_google_lawsuit/
[13] https://www.theregister.com/2022/04/04/compiling_the_future/
[14] https://www.theregister.com/2022/03/04/deutsche_bank_russia_dev_unit/
[15] https://www.theregister.com/2022/03/31/google_misinfo_features/
[16] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YkwTUhE0XmBnG@JpBN0ziQAAAI4&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[17] https://groups.google.com/g/golang-dev/c/K7oGURi0wTM/m/QCc1MgHtAQAJ
[18] https://whitepapers.theregister.com/
Going to A Go Go ...
Forget It
else Stop Go
Bean counters
Aitor 1
In my opinion, this is a sign bean counters and powerpoint creators have taken over and org.
Why? It does sound all good and reasonable. Hey, in my company we have a three people sign off... But is it reasonable?
I suspect that approvers won't have enough time or expertise 5o fully understand the consequences of the changes or the quality of them. I think so because I myself frankly don't have time except for the most egregious issues, and subtle breakage of chain of supply would mean subtle changes.
3+ for internal ?
Hopefully internally the requirement would be 3+ google employees randomly selected from diverse teams around the globe.
I'm not going to say which company I've seen it happen, or in what country. But some company in the past 40 years employed a developer that was outputting high quality code at insane rates (it was almost like a large team of developers were generating that individuals code). Needless to say that the manager of that individual was promoted and the developer was moved into position where they could manage their own hand-picked team, all of which amazingly were outputting high quality code at insane rates (it was almost like a small team of developers were generating each individuals code). Soon this team of god like coders had their fingers in every pie at said company .... anyhow long story short, after a number of years it eventually came to light that the company had hired an entire department of spies.