2011-10-12 16:33:54 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='git am with corrupt input'
|
tests: mark tests as passing with SANITIZE=leak
When the "ab/various-leak-fixes" topic was merged in [1] only t6021
would fail if the tests were run in the
"GIT_TEST_PASSING_SANITIZE_LEAK=check" mode, i.e. to check whether we
marked all leak-free tests with "TEST_PASSES_SANITIZE_LEAK=true".
Since then we've had various tests starting to pass under
SANITIZE=leak. Let's mark those as passing, this is when they started
to pass, narrowed down with "git bisect":
- t5317-pack-objects-filter-objects.sh: In
faebba436e6 (list-objects-filter: plug pattern_list leak, 2022-12-01).
- t3210-pack-refs.sh, t5613-info-alternate.sh,
t7403-submodule-sync.sh: In 189e97bc4ba (diff: remove parseopts member
from struct diff_options, 2022-12-01).
- t1408-packed-refs.sh: In ab91f6b7c42 (Merge branch
'rs/diff-parseopts', 2022-12-19).
- t0023-crlf-am.sh, t4152-am-subjects.sh, t4254-am-corrupt.sh,
t4256-am-format-flowed.sh, t4257-am-interactive.sh,
t5403-post-checkout-hook.sh: In a658e881c13 (am: don't pass strvec to
apply_parse_options(), 2022-12-13)
- t1301-shared-repo.sh, t1302-repo-version.sh: In b07a819c05f (reflog:
clear leftovers in reflog_expiry_cleanup(), 2022-12-13).
- t1304-default-acl.sh, t1410-reflog.sh,
t5330-no-lazy-fetch-with-commit-graph.sh, t5502-quickfetch.sh,
t5604-clone-reference.sh, t6014-rev-list-all.sh,
t7701-repack-unpack-unreachable.sh: In b0c61be3209 (Merge branch
'rs/reflog-expiry-cleanup', 2022-12-26)
- t3800-mktag.sh, t5302-pack-index.sh, t5306-pack-nobase.sh,
t5573-pull-verify-signatures.sh, t7612-merge-verify-signatures.sh: In
69bbbe484ba (hash-object: use fsck for object checks, 2023-01-18).
- t1451-fsck-buffer.sh: In 8e4309038f0 (fsck: do not assume
NUL-termination of buffers, 2023-01-19).
- t6501-freshen-objects.sh: In abf2bb895b4 (Merge branch
'jk/hash-object-fsck', 2023-01-30)
1. 9ea1378d046 (Merge branch 'ab/various-leak-fixes', 2022-12-14)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-07 00:07:36 +01:00
|
|
|
|
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2011-10-12 16:33:54 +02:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
mailinfo.c: avoid strlen on strings that can contains NUL
We're passing buffer from strbuf to reencode_string,
which will call strlen(3) on that buffer,
and discard the length of newly created buffer.
Then, we compute the length of the return buffer to attach to strbuf.
During this process, we introduce a discrimination between mail
originally written in utf-8 and other encoding.
* if the email was written in utf-8, we leave it as is. If there is
a NUL character in that line, we complains loudly:
error: a NUL byte in commit log message not allowed.
* if the email was written in other encoding, we truncate the data as
the NUL character in that line, then we used the truncated line for
the metadata.
We can do better by reusing all the available information,
and call the underlying lower level function that will be called
indirectly by reencode_string. By doing this, we will also postpone
the NUL character processing to the commit step, which will
complains about the faulty metadata.
Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-21 01:54:35 +02:00
|
|
|
make_mbox_with_nul () {
|
|
|
|
space=' '
|
|
|
|
q_nul_in_subject=
|
|
|
|
q_nul_in_body=
|
|
|
|
while test $# -ne 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
subject) q_nul_in_subject='=00' ;;
|
|
|
|
body) q_nul_in_body='=00' ;;
|
|
|
|
esac &&
|
|
|
|
shift
|
|
|
|
done &&
|
|
|
|
cat <<-EOF
|
|
|
|
From ec7364544f690c560304f5a5de9428ea3b978b26 Mon Sep 17 00:00:00 2001
|
|
|
|
From: A U Thor <author@example.com>
|
|
|
|
Date: Sun, 19 Apr 2020 13:42:07 +0700
|
|
|
|
Subject: [PATCH] =?ISO-8859-1?q?=C4=CB${q_nul_in_subject}=D1=CF=D6?=
|
|
|
|
MIME-Version: 1.0
|
|
|
|
Content-Type: text/plain; charset=ISO-8859-1
|
|
|
|
Content-Transfer-Encoding: quoted-printable
|
|
|
|
|
|
|
|
abc${q_nul_in_body}def
|
|
|
|
---
|
|
|
|
diff --git a/afile b/afile
|
|
|
|
new file mode 100644
|
|
|
|
index 0000000000..e69de29bb2
|
|
|
|
--$space
|
|
|
|
2.26.1
|
|
|
|
EOF
|
|
|
|
}
|
|
|
|
|
2011-10-12 16:33:54 +02:00
|
|
|
test_expect_success setup '
|
2013-10-16 14:27:16 +02:00
|
|
|
# Note the missing "+++" line:
|
|
|
|
cat >bad-patch.diff <<-\EOF &&
|
|
|
|
From: A U Thor <au.thor@example.com>
|
|
|
|
diff --git a/f b/f
|
|
|
|
index 7898192..6178079 100644
|
|
|
|
--- a/f
|
|
|
|
@@ -1 +1 @@
|
|
|
|
-a
|
|
|
|
+b
|
|
|
|
EOF
|
|
|
|
|
|
|
|
echo a >f &&
|
2011-10-12 16:33:54 +02:00
|
|
|
git add f &&
|
|
|
|
test_tick &&
|
|
|
|
git commit -m initial
|
|
|
|
'
|
|
|
|
|
|
|
|
# This used to fail before, too, but with a different diagnostic.
|
|
|
|
# fatal: unable to write file '(null)' mode 100644: Bad address
|
|
|
|
# Also, it had the unwanted side-effect of deleting f.
|
|
|
|
test_expect_success 'try to apply corrupted patch' '
|
2020-04-21 01:54:34 +02:00
|
|
|
test_when_finished "git am --abort" &&
|
|
|
|
test_must_fail git -c advice.amWorkDir=false am bad-patch.diff 2>actual &&
|
2016-08-08 23:03:02 +02:00
|
|
|
echo "error: git diff header lacks filename information (line 4)" >expected &&
|
2013-10-16 14:27:16 +02:00
|
|
|
test_path_is_file f &&
|
2021-02-11 02:53:53 +01:00
|
|
|
test_cmp expected actual
|
2011-10-12 16:33:54 +02:00
|
|
|
'
|
|
|
|
|
mailinfo.c: avoid strlen on strings that can contains NUL
We're passing buffer from strbuf to reencode_string,
which will call strlen(3) on that buffer,
and discard the length of newly created buffer.
Then, we compute the length of the return buffer to attach to strbuf.
During this process, we introduce a discrimination between mail
originally written in utf-8 and other encoding.
* if the email was written in utf-8, we leave it as is. If there is
a NUL character in that line, we complains loudly:
error: a NUL byte in commit log message not allowed.
* if the email was written in other encoding, we truncate the data as
the NUL character in that line, then we used the truncated line for
the metadata.
We can do better by reusing all the available information,
and call the underlying lower level function that will be called
indirectly by reencode_string. By doing this, we will also postpone
the NUL character processing to the commit step, which will
complains about the faulty metadata.
Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-21 01:54:35 +02:00
|
|
|
test_expect_success "NUL in commit message's body" '
|
|
|
|
test_when_finished "git am --abort" &&
|
|
|
|
make_mbox_with_nul body >body.patch &&
|
|
|
|
test_must_fail git am body.patch 2>err &&
|
|
|
|
grep "a NUL byte in commit log message not allowed" err
|
|
|
|
'
|
|
|
|
|
2020-04-21 01:54:36 +02:00
|
|
|
test_expect_success "NUL in commit message's header" "
|
mailinfo.c: avoid strlen on strings that can contains NUL
We're passing buffer from strbuf to reencode_string,
which will call strlen(3) on that buffer,
and discard the length of newly created buffer.
Then, we compute the length of the return buffer to attach to strbuf.
During this process, we introduce a discrimination between mail
originally written in utf-8 and other encoding.
* if the email was written in utf-8, we leave it as is. If there is
a NUL character in that line, we complains loudly:
error: a NUL byte in commit log message not allowed.
* if the email was written in other encoding, we truncate the data as
the NUL character in that line, then we used the truncated line for
the metadata.
We can do better by reusing all the available information,
and call the underlying lower level function that will be called
indirectly by reencode_string. By doing this, we will also postpone
the NUL character processing to the commit step, which will
complains about the faulty metadata.
Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-21 01:54:35 +02:00
|
|
|
test_when_finished 'git am --abort' &&
|
|
|
|
make_mbox_with_nul subject >subject.patch &&
|
2020-04-21 01:54:36 +02:00
|
|
|
test_must_fail git mailinfo msg patch <subject.patch 2>err &&
|
|
|
|
grep \"a NUL byte in 'Subject' is not allowed\" err &&
|
|
|
|
test_must_fail git am subject.patch 2>err &&
|
|
|
|
grep \"a NUL byte in 'Subject' is not allowed\" err
|
mailinfo.c: avoid strlen on strings that can contains NUL
We're passing buffer from strbuf to reencode_string,
which will call strlen(3) on that buffer,
and discard the length of newly created buffer.
Then, we compute the length of the return buffer to attach to strbuf.
During this process, we introduce a discrimination between mail
originally written in utf-8 and other encoding.
* if the email was written in utf-8, we leave it as is. If there is
a NUL character in that line, we complains loudly:
error: a NUL byte in commit log message not allowed.
* if the email was written in other encoding, we truncate the data as
the NUL character in that line, then we used the truncated line for
the metadata.
We can do better by reusing all the available information,
and call the underlying lower level function that will be called
indirectly by reencode_string. By doing this, we will also postpone
the NUL character processing to the commit step, which will
complains about the faulty metadata.
Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-21 01:54:35 +02:00
|
|
|
"
|
|
|
|
|
2011-10-12 16:33:54 +02:00
|
|
|
test_done
|