Recent Git security releases break `git clone` on repositories using LFS

[brian m. carlson]

Git has recently released several security releases that introduce a regression when using git clone on a repository with Git LFS. When cloning, a message like the following occurs, and LFS files are not checked out:

$ git clone https://github.com/octocat/xyzzy.git
Cloning into 'pull-bug'...
remote: Enumerating objects: 1275, done.
remote: Counting objects: 100% (343/343), done.
remote: Compressing objects: 100% (136/136), done.
remote: Total 1275 (delta 221), reused 327 (delta 206), pack-reused 932
Receiving objects: 100% (1275/1275), 290.78 KiB | 2.88 MiB/s, done.
Resolving deltas: 100% (226/226), done.
Filtering content: 100% (504/504), 1.86 KiB | 0 bytes/s, done.
fatal: active `post-checkout` hook found during `git clone`:
        /home/octocat/xyzzy/.git/hooks/post-checkout
For security reasons, this is disallowed by default.
If this is intentional and the hook should actually be run, please
run the command again with `GIT_CLONE_PROTECTION_ACTIVE=false`
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

Note that this message and the nonzero exit status also affect users using GIT_LFS_SKIP_SMUDGE=1, such as many CI systems, so this can't be used as a workaround. Users can set the environment variable GIT_CLONE_PROTECTION_ACTIVE=false globally, which will disable this check, or if the repository has already been cloned, users can use git lfs pull to fix the repository and the hooks. (Note that setting the GIT_CLONE_PROTECTION_ACTIVE=false environment variable disables the defense-in-depth measure outlined below.)

Ultimately, this is a regression in Git that was introduced as a defense-in-depth measure. The problem is in Git and cannot be worked around in Git LFS itself without a substantial loss of functionality. The Git developers are aware of the problem and discussion about how to solve it is underway or will be underway shortly on the mailing list. If you're interested, you can follow the discussion there or post yourself (please note that only plain text mail is allowed; no HTML parts can be sent at all).

We realize this has a big impact and we're working with the Git developers to get it fixed as quickly as possible. In the mean time, distributors and users can revert the following non-essential patches, which will solve the problem:

• clone: prevent hooks from running during a clone
• core.hooksPath: add some protection while cloning

Since this is a Git bug and not a Git LFS bug, most discussion about this issue should take place on the Git list, and not on the Git LFS GitHub page. Please refrain from opening issues on this matter on the Git LFS issue tracker. If there is productive discussion about topics that aren't suitable for the Git list (e.g., workarounds), please discuss those in the Git LFS discussions.

We'd also like to encourage people to participate in the respective communities in a positive way and in conjunction with the Git LFS Code of Conduct and the Git Code of Conduct.

[brian m. carlson]

The reverted patches have been sent to the Git list.

[brian m. carlson]

A new series which will soon be merged to the Git maintenance branches has been proposed, which should address this issue and will be included in a 2.45.2 and various other versions.

[brian m. carlson]

Git 2.45.2 has been released, which should fix Git LFS.