git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH] rerere: match the hash algorithm with its length

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 21, 2023, 23:36 UTC
Message-ID
<xmqqa5vou9ar.fsf@gitster.g>

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: brian m. carlson
Message 1 of 5 in “rerere: match the hash algorithm with its length”
  1. rerere: match the hash algorithm with its lengthJunio C Hamano, Jul 21, 2023
  2. brian m. carlsonJul 23, 2023
  3. Junio C HamanoJul 23, 2023
  4. brian m. carlsonJul 24, 2023
  5. Re* [PATCH] rerere: match the hash algorithm with its lengthJunio C Hamano, Jul 24, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.