From 8c8b1c8f60f3976fb4cd06ecc7151d53531327be Mon Sep 17 00:00:00 2001 From: Matthew John Cheetham Date: Fri, 20 Mar 2026 11:28:28 +0000 Subject: [PATCH 1/3] http: fix bug in ntlm_allow=1 handling In 816db62d10 (credential: advertise NTLM suppression and allow helpers to re-enable, 2026-02-09), Git learned to advertise that NTLM authentication was suppressed to credential helpers. It also introduced a way to allow credential helpers to opt-back-in to NTLM authentication via the `ntlm_allow=1` credential protocol flag. There is a bug in the logic of 816db62d10 that means we are responding to the `ntlm_allow=1` signal too late in the auth retry codepath; we've already made the second-attempt request! Move adding of NTLM as a valid auth method to `http_request_reauth` right after the credential helper is consulted following the first request, but (now) before we made the second request. Signed-off-by: Matthew John Cheetham --- http.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/http.c b/http.c index 3a6872bb6612b4..be1fd6f41e8241 100644 --- a/http.c +++ b/http.c @@ -1908,10 +1908,6 @@ static int handle_curl_result(struct slot_results *results) else if (results->http_code == 401) { http_auth.ntlm_suppressed = (results->auth_avail & CURLAUTH_NTLM) && !(http_auth_any & CURLAUTH_NTLM); - if (http_auth.ntlm_suppressed && http_auth.ntlm_allow) { - http_auth_methods |= CURLAUTH_NTLM; - return HTTP_REAUTH; - } if ((http_auth.username && http_auth.password) ||\ (http_auth.authtype && http_auth.credential)) { if (http_auth.multistage) { @@ -2373,6 +2369,13 @@ static int http_request_reauth(const char *url, credential_fill(the_repository, &http_auth, 1); + /* + * Re-enable NTLM auth if the helper allows it and we would + * otherwise suppress authentication via NTLM. + */ + if (http_auth.ntlm_suppressed && http_auth.ntlm_allow) + http_auth_methods |= CURLAUTH_NTLM; + ret = http_request(url, result, target, options); } return ret; From dffcb8a8d52e278ea7e1e42e3ba740344180e067 Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Sat, 29 Nov 2025 09:21:58 +0100 Subject: [PATCH 2/3] ci(dockerized): reduce the PID limit for private repositories Every once in a while I need to verify that Microsoft Git's test suite passes for changes that are not yet meant for public consumption, and since it was (made) too difficult to keep up a working Azure Pipeline definition, I have to use GitHub Actions in a private GitHub repository for that purpose. In these tests, basically all Dockerized CI jobs fail consistently. The symptom is something like: error: cannot create async thread: Resource temporarily unavailable in the middle of a test, typically in the t5xxx-t6xxx range. The first such error is immediately followed by plenty more of these errors, and not a single test succeeds afterwards. At first, I thought that maybe the massive parallelism I enjoy there is the problem, and I thought that the cgroups limits might be shared between the many containers that run on essentially the same physical machine. But even reducing the matrix to just a single of those Dockerized jobs runs into the very same problems. The underlying reason seems to be a substantial difference in the hosted runners that execute these Dockerized jobs: forcing the PID limit of the container to a high number lets the jobs pass, even when running the complete matrix of all 13 Dockerized jobs concurrently. But that's not the only difference: The jobs seem to take a lot longer in these containers than, say, in the containers made available to https://github.com/git/git. When forcing a PID limit of 64k in that private repository, the jobs completed successfully, but they also took a lot longer, between 2x to 2.5x longer, i.e. painfully much longer. Reducing the PID limit to 16k, the CI jobs still passed, but took an equally long amount of time. Reducing the PID limit to 8k caused the errors to reappear. Here are the numbers from three example runs, the first one forcing the PID and nproc limit to 65536, the second one to 16384, the third run is from the public git/git repository: Job | 64k | 16k | reference ------------------------------|---------|---------|--------- almalinux-8 | 19m 3s | 16m 0s | 9m 36s debian-11 | 20m 31s | 20m 3s | 8m 5s fedora-breaking-changes-meson | 16m 29s | 19m 19s | 9m 40s linux-asan-ubsan | 1h 10m | 1h 11m | 34m 36s linux-breaking-changes | 25m 39s | 25m 58s | 13m 15s linux-leaks | 1h 9m | 1h 10m | 33m 30s linux-meson | 28m 9s | 27m 4s | 13m 45s linux-musl-meson | 16m 32s | 13m 39s | 8m 6s linux-reftable-leaks | 1h 13m | 1h 13m | 34m 34s linux-reftable | 26m 2s | 25m 48s | 13m 31s linux-sha256 | 26m 12s | 26m 3s | 12m 36s linux-TEST-vars | 26m 5s | 25m 21s | 13m 25s linux32 | 21m 16s | 19m 57s | 10m 44s It does not look as if the PID limit is the reason for the longer runtime, seeing as the 64k vs 16k timings deviate no more than as is usual with GitHub workflows. So let's go for 16k. Signed-off-by: Johannes Schindelin --- .github/workflows/main.yml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 39e7e63c986bd1..9a8a8ae0f5f0b7 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -423,7 +423,9 @@ jobs: CI_JOB_IMAGE: ${{matrix.vector.image}} CUSTOM_PATH: /custom runs-on: ubuntu-latest - container: ${{matrix.vector.image}} + container: + image: ${{ matrix.vector.image }} + options: ${{ github.repository_visibility == 'private' && '--pids-limit 16384 --ulimit nproc=16384:16384 --ulimit nofile=32768:32768' || '' }} steps: - name: prepare libc6 for actions if: matrix.vector.jobname == 'linux32' From 2d77dd812c686b2b8b3e74591aabcdbf978e640a Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Mon, 16 Mar 2026 10:20:23 +0100 Subject: [PATCH 3/3] mingw: skip symlink type auto-detection for network share targets On Windows, symbolic links come in two flavors: file symlinks and directory symlinks. Since Git was born on Linux where this distinction does not exist, Git for Windows has to auto-detect the type by looking at the target. When the target does not yet exist at symlink creation time, Git for Windows creates a "phantom" file symlink and later, once checkout is complete, calls `CreateFileW()` on the target to check whether it is actually a directory. If the symlink target is a UNC path (e.g. `\\attacker\share`), this auto-detection triggers an SMB connection to the remote host. Windows performs NTLM authentication by default for such connections, which means a crafted repository can exfiltrate the cloning user's NTLMv2 hash to an attacker-controlled server without any user interaction beyond `git clone -c core.symlinks=true `. There are ways to specify UNC paths that start with only a single backslash (e.g. `\??\UNC\host\share`); All of them do start like that, though, so let's use that as a tell-tale that we should skip the auto-detection in `process_phantom_symlink()`. The symlink is then left as a file symlink (the `mklink` default), and a warning is emitted suggesting the user set the `symlink` gitattribute to `dir` if a directory symlink is needed. When the attribute is already set, auto-detection is never invoked in the first place, so that code path is unaffected. This is the same class of vulnerability as CVE-2025-66413 (https://github.com/git-for-windows/git/security/advisories/GHSA-hv9c-4jm9-jh3x) and follows the same general mitigation pattern that MinTTY adopted for ANSI escape sequences referencing network share paths (https://github.com/mintty/mintty/security/advisories/GHSA-jf4m-m6rv-p6c5). Note that there are legitimate paths starting with a single backslash that are _not_ network paths: drive-less absolute paths are interpreted as relative to the current working directory's drive. In practice, these are highly uncommon (and brittle, just one working directory change away from breaking). In any case, the only consequence is now that the symlink type of those has to be specified via Git attributes, is all. Reported-by: Justin Lee Addresses: CVE-2026-32631 Addresses: https://github.com/git-for-windows/git/security/advisories/GHSA-9j5h-h4m7-85hx Assisted-by: Claude Opus 4.6 Signed-off-by: Johannes Schindelin --- compat/mingw.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/compat/mingw.c b/compat/mingw.c index 5a9807e7a42b41..06a80ea1931cfc 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -385,6 +385,29 @@ process_phantom_symlink(const wchar_t *wtarget, const wchar_t *wlink) wchar_t relative[MAX_LONG_PATH]; const wchar_t *rel; + /* + * Do not follow symlinks to network shares, to avoid NTLM credential + * leak from crafted repositories (e.g. \\attacker-server\share). + * Since paths come in all kind of enterprising shapes and forms (in + * addition to the canonical `\\host\share` form, there's also + * `\??\UNC\host\share`, `\GLOBAL??\UNC\host\share` and also + * `\Device\Mup\host\share`, just to name a few), we simply avoid + * following every symlink target that starts with a slash. + * + * This also catches drive-less absolute paths, of course. These are + * uncommon in practice (and also fragile because they are relative to + * the current working directory's drive). The only "harm" this does + * is that it now requires users to specify via the Git attributes if + * they have such an uncommon symbolic link and need it to be a + * directory type link. + */ + if (is_wdir_sep(wtarget[0])) { + warning("created file symlink '%ls' pointing to '%ls';\n" + "set the `symlink` gitattribute to `dir` if a " + "directory symlink is required", wlink, wtarget); + return PHANTOM_SYMLINK_DONE; + } + /* check that wlink is still a file symlink */ if ((GetFileAttributesW(wlink) & (FILE_ATTRIBUTE_REPARSE_POINT | FILE_ATTRIBUTE_DIRECTORY))