From: Jeff King <peff@peff•net>
To: Jo Liss <joliss42@gmail•com>
Cc: Patrick Steinhardt <ps@pks•im>, git@vger•kernel.org
Subject: Re: remote-curl: segfault parsing remote.<name>.fetch outside a repository
Date: Sat, 21 Mar 2026 17:06:02 -0400 [thread overview]
Message-ID: <20260321210602.GA736981@coredump.intra.peff.net> (raw)
In-Reply-To: <CAN=xy38zCRdOAnMtBXtRyUHE=+gtS8J6mwUWFQqxDAaBLAm7dA@mail.gmail.com>
On Sat, Mar 21, 2026 at 07:11:18PM +0000, Jo Liss wrote:
> I ran into a bug and thought I'd report it! The following command
> segfaults for me (where ~/src/git is my clone):
>
> env -C / \
> GIT_CONFIG_NOSYSTEM=1 \
> GIT_CONFIG_GLOBAL=/dev/null \
> GIT_CONFIG_COUNT=1 \
> GIT_CONFIG_KEY_0=remote.repro.fetch \
> GIT_CONFIG_VALUE_0='+refs/tags/*:refs/tags/*' \
> ~/src/git/git-remote-http repro
>
> In other words, this is happening when the shared remote-curl code
> (here, git-remote-http) is called outside of any repository, while
> `remote.<name>.fetch` is set.
>
> I can reproduce this on Ubuntu and macOS, with git master
> (7ff1e8dc1e16) and git 2.51.0.
This is another fallout from c8aed5e8da (repository: stop setting SHA1
as the default object hash, 2024-05-07).
It's a curious case, though. The crashing code is parse_refspec() does
this:
if (llen == the_hash_algo->hexsz && !get_oid_hex(item->src, &unused))
item->exact_sha1 = 1; /* ok */
But what is the correct hash algo to use here when we are outside a
repository? Usually remote-curl tries to detect the hash algorithm in
use by the other side (based on its info/refs response). But we don't
contact the other side until we've run remote_get(), and the refspec
parsing is happening via that remote_get().
In this particular case, the origin refspecs are not even going to be
used, but you can construct a similar one where they are:
git -C / \
-c remote.foo.url=https://github.com/git/git \
-c remote.foo.fetch=whatever \
ls-remote foo
We could do this:
diff --git a/refspec.c b/refspec.c
index 0775358d96..e6c29b7dd0 100644
--- a/refspec.c
+++ b/refspec.c
@@ -101,7 +101,7 @@ static int parse_refspec(struct refspec_item *item, const char *refspec, int fet
/* LHS */
if (!*item->src)
; /* empty is ok; it means "HEAD" */
- else if (llen == the_hash_algo->hexsz && !get_oid_hex(item->src, &unused))
+ else if (the_hash_algo && llen == the_hash_algo->hexsz && !get_oid_hex(item->src, &unused))
item->exact_sha1 = 1; /* ok */
else if (!check_refname_format(item->src, flags))
; /* valid looking ref is ok */
to make the segfault go away, but it is mostly papering over the
problem. I'm not sure if the exact_sha1 flag would matter when we are
not actually fetching (and we cannot fetch when we are not in a local
repo). Grepping around, it looks like it does influence the ref prefixes
we send to the other side (yet another chicken-and-egg!).
-Peff
next prev parent reply other threads:[~2026-03-21 21:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-21 19:11 remote-curl: segfault parsing remote.<name>.fetch outside a repository Jo Liss
2026-03-21 19:46 ` [PATCH] remote-curl: set fallback hash algorithm outside repo K Jayatheerth
2026-03-21 23:09 ` brian m. carlson
2026-03-22 2:35 ` [PATCH v2] refspec: safely parse refspecs outside a repository K Jayatheerth
2026-03-22 3:31 ` Junio C Hamano
2026-03-22 3:53 ` Jeff King
2026-03-22 5:36 ` [PATCH v3 1/2] " K Jayatheerth
2026-03-22 5:36 ` [PATCH v3 2/2] refspec: fix typo in comment K Jayatheerth
2026-03-23 22:27 ` [PATCH v3 1/2] refspec: safely parse refspecs outside a repository Junio C Hamano
2026-03-23 23:10 ` Jeff King
2026-03-23 23:39 ` Junio C Hamano
2026-03-24 1:57 ` [PATCH v4 1/2] remote-curl: fall back to default hash outside repo K Jayatheerth
2026-03-24 1:57 ` [PATCH v4 2/2] refspec: fix typo in comment K Jayatheerth
2026-03-24 4:25 ` [PATCH v4 1/2] remote-curl: fall back to default hash outside repo Junio C Hamano
2026-03-21 21:06 ` Jeff King [this message]
2026-03-22 1:20 ` remote-curl: segfault parsing remote.<name>.fetch outside a repository Junio C Hamano
2026-03-22 1:37 ` Jeff King
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260321210602.GA736981@coredump.intra.peff.net \
--to=peff@peff$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=joliss42@gmail$(echo .)com \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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