| Message ID | 20201126012854.399-6-avarab@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC/PATCH,01/12] mktag: use default strbuf_read() hint | expand |
On Thu, Nov 26, 2020 at 02:28:47AM +0100, Ævar Arnfjörð Bjarmason wrote: > But here we're testing for a SHA-length string which contains > characters outside of the /[0-9a-f]/i set. Let's just do that with a > ROT13 invocation. > > We could get really unlucky and switch to a future hash function that > just happens to produce all [0-9] output for this particular input, > but that's very unlikely. Maybe s/[0-9a-f]/z/ would be both simpler and more robust? -Peff
diff --git a/t/t3800-mktag.sh b/t/t3800-mktag.sh index 0e411e3c45..b5013af2aa 100755 --- a/t/t3800-mktag.sh +++ b/t/t3800-mktag.sh @@ -43,7 +43,7 @@ check_verify_failure 'Tag object length check' \ # 2. object line label check cat >tag.sig <<EOF -xxxxxx 139e9b33986b1c2670fff52c5067603117b3e895 +xxxxxx $head type tag tag mytag tagger . <> 0 +0000 @@ -53,10 +53,11 @@ EOF check_verify_failure '"object" line label check' '^error: char0: .*"object "$' ############################################################ -# 3. object line SHA1 check +# 3. object line SHA check +invalid_sha=$(echo $head | tr A-Za-z N-ZA-Mn-za-m) cat >tag.sig <<EOF -object zz9e9b33986b1c2670fff52c5067603117b3e895 +object $invalid_sha type tag tag mytag tagger . <> 0 +0000
Change the tests amended in acb49d1cc8b (t3800: make hash-size independent, 2019-08-18) even more to make them independent of either SHA-1 or SHA-256. Some of these tests were failing for the wrong reasons. The first one being modified here would fail because the line starts with "xxxxxx" instead of "object", the rest of the line doesn't matter. Let's just put a valid hash on the rest of the line anyway to narrow the test down for just the s/object/xxxxxx/ case. The second one being modified here would fail under GIT_TEST_DEFAULT_HASH=sha256 because <some sha-1 length garbage> is an invalid SHA-256, but we should really be testing <some sha-256 length garbage> when under SHA-256. This doesn't really matter since we should be able to trust other parts of the code to validate things in the 0-9a-f range, but let's do it for good measure. There's a later test which tests an invalid SHA which looks like a valid one, to stress the "We refuse to tag something we can't verify[...]" logic in mktag.c. But here we're testing for a SHA-length string which contains characters outside of the /[0-9a-f]/i set. Let's just do that with a ROT13 invocation. We could get really unlucky and switch to a future hash function that just happens to produce all [0-9] output for this particular input, but that's very unlikely. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- t/t3800-mktag.sh | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)