On Sun, Jan 28, 2018 at 9:06 AM, brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > This series wires up an alternate hash implementation, namely > BLAKE2b-160. The goal is to allow us to identify tests which rely on > the hash algorithm in use so that we can fix those tests. > > 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); > * The API of the libb2 package easily allows arbitrary hash lengths, so > I didn't have to manage truncation myself; > * Our codebase isn't yet ready for a hash function larger than 20 bytes, > as there's still more work to do on the object_id conversions. > > 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. > > The first patch does no feature detection and just assumes you have > libb2 installed. For obvious reasons, this series is not meant for > production use. Thanks for writing this, I chose a slightly different approach at https://public-inbox.org/git/20170728171817.21458-2-sbeller@xxxxxxxxxx/ which might be quicker for local testing. Thanks for bringing this discussion back on the list, Stefan
