> On 05 Jun 2017, at 21:15, Jeff King <p...@peff.net> wrote:
>
> Commit a1283866b (t5313: test bounds-checks of
> corrupted/malicious pack/idx files, 2016-02-25) added a test
> that requires our corrupted pack index to have two objects.
> The entry for the first one remains untouched, but we
> corrupt the entry for second one. Since the index stores the
> entries in sha1-sorted order, this means that the test must
> make sure that the sha1 of the object we expect to be
> corrupted ("$object") sorts after the other placeholder
> object.
>
> That commit used the HEAD commit as the placeholder, but the
> script never calls test_tick. That means that the commit
> object (and thus its sha1) depends on the timestamp when the
> test script is run. This usually works in practice, because
> the sha1 of $object starts with "fff". The commit object
> will sort after that only 1 in 4096 times, but when it does
> the test will fail.
>
> One obvious solution is to add the test_tick call to get a
> deterministic commit sha1. But since we're relying on the
> sort order for the test to function, let's make that very
> explicit by just generating a second blob with a known sha1.
Works for me! Thanks for the explanation!
- Lars
>
> Reported-by: Lars Schneider <larsxschnei...@gmail.com>
> Signed-off-by: Jeff King <p...@peff.net>
> ---
> t/t5313-pack-bounds-checks.sh | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/t/t5313-pack-bounds-checks.sh b/t/t5313-pack-bounds-checks.sh
> index a8a587abc..9372508c9 100755
> --- a/t/t5313-pack-bounds-checks.sh
> +++ b/t/t5313-pack-bounds-checks.sh
> @@ -139,7 +139,13 @@ test_expect_success 'bogus offset into v2 extended
> table' '
> test_expect_success 'bogus offset inside v2 extended table' '
> # We need two objects here, so we can plausibly require
> # an extended table (if the first object were larger than 2^31).
> - do_pack "$object $(git rev-parse HEAD)" --index-version=2 &&
> + #
> + # Note that the value is important here. We want $object as
> + # the second entry in sorted-sha1 order. The sha1 of 1485 starts
> + # with "000", which sorts before that of $object (which starts
> + # with "fff").
> + second=$(echo 1485 | git hash-object -w --stdin) &&
> + do_pack "$object $second" --index-version=2 &&
>
> # We have to make extra room for the table, so we cannot
> # just munge in place as usual.
> --
> 2.13.1.662.g6e89c999d
