From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Cc: "brian m. carlson" <bk2204@github.com>
Subject: [PATCH] rerere: match the hash algorithm with its length
Date: Fri, 21 Jul 2023 16:36:12 -0700 [thread overview]
Message-ID: <xmqqa5vou9ar.fsf@gitster.g> (raw)
The "conflict ID" used by "git rerere" to identify past conflicts we
saw has been a SHA-1 hash of the normalized text taken from the
conflicted region. 0d7c419a (rerere: convert to use the_hash_algo,
2018-10-15) updated the rerere machinery to use more general "hash"
instead of hardcoded SHA-1 by using the_hash_algo, GIT_MAX_RAWSZ and
their friends, but the code that read from the MERGE_RR records were
left unconverted to still use get_sha1_hex(), possibly breaking the
operation in SHA-256 repositories.
We enumerate the subdirectories of $GIT_DIR/rr-cache/ and use the
ones whose name passes parse_oid_hex() in full as conflict IDs,
so they are always of correct length relative to the choice of the
hash the repository makes, and they are written to the MERGE_RR
file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* The "conflict ID" uses SHA-1 not because we needed a secure hash.
We only needed something that is reasonably long with fewer
collisions (the "rerere" machinery tolerates collisions). We
just had SHA-1 readily available to us and that was the only
reason we used it. As these "conflict ID" are not security
sensitive, we could leave them as SHA-1 even in SHA-256
repositories and reverting 0d7c419a might be a good first step if
we want to go in that direction, but let's be consistent.
rerere.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/rerere.c b/rerere.c
index 7070f75014..f06172253b 100644
--- a/rerere.c
+++ b/rerere.c
@@ -203,8 +203,13 @@ static void read_rr(struct repository *r, struct string_list *rr)
int variant;
const unsigned hexsz = the_hash_algo->hexsz;
- /* There has to be the hash, tab, path and then NUL */
- if (buf.len < hexsz + 2 || get_sha1_hex(buf.buf, hash))
+ /*
+ * There has to be the "conflict ID", tab, path and then NUL.
+ * "conflict ID" would be a hash, possibly suffixed by "." and
+ * a small integer (variant number).
+ */
+ if (buf.len < hexsz + 2 ||
+ get_hash_hex_algop(buf.buf, hash, the_hash_algo))
die(_("corrupt MERGE_RR"));
if (buf.buf[hexsz] != '.') {
--
2.41.0-394-ge43f4fd0bd
next reply other threads:[~2023-07-21 23:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-21 23:36 Junio C Hamano [this message]
2023-07-23 15:03 ` [PATCH] rerere: match the hash algorithm with its length brian m. carlson
2023-07-23 16:24 ` Junio C Hamano
2023-07-24 21:22 ` brian m. carlson
2023-07-24 23:11 ` Re* " Junio C Hamano
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=xmqqa5vou9ar.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=bk2204@github.com \
--cc=git@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.