Re: [RFC PATCH 0/2] alternate hash test

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jan 28, 2018, 18:58 UTC
Message-ID: <CACBZZX4TRuPV8j9XV=8gAMirQNTpEJBO8bmE9KBnnmoJ7b_m1g@mail.gmail.com>
In-Reply-To: <20180128170639.216397-1-sandals@crustytoothpaste.net>

On Sun, Jan 28, 2018 at 6:06 PM, brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 10 quoted lines

> For this test, I picked BLAKE2b-160 for a couple reasons:
> * Debian ships a libb2-1 package which can be used easily (in other
>   words, I was lazy and didn't want to add a crypto implementation just
>   for test purposes);
> [...]
> This isn't an endorsement for or against any particular algorithm
> choice, just an artifact of the tools that were easily available to me.
> Provoking discussion of which hash to pick for NewHash is explicitly
> *not* a goal for this series.  I'm only interested in the ability to
> identify and fix tests.

If the goal is to smoke out hardcoded SHA1s in tests, isn't it easier to instrument SHA-1 (e.g. our blk_sha1 copy, or our wrappers) to pretend that whenever we ask for the hash for STRING to pretend we asked for SOME_PREFIX + STRING?

Such an approach would have the advantage of being more portable (easier to run these mock test), and also that if we ever move to NewHash we could still test for this, we'd just always set the prefix to compilation time(), and could thus guarantee that the hashes would change every time git was built.