When DC_SHA1 was made the default we missed a spot

Stop supplying BLK_SHA1=YesPlease when NO_OPENSSL=UnfortunatelyYes is supplied. This has been done ever since [1], when switching to DC_SHA1 by default in [2] this should have been changed as well.

Makefile +0 -2

@@ -23,7 +23,6 @@ all::
 # it at all).
 #
 # Define NO_OPENSSL environment variable if you do not have OpenSSL.
-# This also implies BLK_SHA1.
 #
 # Define USE_LIBPCRE if you have and want to use libpcre. Various
 # commands such as log and grep offer runtime options to use

@@ -1260,7 +1259,6 @@ ifndef NO_OPENSSL
 	endif
 else
 	BASIC_CFLAGS += -DNO_OPENSSL
-	BLK_SHA1 = 1
 	OPENSSL_LIBSSL =
 endif
 ifdef NO_OPENSSL

configure.ac +0 -0

index 2f55237e65..7f8415140f 100644

Quoted 3 lines · Ævar Arnfjörð Bjarmason

Stop supplying BLK_SHA1=YesPlease when NO_OPENSSL=UnfortunatelyYes is supplied. This has been done ever since [1], when switching to DC_SHA1 by default in [2] this should have been changed as well.

I had trouble parsing this, I think for a few reasons:

1. Too much 'this', so I end up not being able to keep track of what has been done ever since (1) and (2)

2. The ',' should be a ';'

3. Can the commit names go inline in the message instead of being footnotes? That way, my eye doesn't have to chase so far to find what kind of dates you are talking about.

4. Why should switching to DC_SHA1 by default have resulted in simply dropping the NO_OPENSSL => BLK_SHA1 behavior? At first glance it would be more intuitive to change it to NO_OPENSSL => DC_SHA1 instead.

Putting those all together, I end up with

Use the collision detecting SHA-1 implementation by default even when NO_OPENSSL is set.

Setting NO_OPENSSL=UnfortunatelyYes has implied BLK_SHA1=1 ever since the former was introduced in dd53c7ab29 (Support for NO_OPENSSL, 2005-07-29). That implication should have been removed when the default SHA-1 implementation changed from OpenSSL to DC_SHA1 in e6b07da278 (Makefile: make DC_SHA1 the default, 2017-03-17). Finish what that commit started by removing the BLK_SHA1 fallback setting so the default DC_SHA1 implementation can be used.

What happens if I set both OPENSSL_SHA1 and NO_OPENSSL? Should this block set

OPENSSL_SHA1 =

so that the latter wins, or should we detect it as an error?

[...]

Quoted 23 lines

Makefile +0 -2

@@ -23,7 +23,6 @@ all::
 # it at all).
 #
 # Define NO_OPENSSL environment variable if you do not have OpenSSL.
-# This also implies BLK_SHA1.
 #
 # Define USE_LIBPCRE if you have and want to use libpcre. Various
 # commands such as log and grep offer runtime options to use

@@ -1260,7 +1259,6 @@ ifndef NO_OPENSSL
 	endif
 else
 	BASIC_CFLAGS += -DNO_OPENSSL
-	BLK_SHA1 = 1
 	OPENSSL_LIBSSL =
 endif
 ifdef NO_OPENSSL

configure.ac +0 -0

index 2f55237e65..7f8415140f 100644

configure.ac AC_MSG_NOTICE([CHECKS for site configuration]) · line 244

Quoted 4 lines

configure.ac +0 -1

@@ -241,7 +241,6 @@ AC_MSG_NOTICE([CHECKS for site configuration])
 # a bundled SHA1 routine optimized for PowerPC.
 #
 # Define NO_OPENSSL environment variable if you do not have OpenSSL.
-# This also implies BLK_SHA1.

With or without some of those commit message tweaks

Reviewed-by Jonathan Nieder <[email protected]>

Use the collision detecting SHA-1 implementation by default even when NO_OPENSSL is set.

Setting NO_OPENSSL=UnfortunatelyYes has implied BLK_SHA1=1 ever since the former was introduced in dd53c7ab29 (Support for NO_OPENSSL, 2005-07-29). That implication should have been removed when the default SHA-1 implementation changed from OpenSSL to DC_SHA1 in e6b07da278 (Makefile: make DC_SHA1 the default, 2017-03-17). Finish what that commit started by removing the BLK_SHA1 fallback setting so the default DC_SHA1 implementation will be used.

Signed-off-by Ævar Arnfjörð Bjarmason <[email protected]>

Reviewed-by Jonathan Nieder <[email protected]>

Using BLK_SHA1 in lieu of the OpenSSL routines was done in 9bccfcdbff ("Windows: use BLK_SHA1 again", 2009-10-22), since DC_SHA1 is now the default for git in general it makes sense for Windows to use that too, this looks like something that was missed back in e6b07da278 ("Makefile: make DC_SHA1 the default", 2017-03-17).

Using BLK_SHA1 in lieu of the OpenSSL routines was done in 9bccfcdbff ("Windows: use BLK_SHA1 again", 2009-10-22), since DC_SHA1 is now the default for git in general it makes sense for Windows to use that too, this looks like something that was missed back in e6b07da278 ("Makefile: make DC_SHA1 the default", 2017-03-17).

As noted in 2cfc70f0de ("mingw: use OpenSSL's SHA-1 routines", 2017-02-09) OpenSSL has a performance benefit compared to BLK_SHA1 on MinGW, so perhaps that and the Windows default should be changed around again. That's a topic for another series, it seems clear that this specific flag is nobody's explicit intention.

Reviewed-by Jonathan Nieder <[email protected]>

Signed-off-by Ævar Arnfjörð Bjarmason <[email protected]>

---
 config.mak.uname | 1 -
 1 file changed, 1 deletion(-)

config.mak.uname +0 -0

index 685a80d138..6a862abd35 100644

Hi,

Quoted 23 lines · Ævar Arnfjörð Bjarmason

Using BLK_SHA1 in lieu of the OpenSSL routines was done in 9bccfcdbff ("Windows: use BLK_SHA1 again", 2009-10-22), since DC_SHA1 is now the default for git in general it makes sense for Windows to use that too, this looks like something that was missed back in e6b07da278 ("Makefile: make DC_SHA1 the default", 2017-03-17).

As noted in 2cfc70f0de ("mingw: use OpenSSL's SHA-1 routines", 2017-02-09) OpenSSL has a performance benefit compared to BLK_SHA1 on MinGW, so perhaps that and the Windows default should be changed around again. That's a topic for another series, it seems clear that this specific flag is nobody's explicit intention.

Reviewed-by Jonathan Nieder <[email protected]>

Signed-off-by Ævar Arnfjörð Bjarmason <[email protected]>

---
 config.mak.uname | 1 -
 1 file changed, 1 deletion(-)

config.mak.uname +0 -0

index 685a80d138..6a862abd35 100644

config.mak.uname ifeq ($(uname_S),Windows) · line 366

Quoted 7 lines

config.mak.uname +0 -1

@@ -361,7 +361,6 @@ ifeq ($(uname_S),Windows)
 	NO_REGEX = YesPlease
 	NO_GETTEXT = YesPlease
 	NO_PYTHON = YesPlease
-	BLK_SHA1 = YesPlease
 	ETAGS_TARGET = ETAGS
 	NO_INET_PTON = YesPlease
 	NO_INET_NTOP = YesPlease

This patch is actually identical to 8756c75cd10 (msvc: use OpenSSL's SHA-1 routines, 2016-10-12) in Git for Windows' master.

I did plan to submit this, but it is part of a bigger effort to get Git to build in current versions of Visual Studio again.

Before this work, the MSVC build could only use an ancient OpenSSL version from pre-built binaries hosted on repo.or.cz, and those are unlikely to get the performance benefits that you seek.

So I would like to ask to skip this patch for now, and take Jeff Hostetler's patch as part of the MSVC patches later, once they have been matured in Git for Windows?

Quoted 3 lines

So I would like to ask to skip this patch for now, and take Jeff Hostetler's patch as part of the MSVC patches later, once they have been matured in Git for Windows?

Sounds good to me. Junio, could you please drop this one and just take 1/2?

Using BLK_SHA1 in lieu of the OpenSSL routines was done in [1], but since DC_SHA1 is now the default for git in general it makes sense for Windows to use that too, this looks like something that was missed back in [2].

As noted in [3] OpenSSL has a performance benefit compared to BLK_SHA1 on MinGW, so perhaps that and the Windows default should be changed around again, but that's a topic for another series, it seems clear that this specific flag is nobody's explicit intention.

config.mak.uname +0 -1

@@ -361,7 +361,6 @@ ifeq ($(uname_S),Windows)
 	NO_REGEX = YesPlease
 	NO_GETTEXT = YesPlease
 	NO_PYTHON = YesPlease
-	BLK_SHA1 = YesPlease
 	ETAGS_TARGET = ETAGS
 	NO_INET_PTON = YesPlease
 	NO_INET_NTOP = YesPlease

+git-for-windows

Quoted 9 lines · Ævar Arnfjörð Bjarmason

Using BLK_SHA1 in lieu of the OpenSSL routines was done in [1], but since DC_SHA1 is now the default for git in general it makes sense for Windows to use that too, this looks like something that was missed back in [2].

As noted in [3] OpenSSL has a performance benefit compared to BLK_SHA1 on MinGW, so perhaps that and the Windows default should be changed around again, but that's a topic for another series, it seems clear that this specific flag is nobody's explicit intention.

I have some memory of performance issues on Windows when DC_SHA1 was introduced leading to interest in a mixed configuration with DC_SHA1 only being used where it is security sensitive (e.g. for object naming but not for packfile trailers).

Did anything come of that?

In any event removing this BLK_SHA1 setting looks like a good change to me, but I'd rather that Windows folks weigh in.

Thanks,
Jonathan

[...]

Quoted 10 lines

config.mak.uname +0 -1

@@ -361,7 +361,6 @@ ifeq ($(uname_S),Windows)
 	NO_REGEX = YesPlease
 	NO_GETTEXT = YesPlease
 	NO_PYTHON = YesPlease
-	BLK_SHA1 = YesPlease
 	ETAGS_TARGET = ETAGS
 	NO_INET_PTON = YesPlease
 	NO_INET_NTOP = YesPlease

On Wed, Dec 27 2017, Jonathan Nieder jotted:

Quoted 18 lines

+git-for-windows

Quoted 9 lines · Ævar Arnfjörð Bjarmason

Using BLK_SHA1 in lieu of the OpenSSL routines was done in [1], but since DC_SHA1 is now the default for git in general it makes sense for Windows to use that too, this looks like something that was missed back in [2].

As noted in [3] OpenSSL has a performance benefit compared to BLK_SHA1 on MinGW, so perhaps that and the Windows default should be changed around again, but that's a topic for another series, it seems clear that this specific flag is nobody's explicit intention.

I have some memory of performance issues on Windows when DC_SHA1 was introduced leading to interest in a mixed configuration with DC_SHA1 only being used where it is security sensitive (e.g. for object naming but not for packfile trailers).

Quoted 1 line

Did anything come of that?

This was Johannes Schindelin (CC'd) on-list when the sha1dc discussion first came up earlier this year. I.e. it's slower, so we could use openssl on trusted data and sha1dc on untrusted data, but nothing came of that.