From: "Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: Taylor Blau <me@ttaylorr.com>,
Phillip Wood <phillip.wood@dunelm.org.uk>,
Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: [PATCH] apply: improve error messages when reading patch
Date: Mon, 26 Jun 2023 09:37:33 +0000 [thread overview]
Message-ID: <pull.1552.git.1687772253869.gitgitgadget@gmail.com> (raw)
From: Phillip Wood <phillip.wood@dunelm.org.uk>
Commit f1c0e3946e (apply: reject patches larger than ~1 GiB, 2022-10-25)
added a limit on the size of patch that apply will process to avoid
integer overflows. The implementation re-used the existing error message
for when we are unable to read the patch. This is unfortunate because (a) it
does not signal to the user that the patch is being rejected because it
is too large and (b) it uses error_errno() without setting errno.
This patch adds a specific error message for the case when a patch is
too large. It also updates the existing message to make it clearer that
it is the patch that cannot be read rather than any other file and marks
both messages for translation. The "git apply" prefix is also dropped to
match most of the rest of the error messages in apply.c (there are still
a few error messages that prefixed with "git apply" and are not marked
for translation after this patch). The test added in f1c0e3946e is
updated accordingly.
Reported-by: Premek Vysoky <Premek.Vysoky@microsoft.com>
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
---
apply: improve error messages when reading patch
I haven't changed it but I found the test a bit confusing as it
superficially looks like it is generating a valid patch that is too
large, but it isn't actually a valid patch because the changed line is
lacking a leading '+' and a trailing '\n'. As we are checking for the
error message that does not matter but it might be clearer to just do
sz=$((1024 * 1024 * 1023)) &&
test-tool genzeros $sz | test_must_fail git apply &&
grep "patch too large" err
if we don't care about the patch being valid. Alternatively we could
create a valid patch with
sz=$((1024 * 1024 * 1023)) &&
{
cat <<-\EOF &&
diff --git a/file b/file
new file mode 100644
--- /dev/null
+++ b/file
@@ -0,0 +1 @@
EOF
printf "+%${sz}s\n" x
} | test_must_fail git apply 2>err &&
grep "patch too large" err
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1552%2Fphillipwood%2Fapply-error-message-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1552/phillipwood/apply-error-message-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1552
apply.c | 7 ++++---
t/t4141-apply-too-large.sh | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/apply.c b/apply.c
index 6212ab3a1b3..21c7f92ada8 100644
--- a/apply.c
+++ b/apply.c
@@ -410,9 +410,10 @@ static void say_patch_name(FILE *output, const char *fmt, struct patch *patch)
static int read_patch_file(struct strbuf *sb, int fd)
{
- if (strbuf_read(sb, fd, 0) < 0 || sb->len >= MAX_APPLY_SIZE)
- return error_errno("git apply: failed to read");
-
+ if (strbuf_read(sb, fd, 0) < 0)
+ return error_errno(_("failed to read patch"));
+ else if (sb->len >= MAX_APPLY_SIZE)
+ return error(_("patch too large"));
/*
* Make sure that we have some slop in the buffer
* so that we can do speculative "memcmp" etc, and
diff --git a/t/t4141-apply-too-large.sh b/t/t4141-apply-too-large.sh
index 58742d4fc5d..20cc1209f62 100755
--- a/t/t4141-apply-too-large.sh
+++ b/t/t4141-apply-too-large.sh
@@ -17,7 +17,7 @@ test_expect_success EXPENSIVE 'git apply rejects patches that are too large' '
EOF
test-tool genzeros
} | test_copy_bytes $sz | test_must_fail git apply 2>err &&
- grep "git apply: failed to read" err
+ grep "patch too large" err
'
test_done
base-commit: fe86abd7511a9a6862d5706c6fa1d9b57a63ba09
--
gitgitgadget
next reply other threads:[~2023-06-26 9:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-26 9:37 Phillip Wood via GitGitGadget [this message]
2023-06-26 15:58 ` [PATCH] apply: improve error messages when reading patch 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=pull.1552.git.1687772253869.gitgitgadget@gmail.com \
--to=gitgitgadget@gmail.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
--cc=phillip.wood@dunelm.org.uk \
/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).