Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
WIP git clone protections: special-case Git LFS
TODO: - add support for specifying these hashes in the global config - replace the logic to compare hooks against the template by populating an in-core list of known-good hashes (This might not actually work if we're dealing with sub-processes, dunno, need to check.) As defense-in-depth measures, v2.39.4 and friends leading up to v2.45.1 introduced code that detects when hooks have been installed during a `git clone`, which is indicative of a common attack vector with critical severity that allows Remote Code Execution. There are legitimate use cases for such behavior, though, for example when those hooks stem from Git's own templates, which system administrators are at liberty to modify to enforce, say, commit message conventions. The git clone protections specifically add exceptions to allow for that. Another legitimate use case that has been identified too late to be handled in these security bug-fix versions is Git LFS. The symptom is that any Git LFS-enabled `git clone` will fail with an error message that suggests to set `GIT_CLONE_PROTECTION_ACTIVE=false` and try again. While the clone still works in many circumstances, and while the result can be fixed using `git lfs pull` instead of re-cloning, it is still a concerning usability issue. Let's quickly follow up with code to special-case Git LFS' hooks, too: They have a quite fixed format that has not been changed since git-lfs/git-lfs@86a8d7369c98#diff-2ef0c6acf2db4fdf031483aa31f30f52c12f5b660969f14e3de000eedbf25d1c which was first shipped with Git LFS v3.4.0 in July 2023. That allows for checking the SHA-256 checksums of those files' contents to verify that they are part of a benign scenario rather than an attack. Signed-off-by: Johannes Schindelin <[email protected]>
- Loading branch information