All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Martin Ågren" <martin.agren@gmail.com>
Cc: git@vger.kernel.org, Jonathan Tan <jonathantanmy@google.com>
Subject: Re: [PATCH] t1450: fix quoting of NUL byte when corrupting pack
Date: Sat, 01 Aug 2020 17:45:11 -0700	[thread overview]
Message-ID: <xmqqmu3d27vs.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20200801220611.10453-1-martin.agren@gmail.com> ("Martin =?utf-8?Q?=C3=85gren=22's?= message of "Sun, 2 Aug 2020 00:06:11 +0200")

Martin Ågren <martin.agren@gmail.com> writes:

> We use
>
>   printf '\0'
>
> to generate a NUL byte which we then `dd` into the packfile to ensure
> that we modify the first byte of the first object, thereby
> (probabilistically) invalidating the checksum. Except the single quotes
> we're using are interpreted to match with the ones we enclose the whole
> test in. So we actually execute
>
>   printf \0
>
> and end up injecting the ASCII code for "0", 0x30, instead.
>
> The comment right above this `printf` invocation says that "at least one
> of [the type bits] is not zero, so setting the first byte to 0 is
> sufficient". Substituting "0x30" for "0" in that comment won't do: we'd
> need to reason about which bits go where and just what the packfile
> looks like that we're modifying in this test.
>
> Let's avoid all of that by actually executing
>
>   printf "\0"
>
> to generate a NUL byte, as intended.

Thanks.  Very well explained.

I wonder if it is an easy way to find similar problems without too
much hand-parsing of the test scripts.  Inside a modern test_expect_*
that begins and ends the test body with a single quote, any line
that has a single quote that is not quoted could be suspect, but
that would probably give us too many false positive.


> Signed-off-by: Martin Ågren <martin.agren@gmail.com>
> ---
>  If my reading is correct, when we substitute 0x30, the type will be 3
>  (blob) and the size will be zero. So there might actually exist
>  formally valid packfiles where this byte that we're modifying is
>  already zero. What matters in the end is whether we might be using such
>  a packfile in this exact test and from what I can tell, no, we won't be
>  doing that.
>
>  t/t1450-fsck.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
> index 344a2aad82..af2a2c4682 100755
> --- a/t/t1450-fsck.sh
> +++ b/t/t1450-fsck.sh
> @@ -714,7 +714,7 @@ test_expect_success 'fsck fails on corrupt packfile' '
>  	# at least one of which is not zero, so setting the first byte to 0 is
>  	# sufficient.)
>  	chmod a+w .git/objects/pack/pack-$pack.pack &&
> -	printf '\0' | dd of=.git/objects/pack/pack-$pack.pack bs=1 conv=notrunc seek=12 &&
> +	printf "\0" | dd of=.git/objects/pack/pack-$pack.pack bs=1 conv=notrunc seek=12 &&
>  
>  	test_when_finished "rm -f .git/objects/pack/pack-$pack.*" &&
>  	remove_object $hsh &&

  reply	other threads:[~2020-08-02  0:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-01 22:06 [PATCH] t1450: fix quoting of NUL byte when corrupting pack Martin Ågren
2020-08-02  0:45 ` Junio C Hamano [this message]
2020-08-02 14:30   ` Martin Ågren
2020-08-02 17:22     ` Eric Sunshine
2020-08-06 20:08     ` [PATCH v2 0/2] t: don't spuriously close and reopen quotes Martin Ågren
2020-08-06 20:08       ` [PATCH v2 1/2] " Martin Ågren
2020-08-06 20:26         ` Eric Sunshine
2020-08-07  8:45           ` Martin Ågren
2020-08-07 16:17             ` Eric Sunshine
2020-08-07 17:16               ` Junio C Hamano
2020-08-06 20:08       ` [PATCH v2 2/2] t4104: modernize and simplify quoting Martin Ågren
2020-08-02  1:00 ` [PATCH] t1450: fix quoting of NUL byte when corrupting pack Chris Torek
2020-08-02  1:02   ` Chris Torek
2020-08-02 14:35     ` Martin Ågren
2020-08-02 16:20       ` Chris Torek
2020-08-02 17:57         ` 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=xmqqmu3d27vs.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@google.com \
    --cc=martin.agren@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.