# [ANNOUNCE] Git v2.37.1 and others 4 messages from 2022-07-12 to 2022-07-14. Participants: Junio C Hamano, rsbecker@nexbridge.com. Thread: https://gitlist.dev/t/58144 ## Junio C Hamano, 2022-07-12 17:06 Subject: [ANNOUNCE] Git v2.37.1 and others Message-ID: URL: https://gitlist.dev/e/xmqqv8s2fefi.fsf%40gitster.g ``` 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 ``` ## rsbecker@nexbridge.com, 2022-07-13 12:11 Subject: [Test Failures] Git v2.37.1 (was RE: [ANNOUNCE] Git v2.37.1 and others) Message-ID: <01af01d896b1$a48e32f0$edaa98d0$@nexbridge.com> URL: https://gitlist.dev/e/01af01d896b1%24a48e32f0%24edaa98d0%24%40nexbridge.com In-Reply-To: ``` On July 12, 2022 1:07 PM, Junio C Hamano wrote: >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. 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 ``` ## rsbecker@nexbridge.com, 2022-07-13 14:23 Subject: RE: [Test Failures] Git v2.37.1 (was RE: [ANNOUNCE] Git v2.37.1 and others) Message-ID: <01b101d896c4$31761bd0$94625370$@nexbridge.com> URL: https://gitlist.dev/e/01b101d896c4%2431761bd0%2494625370%24%40nexbridge.com In-Reply-To: <01af01d896b1$a48e32f0$edaa98d0$@nexbridge.com> ``` On July 13, 2022 8:11 AM, I wrote: >On July 12, 2022 1:07 PM, Junio C Hamano wrote: >>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. > >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 Test passes when not run in Jenkins CI/CD >t5601-clone subtest 8 Test passes when not run in Jenkins CI/CD >t7502-commit-porcelain subtests 20-26, 29-33, 42-47 Test passes when not run in Jenkins CI/CD >t7528-signed-commit-ssh subtests 4, 5 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 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 ``` ## rsbecker@nexbridge.com, 2022-07-14 02:10 Subject: RE: [Test Failures] Git v2.37.1 (was RE: [ANNOUNCE] Git v2.37.1 and others) Message-ID: <021701d89726$ed4d09b0$c7e71d10$@nexbridge.com> URL: https://gitlist.dev/e/021701d89726%24ed4d09b0%24c7e71d10%24%40nexbridge.com In-Reply-To: <01b101d896c4$31761bd0$94625370$@nexbridge.com> ``` On July 13, 2022 10:24 AM, I wrote: >On July 13, 2022 8:11 AM, I wrote: >>On July 12, 2022 1:07 PM, Junio C Hamano wrote: >>>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. >> >>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 > >Test passes when not run in Jenkins CI/CD > >>t5601-clone subtest 8 > >Test passes when not run in Jenkins CI/CD > >>t7502-commit-porcelain subtests 20-26, 29-33, 42-47 > >Test passes when not run in Jenkins CI/CD > >>t7528-signed-commit-ssh subtests 4, 5 > >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 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. 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. ```