[ANNOUNCE] Git v2.37.1 and others

Git v2.37.1, together with v2.30.5, v2.31.4, v2.32.3, v2.33.4, v2.34.4, v2.35.4, and v2.36.2 for older maintenance tracks, are now available at the usual places.

These are to address CVE-2022-29187, where the fixes in v2.36.1 and below to address CVE-2022-24765 released earlier may not have been complete.

The tarballs are found at:

    https://www.kernel.org/pub/software/scm/git/

The following public repositories all have a copy of the 'v2.37.1' tag and other tags for older maintenance tracks.

  url = https://git.kernel.org/pub/scm/git/git
  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = https://github.com/gitster/git

----------------------------------------------------------------

Git 2.37.1 Release Notes ========================

This release merges up the fixes that appear in v2.30.5, v2.31.4, v2.32.3, v2.33.4, v2.34.4, v2.35.4, and v2.36.2 to address the security issue CVE-2022-29187; see the release notes for these versions for details.

Fixes since Git 2.37 --------------------

 * Rewrite of "git add -i" in C that appeared in Git 2.25 didn't
   correctly record a removed file to the index, which is an old
   regression but has become widely known because the C version has
   become the default in the latest release.

 * Fix for CVE-2022-29187.

----------------------------------------------------------------

Git v2.30.5 Release Notes =========================

This release contains minor fix-ups for the changes that went into Git 2.30.3 and 2.30.4, addressing CVE-2022-29187.

 * The safety check that verifies a safe ownership of the Git
   worktree is now extended to also cover the ownership of the Git
   directory (and the `.git` file, if there is any).

Carlo Marcelo Arenas Belón (1):
      setup: tighten ownership checks post CVE-2022-24765

On July 12, 2022 1:07 PM, Junio C Hamano wrote:

Following are net new test failures with 2.37.1 compared with 2.37.0 are as follows on NonStop ia64 and x86 platforms:

t5516-fetch-push subtests 53, 113

t5545-push-options subtest 9

t5601-clone subtest 8

t7502-commit-porcelain subtests 20-26, 29-33, 42-47

t7528-signed-commit-ssh subtests 4, 5

I am investigating, but as it stands, we cannot package this release for our platform at this time.

Sincerely, Randall

On July 13, 2022 8:11 AM, I wrote:

Test passes when not run in Jenkins CI/CD

Test passes when not run in Jenkins CI/CD

Test passes when not run in Jenkins CI/CD

Test passes when not run in Jenkins CI/CD 

So it looks like a Jenkins/git test interaction is the issue here. I'm wondering whether running the test with </dev/null and 2>/dev/null might make a difference when running in Jenkins. The tty where Jenkins was started is in a permanently disconnected state.

Mostly ignore the subtest failures, but still, would like to know why these subtests in particular.

--Randall

On July 13, 2022 10:24 AM, I wrote:

Strangely, setting stdin to /dev/null and stderr to /dev/null makes no difference in the test results. stdout is the Jenkins pipe, which is Java of course, but roughly a popen(x, "r"). I have no explanation at this point why specific tests fail - other than OpenSSH, which I know attempts to prompt if it thinks the tty is even remotely reasonable.