[ANNOUNCE] Git v2.48.1 and friends

[Junio C Hamano]

A maintenance release Git v2.48.1, together with releases for older
maintenance tracks (v2.40.4, v2.41.3, v2.42.4, v2.43.6, v2.44.3,
v2.45.3, v2.46.3, and v2.47.2) are now available at the usual
places. These are to address a couple of security issues.

The tarballs are found at:

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

The following public repositories all have a copy of the 'v2.48.1'
tag, as well as the tags for older maintenance tracks listed above.

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


These releases make Git refuse to accept URLs that contain control
sequences to address CVE-2024-50349 and CVE-2024-52006.

- CVE-2024-50349:

Printing unsanitized URLs when asking for credentials made the
user susceptible to crafted URLs (e.g. in recursive clones) that
mislead the user into typing in passwords for trusted sites that
would then be sent to untrusted sites instead.

- CVE-2024-52006

Git may pass on Carriage Returns via the credential protocol to
credential helpers which use line-reading functions that
interpret said Carriage Returns as line endings, even though Git
did not intend that.


Huge credit goes to Dscho who led and coordinated the fixes for this
set of releases.

[Johannes Schindelin]

Hi Junio,

my apologies, I only realized _now_ that I had forgotten to update
`GIT-VERSION-GEN` in v2.47.2, it still has `DEF_VER=v2.47.1` (but all
other mentioned tagged versions have a correct `GIT-VERSION-GEN`). I am
very sorry about that.

Ciao,
Johannes

[rsbe...@nexbridge.com]

On January 14, 2025 1:44 PM, Johannes Schindelin wrote:
>To: Junio C Hamano <git...@pobox.com>
>Cc: g...@vger.kernel.org; Linux Kernel <linux-...@vger.kernel.org>; git-
>pack...@googlegroups.com
>Subject: Re: [ANNOUNCE] Git v2.48.1 and friends

>
>Hi Junio,
>
>my apologies, I only realized _now_ that I had forgotten to update
`GIT-VERSION-
>GEN` in v2.47.2, it still has `DEF_VER=v2.47.1` (but all other mentioned
tagged
>versions have a correct `GIT-VERSION-GEN`). I am very sorry about that.

Oh gosh. Glad I did not hit the "build" button. I will hold off packaging
that
version until this is resolved. It is definitely needed by the NonStop
community.

--Randall

[Johannes Schindelin]

Hi Randall,

On Tue, 14 Jan 2025, rsbe...@nexbridge.com wrote:

> On January 14, 2025 1:44 PM, Johannes Schindelin wrote:
>
> > my apologies, I only realized _now_ that I had forgotten to update

> > `GIT-VERSION-GEN` in v2.47.2, it still has `DEF_VER=v2.47.1` (but all

> > other mentioned tagged versions have a correct `GIT-VERSION-GEN`). I
> > am very sorry about that.

[I fixed the formatting, not sure how it got screwed up, it had verbatim
mbox headers and inconsistent `>` prefixes in the quoted lines.]

> Oh gosh. Glad I did not hit the "build" button.

Well, depending what that "build" button does when you hit it, it might
not even affect you, have you tried it or at least looked at what
`GIT-VERSION-GEN` does? `DEF_VER` only sets the default version when
building e.g. from a tarball.

When building from a Git checkout, though, it uses the tag and everything
is fine, the output of `git version` will say that this is 2.47.2:
https://github.com/git/git/blob/v2.47.2/GIT-VERSION-GEN#L15

Also, you can always hard-code the version by writing it to a file
called... wait for it... `version`, before calling `make`.

> I will hold off packaging that version until this is resolved. It is
> definitely needed by the NonStop community.

I'm not sure what you're implying by "until this is resolved". I hope that
you don't intend to suggest to re-tag and force-push v2.47.2 because
that's kind of a serious no-go, those tags have been relayed to quite a
few people well in advance of today during the carefully-orchestrated
coordination of the embargoed release process. You cannot pull that
v2.47.2 tag.

In any case, if you don't want to build v2.48.1 instead, and if you cannot
build v2.47.2 from a Git checkout, at least that `version` file method
should work for you and you don't need to put pressure on anybody else to
get the version that is so definitely needed out to the NonStop community.

Ciao,
Johannes

[Junio C Hamano]

Johannes Schindelin <Johannes....@gmx.de> writes:

> my apologies, I only realized _now_ that I had forgotten to update
> `GIT-VERSION-GEN` in v2.47.2, it still has `DEF_VER=v2.47.1` (but all
> other mentioned tagged versions have a correct `GIT-VERSION-GEN`). I am
> very sorry about that.

Heh, mistakes happen. You do not owe _me_ an apology.

I hope I did 2.48.1 right, so we should be OK ;-)

[rsbe...@nexbridge.com]

I will not be able to package this. The reason is that only official commits
are
permitted in the highly regulated customer base that I have to support. If I
modify any file in the git build to "get it out the door", my community will
not install the package, even if I make a fork of git and do it there. My
personal commit is not considered "sanctioned", so the package will be
ignored.

If 2.47.2 has a mistake, I will simply skip the release, and tell people to
move
to 2.48.1 to get the security fix instead of 2.47.2, which is not going to
make
them particularly happy. Sadly, this is my reality.

--Randall

[Junio C Hamano]

<rsbe...@nexbridge.com> writes:

> I will not be able to package this. The reason is that only official commits
> are
> permitted in the highly regulated customer base that I have to support.

Well, you probably want to be a bit more careful.

Think what *exactly* is *this* in "package this" in your message,
for example.

Will it be the resulting checkout of "git clone --single" of that
tag? Then you can go there and say "make", and as Dscho explained,
what Dscho wrote in DEF_VER does not matter. The tag that points at
that checked out commit is v2.47.2 and that is what resulting "git
version" would say.

Will it be the tarball extract from the git-2.47.2.tar.gz that is
available at https://www.kernel.org/pub/software/scm/git/? Then you
can go there and say "make", and what Dscho wrote in DEF_VER does
not matter, either, because the official tarball contains the
'version' file that says "2.47.2" and that is the version used by
the resulting "git version".

[rsbe...@nexbridge.com]

In order to accept our builds, the NonStop community needs to be able to
correlate what we build to a real commit from the git git repository. We
cannot
build from tarballs, as this cannot be certified by the community users. If
they
cannot certify what I am building for them, they will not use it. It is that
simple,
sadly. That is why we worked so hard to have our builds 100% consistent with
the official git commits. Tarballs can be hacked. Now, if members of the
community wanted to do that, I would be elated at the prospect, and it would
save me hundreds of hours a year, but they are not willing (or able) to do
that. My key role is as a trusted build manager for the platform. I cannot
package a modified set of files, so I must skip this element of the friends
of
2.48.1, and ask them to go directly to that version instead of 2.47.2.

I ask you sincerely to please understand the constraints I am under.

[Junio C Hamano]

<rsbe...@nexbridge.com> writes:

> On January 14, 2025 8:28 PM, Junio C Hamano wrote:

> ...

>>Will it be the resulting checkout of "git clone --single" of that tag?
> Then you can go
>>there and say "make", and as Dscho explained, what Dscho wrote in DEF_VER
> does
>>not matter. The tag that points at that checked out commit is v2.47.2 and
> that is
>>what resulting "git version" would say.

>> ...

> In order to accept our builds, the NonStop community needs to be able to
> correlate what we build to a real commit from the git git repository. We
> cannot
> build from tarballs, as this cannot be certified by the community users.

So you are going to build by having a clone of my repository that is
updated via "git fetch" to have these latest tags, and you will
check out the v2.47.2 tag or the "maint-2.47" branch whose tip
happens to be at that tag. And say "make" in there. We may have a
wrong string in DEF_VAR in its GIT-VERSION-GEN file, but as you read
already in the above, it does not matter. Saying "make" would run
GIT-VERSION-GEN script, which notices that you are in a Git
repository and not in a tarball extract, and runs "git describe" on
the commit you are building from, instead of blindly relying on the
value in DEF_VAR.

Which means your build will result in a version of git that says
"2.47.2" when "git version" is run.

So is there still a problem? I am puzzled.