Re: [PATCH v2 10/13] Add a base implementation of SHA-256 support

From: Duy Nguyen <pclouds@gmail.com>
Date: Oct 15, 2018, 14:59 UTC
Message-ID: <CACsJy8AOu-SdLu+MQKOzVLEy0SM0r45TjwZYkD_S5W756hWRpw@mail.gmail.com>
In-Reply-To: <20181015021900.1030041-11-sandals@crustytoothpaste.net>

 On Mon, Oct 15, 2018 at 4:23 AM brian m. carlson
<sandals@crustytoothpaste.net> wrote:

Show 17 quoted lines

>
> SHA-1 is weak and we need to transition to a new hash function.  For
> some time, we have referred to this new function as NewHash.  Recently,
> we decided to pick SHA-256 as NewHash.
>
> Add a basic implementation of SHA-256 based off libtomcrypt, which is in
> the public domain.  Optimize it and restructure it to meet our coding
> standards.  Place it in a directory called "sha256" where it and any
> future implementations can live so as to avoid a proliferation of
> implementation directories.
>
> Wire up SHA-256 in the list of hash algorithms, and add a test that the
> algorithm works correctly.
>
> Note that with this patch, it is still not possible to switch to using
> SHA-256 in Git.  Additional patches are needed to prepare the code to
> handle a larger hash algorithm and further test fixes are needed.

At some point I assume SHA-256 will become functional and be part of a git release without all file formats updated to support multiple hashes. Should we somehow discourage the user from using it because it will break when all file formats are finally updated?

The simplest way is to just not register "sha256" in hash_algos unless some developer flag is set. Or rename sha256 to sha256-experimental or something to make it more obvious (but then we may need to fix up the test suite after renaming it back to sha256, not great)

-- 
Duy