Re: [PATCH 00/10] Hash-independent tests (part 1)

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 27, 2018, 14:40 UTC
Message-ID: <nycvar.QRO.7.76.6.1803271630210.77@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
In-Reply-To: <xmqq8tafe92r.fsf@gitster-ct.c.googlers.com>

Hi Junio,

On Sun, 25 Mar 2018, Junio C Hamano wrote:

Show 15 quoted lines

> Eric Sunshine <sunshine@sunshineco.com> writes:
> 
> > What's the plan for oddball cases such as 66ae9a57b8 (t3404: rebase
> > -i: demonstrate short SHA-1 collision, 2013-08-23) which depend
> > implicitly upon SHA-1 without actually hardcoding any hashes? The test
> > added by 66ae9a57b8, for instance, won't start failing in the face of
> > NewHash, but it also won't be testing anything meaningful.
> >
> > Should such tests be dropped altogether? Should they be marked with a
> > 'SHA1' predicate or be annotated with a comment as being
> > SHA-1-specific? Something else?
> 
> Ideally, the existing one be annotated with prereq SHA1, and also
> duplicated with a tweak to cause the same kind of (half-)collision
> under the NewHash and be annotated with prereq NewHash.

That's a good idea. I wonder whether we want to be a bit more specific, though, so that we have something grep'able for the future? Something like SHA1_SHORT_COLLISION or some such?

> It's a different matter how feasible it is to attain such an ideal,
> though.  t1512 was fun to write, but it was quite a lot of work to
> come up with bunch of blobs, trees and commits whose object names
> share the common prefix 0{10}.

Did you write a helper to brute-force those? If so, we might want to have such a helper in t/helper/ to generate/re-generate those (i.e. it could be asked to generate a blob whose ID starts with five NUL bytes, and it would have hard-coded values for already-generated ones). Even if you did not write such a helper, we might want to have such a helper. That would take the responsibility away from the shell script.

Ciao, Dscho