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

[PATCH] wt-status: Don't find scissors line beyond buf len

From
Florian Schmidt <flosch@nutanix.com>
Date
Mar 7, 2024, 18:37 UTC
Message-ID
<20240307183743.219951-1-flosch@nutanix.com>
Currently, if
(a) There is a "---" divider in a commit message,
(b) At some point beyond that divider, there is a cut-line (that is,
    "# ------------------------ >8 ------------------------") in the
    commit message,
(c) the user does not explicitly set the "no-divider" option,
then "git interpret-trailers" will hang indefinitively.

This is because when (a) is true, find_end_of_log_message() will invoke ignored_log_message_bytes() with a len that is intended to make it ignore the part of the commit message beyond the divider. However, ignored_log_message_bytes() calls wt_status_locate_end(), and that function ignores the length restriction when it tries to locate the cut line. If it manages to find one, the returned cutoff value is greater than len. At this point, ignored_log_message_bytes() goes into an infinite loop, because it won't advance the string parsing beyond len, but the exit condition expects to reach cutoff.

It seems sensible to expect that wt_status_locate_end() should honour the length parameter passed in, and doing so fixes this issue.

Signed-off-by: Florian Schmidt <flosch@nutanix.com>
Reviewed-by: Jonathan Davies <jonathan.davies@nutanix.com>
---

Side remark: Since strstr() doesn't consider len, and will always search up to a null byte, I now wonder whether it would be safer to create a new strbuf that only contains the len bytes we want to operate on. If anybody ever thinks they can pass a non-null-terminated string into wt_status_locate_end() because they already provide a len parameter, they will not have a good time. So it's that traded off against the slightly higher overhead of creating yet another buffer and copying a potentially large-ish commit message around.

 t/t7513-interpret-trailers.sh | 14 ++++++++++++++
 wt-status.c                   | 13 +++++++++----
 2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-trailers.sh
index ec9c6de114..3d3e13ccf8 100755
--- a/t/t7513-interpret-trailers.sh
+++ b/t/t7513-interpret-trailers.sh
@@ -1935,4 +1935,18 @@ test_expect_success 'suppressing --- does not disable cut-line handling' '
 	test_cmp expected actual
 '
 
+test_expect_success 'handling of --- lines in conjunction with cut-lines' '
+	echo "my-trailer: here" >expected &&
+
+	git interpret-trailers --parse >actual <<-\EOF &&
+	subject
+
+	my-trailer: here
+	---
+	# ------------------------ >8 ------------------------
+	EOF
+
+	test_cmp expected actual
+'
+
 test_done
diff --git a/wt-status.c b/wt-status.c
index b5a29083df..51a84575ed 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1089,14 +1089,19 @@ size_t wt_status_locate_end(const char *s, size_t len)
 {
 	const char *p;
 	struct strbuf pattern = STRBUF_INIT;
+	size_t result = len;
 
 	strbuf_addf(&pattern, "\n%c %s", comment_line_char, cut_line);
 	if (starts_with(s, pattern.buf + 1))
-		len = 0;
-	else if ((p = strstr(s, pattern.buf)))
-		len = p - s + 1;
+		result = 0;
+	else if ((p = strstr(s, pattern.buf))) {
+		result = p - s + 1;
+		if (result > len) {
+			result = len;
+		}
+	}
 	strbuf_release(&pattern);
-	return len;
+	return result;
 }
 
 void wt_status_append_cut_line(struct strbuf *buf)
-- 
2.42.0
Next: Junio C Hamano
Message 1 of 14 in “wt-status: Don't find scissors line beyond buf len”
  1. wt-status: Don't find scissors line beyond buf lenFlorian Schmidt, Mar 7, 2024
  2. Junio C HamanoMar 7, 2024
  3. Junio C HamanoMar 7, 2024
  4. Eric SunshineMar 7, 2024
  5. Kristoffer HaugsbakkMar 7, 2024
  6. Junio C HamanoMar 7, 2024
  7. Eric SunshineMar 7, 2024
  8. Kristoffer HaugsbakkMar 7, 2024
  9. Florian SchmidtMar 8, 2024
  10. Junio C HamanoMar 8, 2024
  11. Florian SchmidtMar 8, 2024
  12. Linus ArverApr 6, 2024
  13. Junio C HamanoMar 7, 2024
  14. Florian SchmidtMar 8, 2024

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.