Git Mailing List Archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <>
Cc: Linux Kernel <>,
Subject: [ANNOUNCE] Git v2.45.1 and friends
Date: Tue, 14 May 2024 10:06:04 -0700	[thread overview]
Message-ID: <xmqqv83g4937.fsf@gitster.g> (raw)

A maintenance release Git v2.45.1, together with releases for older
maintenance tracks v2.44.1, v2.43.4, v2.42.2, v2.41.1, v2.40.2, and
v2.39.4, are now available at the usual places.  These are to address
a handful of security issues.

The tarballs are found at:

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

  url =
  url =
  url = git://
  url =

The addressed issues are all listed in the release notes for Git
2.39.4, attached below.

Note: There is a regression for Git LFS users.  The defense-in-depth
protection this update contains is at odds with the way Git LFS
currently works when cloning a new repository that wants to use the
post-checkout hook during the initial cloning.  The users can fix it
after the fact by running `git lfs pull`, if the checkout stage is
stopped, as a workaround.  The error message given after a failed
clone also gives an alternative workaround to disable the added
safety with the use of the GIT_CLONE_PROTECTION_ACTIVE environment
variable that the users and the scripts can use.

Git v2.39.4 Release Notes

This addresses the security issues CVE-2024-32002, CVE-2024-32004,
CVE-2024-32020 and CVE-2024-32021.

This release also backports fixes necessary to let the CI builds pass

Fixes since v2.39.3

 * CVE-2024-32002:

   Recursive clones on case-insensitive filesystems that support symbolic
   links are susceptible to case confusion that can be exploited to
   execute just-cloned code during the clone operation.

 * CVE-2024-32004:

   Repositories can be configured to execute arbitrary code during local
   clones. To address this, the ownership checks introduced in v2.30.3
   are now extended to cover cloning local repositories.

 * CVE-2024-32020:

   Local clones may end up hardlinking files into the target repository's
   object database when source and target repository reside on the same
   disk. If the source repository is owned by a different user, then
   those hardlinked files may be rewritten at any point in time by the
   untrusted user.

 * CVE-2024-32021:

   When cloning a local source repository that contains symlinks via the
   filesystem, Git may create hardlinks to arbitrary user-readable files
   on the same filesystem as the target repository in the objects/

 * CVE-2024-32465:

   It is supposed to be safe to clone untrusted repositories, even those
   unpacked from zip archives or tarballs originating from untrusted
   sources, but Git can be tricked to run arbitrary code as part of the

 * Defense-in-depth: submodule: require the submodule path to contain
   directories only.

 * Defense-in-depth: clone: when symbolic links collide with directories, keep
   the latter.

 * Defense-in-depth: clone: prevent hooks from running during a clone.

 * Defense-in-depth: core.hooksPath: add some protection while cloning.

 * Defense-in-depth: fsck: warn about symlink pointing inside a gitdir.

 * Various fix-ups on HTTP tests.

 * Test update.

 * HTTP Header redaction code has been adjusted for a newer version of
   cURL library that shows its traces differently from earlier

 * Fix was added to work around a regression in libcURL 8.7.0 (which has
   already been fixed in their tip of the tree).

 * Replace macos-12 used at GitHub CI with macos-13.

 * ci(linux-asan/linux-ubsan): let's save some time

 * Tests with LSan from time to time seem to emit harmless message that makes
   our tests unnecessarily flakey; we work it around by filtering the
   uninteresting output.

 * Update GitHub Actions jobs to avoid warnings against using deprecated
   version of Node.js.

                 reply	other threads:[~2024-05-14 17:06 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqv83g4937.fsf@gitster.g \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).