When a remote helper like git-remote-http is invoked outside of a
repository (for example, by running git ls-remote in a non-git
directory), setup_git_directory_gently() leaves the_hash_algo
uninitialized as NULL.
If the user has a globally configured fetch refspec, remote-curl
attempts to parse it during initialization. Inside parse_refspec(),
it checks whether the LHS of the refspec is an exact OID by evaluating
llen == the_hash_algo->hexsz. Because the_hash_algo is NULL, this
results in a segmentation fault.
In
9e89dcb66a (builtin/ls-remote: fall back to SHA1 outside of a repo,
2024-08-02), we added a workaround to ls-remote to fall back to the
default hash algorithm to prevent exactly this type of crash when
parsing refspec capabilities. However, because remote-curl runs as a
separate process, it does not inherit that fallback and crashes anyway.
Instead of pushing a NULL-guard workaround down into parse_refspec(),
fix this by mirroring the ls-remote workaround directly in
remote-curl.c. If we are operating outside a repository, initialize
the_hash_algo to GIT_HASH_DEFAULT. This keeps the HTTP transport
consistent with non-HTTP transports that execute in-process, preventing
crashes without altering the generic refspec parsing logic.
Reported-by: Jo Liss <redacted>
Helped-by: Jeff King <redacted>
Signed-off-by: K Jayatheerth <redacted>
Signed-off-by: Junio C Hamano <redacted>
goto cleanup;
}
+ /*
+ * yuck, see 9e89dcb66a (builtin/ls-remote: fall back to SHA1 outside
+ * of a repo, 2024-08-02)
+ */
+ if (nongit)
+ repo_set_hash_algo(the_repository, GIT_HASH_DEFAULT);
+
options.verbosity = 1;
options.progress = !!isatty(2);
options.thin = 1;
test_cmp expect actual
'
+test_expect_success 'ls-remote outside repo does not segfault with fetch refspec' '
+ nongit git \
+ -c remote.origin.url="$HTTPD_URL/smart/repo.git" \
+ -c remote.origin.fetch=anything \
+ ls-remote origin
+'
+
test_done