From: Patrick Steinhardt <ps@pks.im>
To: git@vger.kernel.org
Cc: Kyle Lippincott <spectral@google.com>,
Junio C Hamano <gitster@pobox.com>
Subject: [PATCH 1/2] config: fix segfault when parsing "core.abbrev" without repo
Date: Tue, 11 Jun 2024 10:42:02 +0200 [thread overview]
Message-ID: <7ded51bbce1b23cf4110e3bf0abb7579efd4d344.1718095090.git.ps@pks.im> (raw)
In-Reply-To: <CAO_smVimsHAPbMxy09mcYZY8apFgCbpnS9eSF7UOL6_BLqntNw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4099 bytes --]
The "core.abbrev" config allows the user to specify the minimum length
when abbreviating object hashes. Next to the values "auto" and "no",
this config also accepts a concrete length that needs to be bigger or
equal to the minimum length and smaller or equal to the hash algorithm's
hex length. While the former condition is trivial, the latter depends on
the object format used by the current repository. It is thus a variable
upper boundary that may either be 40 (SHA-1) or 64 (SHA-256).
This has two major downsides. First, the user that specifies this config
must be aware of the object hashes that its repository use. If they want
to configure the value globally, then they cannot pick any value in the
range `[41, 64]` if they have any repository that uses SHA-1. If they
did, Git would error out when parsing the config.
Second, and more importantly, parsing "core.abbrev" crashes when outside
of a Git repository because we dereference `the_hash_algo` to figure out
its hex length. Starting with c8aed5e8da (repository: stop setting SHA1
as the default object hash, 2024-05-07) though, we stopped initializing
`the_hash_algo` outside of Git repositories.
Fix both of these issues by not making it an error anymore when the
given length exceeds the hash length. Instead, if we have a repository,
then we truncate the length to the maximum length of `the_hash_algo`.
Otherwise, we simply leave the abbreviated length intact and store it
as-is. This is equivalent to the logic in `parse_opt_abbrev_cb()` and is
handled just fine by `repo_find_unique_abbrev_r()`. In practice, we
should never even end up using `default_abbrev` without a repository
anyway given that abbreviating object IDs to unique prefixes requires us
to have access to an object database.
Reported-by: Kyle Lippincott <spectral@google.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
config.c | 7 +++++--
t/t4202-log.sh | 6 ++++++
t/t5601-clone.sh | 7 +++++++
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index abce05b774..ab2844d9e1 100644
--- a/config.c
+++ b/config.c
@@ -1460,11 +1460,14 @@ static int git_default_core_config(const char *var, const char *value,
if (!strcasecmp(value, "auto"))
default_abbrev = -1;
else if (!git_parse_maybe_bool_text(value))
- default_abbrev = the_hash_algo->hexsz;
+ default_abbrev = startup_info->have_repository ?
+ the_hash_algo->hexsz : GIT_MAX_HEXSZ;
else {
int abbrev = git_config_int(var, value, ctx->kvi);
- if (abbrev < minimum_abbrev || abbrev > the_hash_algo->hexsz)
+ if (abbrev < minimum_abbrev)
return error(_("abbrev length out of range: %d"), abbrev);
+ else if (startup_info->have_repository && abbrev > the_hash_algo->hexsz)
+ abbrev = the_hash_algo->hexsz;
default_abbrev = abbrev;
}
return 0;
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 86c695eb0a..99c063e4cd 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -1237,6 +1237,12 @@ test_expect_success 'log.abbrevCommit configuration' '
test_cmp expect.whatchanged.full actual
'
+test_expect_success 'log.abbrevCommit with --abbrev=9000' '
+ git log --no-abbrev >expect &&
+ git log --abbrev-commit --abbrev=9000 >actual &&
+ test_cmp expect actual
+'
+
test_expect_success 'show added path under "--follow -M"' '
# This tests for a regression introduced in v1.7.2-rc0~103^2~2
test_create_repo regression &&
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index cc0b953f14..5d7ea147f1 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -46,6 +46,13 @@ test_expect_success 'output from clone' '
test $(grep Clon output | wc -l) = 1
'
+test_expect_success 'output from clone with core.abbrev does not crash' '
+ rm -fr dst &&
+ echo "Cloning into ${SQ}dst${SQ}..." >expect &&
+ git -c core.abbrev=12 clone -n "file://$(pwd)/src" dst >actual 2>&1 &&
+ test_cmp expect actual
+'
+
test_expect_success 'clone does not keep pack' '
rm -fr dst &&
--
2.45.2.436.gcd77e87115.dirty
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-06-11 8:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-10 22:27 SEGV (detected by Address Sanitizer) when using `core.abbrev` option Kyle Lippincott
2024-06-10 23:01 ` Kyle Lippincott
2024-06-10 23:21 ` Junio C Hamano
2024-06-11 6:06 ` Patrick Steinhardt
2024-06-11 8:42 ` Patrick Steinhardt [this message]
2024-06-11 17:54 ` [PATCH 1/2] config: fix segfault when parsing "core.abbrev" without repo Junio C Hamano
2024-06-12 5:55 ` Patrick Steinhardt
2024-06-11 8:42 ` [PATCH 2/2] object-name: don't try to abbreviate to lengths greater than hexsz Patrick Steinhardt
2024-06-12 8:03 ` [PATCH v2 0/3] config: fix segfault when parsing "core.abbrev" without repo Patrick Steinhardt
2024-06-12 8:03 ` [PATCH v2 1/3] " Patrick Steinhardt
2024-06-12 9:22 ` Karthik Nayak
2024-06-12 8:03 ` [PATCH v2 2/3] parse-options-cb: stop clamping "--abbrev=" to hash length Patrick Steinhardt
2024-06-12 8:03 ` [PATCH v2 3/3] object-name: don't try to abbreviate to lengths greater than hexsz Patrick Steinhardt
2024-06-12 9:29 ` [PATCH v2 0/3] config: fix segfault when parsing "core.abbrev" without repo Karthik Nayak
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=7ded51bbce1b23cf4110e3bf0abb7579efd4d344.1718095090.git.ps@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=spectral@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).