[ANNOUNCE] Git v2.37.1 and others

[ANNOUNCE] Git v2.37.1 and others

[Junio C Hamano]

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

[Test Failures] Git v2.37.1 (was RE: [ANNOUNCE] Git v2.37.1 and others)

[rsbecker]

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

RE: [Test Failures] Git v2.37.1 (was RE: [ANNOUNCE] Git v2.37.1 and others)

[rsbecker]

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 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

RE: [Test Failures] Git v2.37.1 (was RE: [ANNOUNCE] Git v2.37.1 and others)

[rsbecker]

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 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.

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.