git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Jann Horn" <jannh@google.com>,
	git@vger.kernel.org, "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
	"Johannes Schindelin" <johannes.schindelin@gmx.de>,
	"Nicolas Pitre" <nico@fluxnic.net>
Subject: Re: [PATCH 2/5] t5303: test some corrupt deltas
Date: Thu, 30 Aug 2018 14:44:59 -0400	[thread overview]
Message-ID: <20180830184459.GC14273@sigill.intra.peff.net> (raw)
In-Reply-To: <20180830184201.GB14273@sigill.intra.peff.net>

On Thu, Aug 30, 2018 at 02:42:01PM -0400, Jeff King wrote:

> > Would "echo base >base" give us 5-byte long base even on Windows?
> > Or the test does not care if it is either "base\n" or "base\r\n"?
> > 
> > Just double-checking.
> 
> Good question. On the first one, I don't know. On the second one, yes,
> it does matter. We'd feed "6" to patch_delta(), and it would complain
> about the mismatch before actually hitting the code we're trying to
> exercise. The test would still pass (the error result is the same either
> way), but would quietly not test what we wanted.
> 
> Maybe something like this to be on the safe side?

That could be squashed into patch 2. Patch 4 would need this one
additional case:

diff --git a/t/t5303-pack-corruption-resilience.sh b/t/t5303-pack-corruption-resilience.sh
index 0c537958e7..e91d6f5770 100755
--- a/t/t5303-pack-corruption-resilience.sh
+++ b/t/t5303-pack-corruption-resilience.sh
@@ -379,7 +379,7 @@ test_expect_success \
     'printf "\0\1\1X\1" > tail_garbage_literal &&
      test_must_fail test-tool delta -p /dev/null tail_garbage_literal /dev/null'
 
-# \5 - five bytes in base
+# \4 - four bytes in base
 # \1 - one byte in result
 # \1 - one literal byte (X)
 # \221 - copy, one byte offset, one byte size
@@ -387,8 +387,8 @@ test_expect_success \
 #   \1 - copy 1 byte
 test_expect_success \
     'apply delta with trailing garbage copy' \
-    'printf "\5\1\1X\221\0\1" > tail_garbage_copy &&
-     echo base >base &&
+    'printf "\4\1\1X\221\0\1" > tail_garbage_copy &&
+     printf base >base &&
      test_must_fail test-tool delta -p /dev/null tail_garbage_copy /dev/null'
 
 # \0 - empty base

I can re-roll, or even prepare a patch on top (it's sufficiently subtle
that it may merit calling out explicitly in a commit).

-Peff

  reply	other threads:[~2018-08-30 18:45 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-29 20:58 [PATCH 1/3] patch-delta: fix oob read Jann Horn
2018-08-29 20:58 ` [PATCH 2/3] t/helper/test-delta: segfault on OOB access Jann Horn
2018-08-29 21:34   ` Jeff King
2018-08-29 21:40     ` Jann Horn
2018-08-29 21:46       ` Jeff King
2018-08-29 21:48         ` Jeff King
2018-08-29 20:58 ` [PATCH 3/3] t5303: add tests for corrupted deltas Jann Horn
2018-08-29 22:03   ` Jeff King
2018-08-29 22:30     ` Jeff King
2018-08-29 21:20 ` [PATCH 1/3] patch-delta: fix oob read Jeff King
2018-08-29 22:18   ` Jeff King
2018-08-30  7:05 ` [PATCH 0/5] handle corruption in patch-delta Jeff King
2018-08-30  7:07   ` [PATCH 1/5] test-delta: read input into a heap buffer Jeff King
2018-08-30  7:09   ` [PATCH 2/5] t5303: test some corrupt deltas Jeff King
2018-08-30 17:38     ` Junio C Hamano
2018-08-30 18:42       ` Jeff King
2018-08-30 18:44         ` Jeff King [this message]
2018-08-30 18:50           ` Junio C Hamano
2018-08-30 19:13             ` Jeff King
2018-08-31  9:58       ` Johannes Schindelin
2018-08-31 15:33         ` Junio C Hamano
2018-08-31 19:47           ` Jeff King
2018-08-31 21:39             ` Junio C Hamano
2018-08-31 21:14           ` Johannes Schindelin
2018-08-31 21:41             ` Jeff King
2018-08-31 21:55               ` Junio C Hamano
2018-08-30  7:09   ` [PATCH 3/5] patch-delta: fix oob read Jeff King
2018-08-30  7:10   ` [PATCH 4/5] patch-delta: consistently report corruption Jeff King
2018-08-30  7:12   ` [PATCH 5/5] patch-delta: handle truncated copy parameters Jeff King
2018-08-30 13:25   ` [PATCH 0/5] handle corruption in patch-delta Jann Horn
2018-08-30 15:23   ` Nicolas Pitre

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=20180830184459.GC14273@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jannh@google.com \
    --cc=johannes.schindelin@gmx.de \
    --cc=nico@fluxnic.net \
    --cc=pclouds@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).