_posts/2022-01-12-esc-minutes.md - homepage - Git at Google

 ---
 title: "Gerrit ESC Meeting Minutes"
 tags: esc
 keywords: esc minutes
 permalink: 2022-01-12-esc-minutes.html
 summary: "Minutes from the ESC meeting held on Jan 12, 2022"
 hide_sidebar: true
 hide_navtoggle: true
 toc: true
 ---

 ## Engineering Steering Committee Meeting, Jan 12, 2022

 Christophe Poucet, Han-Wen Nienhuys, Luca Milanesio, Matthias Sohn,
 Patrick Hiesel, Saša Živkov.

 ### Next meeting

 Feb 2, 2022

 ## Minutes

 ## Proposal to drop Log4J completely and use java.util.logging

 Google does not use Log4J, and Gerrit does not require it directly because it is
 based on Flogger. Can we drop Log4J altogether in Gerrit?

 After an initial analysis, it looks like some of the components that Gerrit uses
 (e.g., Apache Mina SSHD) still refer to Log4J directly; therefore, removing it
 won't be trivial.

 Matthias pointed out that the reload4j project (https://reload4j.qos.ch/) has
 fixed the vulnerabilities found on Log4J 1.x and made the fork available to the
 community with the same Open-Source license.

 The removal of Log4J is put on hold, waiting to see if the reload4j project may
 work in the meantime.

 ## Definition of a policy for updating JGit on stable Gerrit branches

 Gerrit and JGit have different release schedules: twice a year for Gerrit, four
 times a year for JGit. Also, there is reluctance in updating JGit pointer in
 Gerrit stable not-EOL branches because of the fear of potential regressions.
 The two factors have contributed to the accumulation of lag in the alignment of
 the latest JGit version in Gerrit. For example, both Gerrit v3.4 and v3.5 use
 JGit v5.12, six months behind the latest.

 The consensus is to define a policy for updating JGit pointer on a regular basis
 as follows: Gerrit/master updates its submodule to JGit/master regularly. After
 two weeks of tests by Google (using the JGit fork) and GerritForge (using the
 JGit vanilla), the update is performed on the non-EOL stable branches, assuming
 that there are no breaking JGit API changes. Stable branches that are in EOL
 will not have any regular JGit updates

 ## Delay in Gerrit releases due to the review of release notes

 The Gerrit release notes are created and reviewed too late in the process,
 causing potential delays and potential mistakes and gaps in the initial Gerrit
 versions. Ideally, updating the release notes should be part of the review
 process of the changes that are modifying or creating new functionalities,
 rather than a one-off task for the release manager.

 We had the idea of implementing the mechanism of validating the presence of
 release notes in the submit rules; however, that did not take off. Patrick
 takes the task of assessing a similar check by using the new submit
 requirements available in Gerrit master.

 ## Proposal to drop Java-8 support for stable-3.3/3.4

 Gerrit v3.3.* and v3.4.* are distributed only for Java 11; however, during their
 development SAP and Google needed to preserve the source-code compatibility to
 Java 8 for being able to upgrade and deploy to their respective Java 8-based
 setup. Nowadays, SAP and Google are on Java 11; therefore, there is no need
 anymore to keep source-code level compatibility with Java 8.

 The consensus is to drop Java 8 source compatibility for stable-3.3/3.4 to
 switch the whole Gerrit CI/CD pipeline to Java 11, avoiding complicated
 if/then/else in the build scripts.

 Luca has created [a small survey](https://www.surveymonkey.co.uk/r/8CQ5BH7)
 for asking the community which Java version is used with Gerrit v3.3/v3.4.
 Once the results are available, the project can make a final decision on the
 matter.

 ## Proposal to define a trusted group of contributors for running CI builds

 Currently, any incoming Gerrit change triggers a CI build, posing security risks
 because the execution happens *before* any review or validation by
 contributors. Both the Jenkins-based pipeline
 (https://gerrit-ci.gerritforge.com) and the Zuul pipeline
 (https://ci.gerritcodereview.com) are impacted but with different security
 issues.

 The use of RBE for the build execution would not mitigate the security issue,
 because some of the build steps have to be executed on the agents anyway
 (e.g., PolyGerrit tests).

 The possible options are introducing further isolation layers
 (e.g., https://gvisor.dev/docs/) or using a service such as Google Cloud Build.
 Han-Wen will explore this second option.
	---
	title: "Gerrit ESC Meeting Minutes"
	tags: esc
	keywords: esc minutes
	permalink: 2022-01-12-esc-minutes.html
	summary: "Minutes from the ESC meeting held on Jan 12, 2022"
	hide_sidebar: true
	hide_navtoggle: true
	toc: true
	---

	## Engineering Steering Committee Meeting, Jan 12, 2022

	Christophe Poucet, Han-Wen Nienhuys, Luca Milanesio, Matthias Sohn,
	Patrick Hiesel, Saša Živkov.

	### Next meeting

	Feb 2, 2022

	## Minutes

	## Proposal to drop Log4J completely and use java.util.logging

	Google does not use Log4J, and Gerrit does not require it directly because it is
	based on Flogger. Can we drop Log4J altogether in Gerrit?

	After an initial analysis, it looks like some of the components that Gerrit uses
	(e.g., Apache Mina SSHD) still refer to Log4J directly; therefore, removing it
	won't be trivial.

	Matthias pointed out that the reload4j project (https://reload4j.qos.ch/) has
	fixed the vulnerabilities found on Log4J 1.x and made the fork available to the
	community with the same Open-Source license.

	The removal of Log4J is put on hold, waiting to see if the reload4j project may
	work in the meantime.

	## Definition of a policy for updating JGit on stable Gerrit branches

	Gerrit and JGit have different release schedules: twice a year for Gerrit, four
	times a year for JGit. Also, there is reluctance in updating JGit pointer in
	Gerrit stable not-EOL branches because of the fear of potential regressions.
	The two factors have contributed to the accumulation of lag in the alignment of
	the latest JGit version in Gerrit. For example, both Gerrit v3.4 and v3.5 use
	JGit v5.12, six months behind the latest.

	The consensus is to define a policy for updating JGit pointer on a regular basis
	as follows: Gerrit/master updates its submodule to JGit/master regularly. After
	two weeks of tests by Google (using the JGit fork) and GerritForge (using the
	JGit vanilla), the update is performed on the non-EOL stable branches, assuming
	that there are no breaking JGit API changes. Stable branches that are in EOL
	will not have any regular JGit updates

	## Delay in Gerrit releases due to the review of release notes

	The Gerrit release notes are created and reviewed too late in the process,
	causing potential delays and potential mistakes and gaps in the initial Gerrit
	versions. Ideally, updating the release notes should be part of the review
	process of the changes that are modifying or creating new functionalities,
	rather than a one-off task for the release manager.

	We had the idea of implementing the mechanism of validating the presence of
	release notes in the submit rules; however, that did not take off. Patrick
	takes the task of assessing a similar check by using the new submit
	requirements available in Gerrit master.

	## Proposal to drop Java-8 support for stable-3.3/3.4

	Gerrit v3.3.* and v3.4.* are distributed only for Java 11; however, during their
	development SAP and Google needed to preserve the source-code compatibility to
	Java 8 for being able to upgrade and deploy to their respective Java 8-based
	setup. Nowadays, SAP and Google are on Java 11; therefore, there is no need
	anymore to keep source-code level compatibility with Java 8.

	The consensus is to drop Java 8 source compatibility for stable-3.3/3.4 to
	switch the whole Gerrit CI/CD pipeline to Java 11, avoiding complicated
	if/then/else in the build scripts.

	Luca has created [a small survey](https://www.surveymonkey.co.uk/r/8CQ5BH7)
	for asking the community which Java version is used with Gerrit v3.3/v3.4.
	Once the results are available, the project can make a final decision on the
	matter.

	## Proposal to define a trusted group of contributors for running CI builds

	Currently, any incoming Gerrit change triggers a CI build, posing security risks
	because the execution happens before any review or validation by
	contributors. Both the Jenkins-based pipeline
	(https://gerrit-ci.gerritforge.com) and the Zuul pipeline
	(https://ci.gerritcodereview.com) are impacted but with different security
	issues.

	The use of RBE for the build execution would not mitigate the security issue,
	because some of the build steps have to be executed on the agents anyway
	(e.g., PolyGerrit tests).

	The possible options are introducing further isolation layers
	(e.g., https://gvisor.dev/docs/) or using a service such as Google Cloud Build.
	Han-Wen will explore this second option.