Subject: Re: [PATCH 04/10] unpack_loose_header(): fix infinite loop on broken zlib input

From: Patrick Steinhardt <[email-masked]>
Date: Tue, 25 Feb 2025 12:42:31 +0100

On Tue, Feb 25, 2025 at 01:29:58AM -0500, Jeff King wrote:
> diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
> index 398865d6eb..0b0d915773 100755
> --- a/t/t1006-cat-file.sh
> +++ b/t/t1006-cat-file.sh
> @@ -903,6 +903,25 @@ test_expect_success 'cat-file -t and -s on corrupt loose object' '
>  	)
>  '
>  
> +test_expect_success 'truncated object with --allow-unknown-type' - <<\EOT
> +	objtype='a really long type name that exceeds the 32-byte limit' &&
> +	blob=$(git hash-object -w --literally -t "$objtype" /dev/null) &&
> +	objpath=.git/objects/$(test_oid_to_path "$blob") &&
> +
> +	# We want to truncate the object far enough in that we don't hit the
> +	# end while inflating the first 32 bytes (since we want to have to dig
> +	# for the trailing NUL of the header). But we don't want to go too far,
> +	# since our header isn't very big. And of course we are counting
> +	# deflated zlib bytes in the on-disk file, so it's a bit of a guess.
> +	# Empirically 50 seems to work.
> +	mv "$objpath" obj.bak &&
> +	test_when_finished 'mv obj.bak "$objpath"' &&

The order should probably be reversed here, as we nowadays tend to first
queue the cleanup before doing the actual work. Not that it really
matters in this case.

Patrick