On Mon, Oct 15, 2018 at 04:59:12PM +0200, Duy Nguyen wrote:
> On Mon, Oct 15, 2018 at 4:23 AM brian m. carlson
> <sandals@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > 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?
In order to activate SHA-256 in the codebase, currently you need a patch
to force it on. Otherwise, the code is simply inert and does nothing
(other than in the test-tool). I've included the patch below so you can
see what it does (or if you want to play around with it).
Without this patch, Git remains fully SHA-1 and can't access any of the
SHA-256 code. I have some very preliminary patches that do wire up
extensions.objectFormat (branch object-id-part15 [sic]) but I haven't
picked them up in a while. (I need to finish test fixes first.)
Making the codebase run in SHA-256 mode with a Git that supports both
algorithms but defaults to SHA-1 is currently seriously broken, even
with the object-id-part15 branch. When those patches go in, they will
be behind a developer flag to prevent wholesale chaos and segfaults.
So in summary, no, I don't think a developer flag is necessary at this
point.
-- >% --
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 25 Jul 2018 23:48:30 +0000
Subject: [PATCH] Switch default hash algorithm to SHA-256 for testing
Set the default hash algorithm to SHA-256 for testing purposes.
This is a test commit and should not be used in production.
Signed-off-by: brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx>
---
repository.c | 2 +-
setup.c | 2 +-
t/test-lib-functions.sh | 4 +---
t/test-lib.sh | 13 ++++++++-----
4 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/repository.c b/repository.c
index 5dd1486718..4ce50ea670 100644
--- a/repository.c
+++ b/repository.c
@@ -17,7 +17,7 @@ void initialize_the_repository(void)
the_repo.objects = raw_object_store_new();
the_repo.parsed_objects = parsed_object_pool_new();
- repo_set_hash_algo(&the_repo, GIT_HASH_SHA1);
+ repo_set_hash_algo(&the_repo, GIT_HASH_SHA256);
}
static void expand_base_dir(char **out, const char *in,
diff --git a/setup.c b/setup.c
index b24c811c1c..2b4cc4e5a4 100644
--- a/setup.c
+++ b/setup.c
@@ -490,7 +490,7 @@ int read_repository_format(struct repository_format *format, const char *path)
memset(format, 0, sizeof(*format));
format->version = -1;
format->is_bare = -1;
- format->hash_algo = GIT_HASH_SHA1;
+ format->hash_algo = GIT_HASH_SHA256;
string_list_init(&format->unknown_extensions, 1);
git_config_from_file(check_repo_format, path, format);
return format->version;
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index dfa1bebb46..91cf2b9d40 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -1165,9 +1165,7 @@ test_set_hash () {
# Detect the hash algorithm in use.
test_detect_hash () {
- # Currently we only support SHA-1, but in the future this function will
- # actually detect the algorithm in use.
- test_hash_algo='sha1'
+ test_hash_algo='sha256'
}
# Load common hash metadata and common placeholder object IDs for use with
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 3f95bfda60..bb507f2d4f 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -176,18 +176,21 @@ esac
# Convenience
#
-# A regexp to match 5, 35 and 40 hexdigits
+# A regexp to match 4, 5, 35, 40, and 64 hexdigits
+_x04='[0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x05='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x35="$_x05$_x05$_x05$_x05$_x05$_x05$_x05"
_x40="$_x35$_x05"
+_x64="$_x40$_x05$_x05$_x05$_x05$_x04"
# Zero SHA-1
_z40=0000000000000000000000000000000000000000
+_z64=0000000000000000000000000000000000000000000000000000000000000000
-OID_REGEX="$_x40"
-ZERO_OID=$_z40
-EMPTY_TREE=4b825dc642cb6eb9a060e54bf8d69288fbee4904
-EMPTY_BLOB=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
+OID_REGEX="$_x64"
+ZERO_OID=$_z64
+EMPTY_TREE=6ef19b41225c5369f1c104d45d8d85efa9b057b53b14b4b9b939dd74decc5321
+EMPTY_BLOB=473a0f4c3be8a93681a267e3b1e9a7dcda1185436fe141f7749120a303721813
# Line feed
LF='
-- >% --
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
