# [PATCH] upload-pack: don't send null character in abort message to the client 2 messages from 2024-02-25 to 2024-02-26. Participants: SZEDER Gábor, Junio C Hamano. Thread: https://gitlist.dev/t/60996 ## SZEDER Gábor, 2024-02-25 18:34 Subject: [PATCH] upload-pack: don't send null character in abort message to the client Message-ID: <20240225183452.1939334-1-szeder.dev@gmail.com> URL: https://gitlist.dev/e/20240225183452.1939334-1-szeder.dev%40gmail.com ``` Since 583b7ea31b (upload-pack/fetch-pack: support side-band communication, 2006-06-21) the abort message sent by upload-pack in case of possible repository corruption ends with a null character. This can be seen in several test cases in 't5530-upload-pack-error.sh' where 'grep output.err' often reports "Binary file output.err matches" because of that null character. The reason for this is that the abort message is defined as a string literal, and we pass its size to the send function as sizeof(abort_msg), which also counts the terminating null character. Use strlen() instead to avoid sending that terminating null character. Signed-off-by: SZEDER Gábor --- upload-pack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/upload-pack.c b/upload-pack.c index 2537affa90..6e0d441ef5 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -463,7 +463,7 @@ static void create_pack_file(struct upload_pack_data *pack_data, fail: free(output_state); - send_client_data(3, abort_msg, sizeof(abort_msg), + send_client_data(3, abort_msg, strlen(abort_msg), pack_data->use_sideband); die("git upload-pack: %s", abort_msg); } -- 2.44.0.rc1.366.g26e5fbbdb0 ``` ## Junio C Hamano, 2024-02-26 17:49 Subject: Re: [PATCH] upload-pack: don't send null character in abort message to the client Message-ID: URL: https://gitlist.dev/e/xmqqttlvnmk1.fsf%40gitster.g In-Reply-To: <20240225183452.1939334-1-szeder.dev@gmail.com> ``` SZEDER Gábor writes: > Since 583b7ea31b (upload-pack/fetch-pack: support side-band > communication, 2006-06-21) the abort message sent by upload-pack in > case of possible repository corruption ends with a null character. It is so so old that makes me wonder if it is safe to "fix" it, but I cannot think of a sensible way to write a third-party client that may have been working fine and would break when this fix is made. > This can be seen in several test cases in 't5530-upload-pack-error.sh' > where 'grep output.err' often reports "Binary file > output.err matches" because of that null character. > > The reason for this is that the abort message is defined as a string > literal, and we pass its size to the send function as > sizeof(abort_msg), which also counts the terminating null character. > > Use strlen() instead to avoid sending that terminating null character. > > Signed-off-by: SZEDER Gábor > --- > upload-pack.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/upload-pack.c b/upload-pack.c > index 2537affa90..6e0d441ef5 100644 > --- a/upload-pack.c > +++ b/upload-pack.c > @@ -463,7 +463,7 @@ static void create_pack_file(struct upload_pack_data *pack_data, > > fail: > free(output_state); > - send_client_data(3, abort_msg, sizeof(abort_msg), > + send_client_data(3, abort_msg, strlen(abort_msg), > pack_data->use_sideband); > die("git upload-pack: %s", abort_msg); > } ```