[PATCH] Makefile: use sha1collisiondetection by default on OSX and Darwin

[PATCH] Makefile: use sha1collisiondetection by default on OSX and Darwin

[Ævar Arnfjörð Bjarmason]

When the sha1collisiondetection library was added and made the default
in [1] the interaction with APPLE_COMMON_CRYPTO added in [2] and [3]
seems to have been missed. On modern OSX and Darwin we are able to use
Apple's CommonCrypto both for SHA-1, and as a generic (but partial)
OpenSSL replacement.

This left OSX and Darwin without protection against the SHAttered
attack when building Git in its default configuration.

Let's also use sha1collisiondetection on OSX, to do so we'll need to
split up the "APPLE_COMMON_CRYPTO" flag into that flag and a new
"APPLE_COMMON_CRYPTO_SHA1".

Let's also change the CI for "osx-clang" to test with the new
APPLE_COMMON_CRYPTO_SHA1 knob ("osx-gcc" uses the new
sha1collisiondetection default).

In practice this will spot issues like the one noted in [4], as
testing with just two backends should be enough to spot unportable
code. Ideally we'd have other CI jobs to test the various SHA-1
combinations, but for now we have better CI coverage than before.

1. e6b07da2780 (Makefile: make DC_SHA1 the default, 2017-03-17)
2. 4dcd7732db0 (Makefile: add support for Apple CommonCrypto facility, 2013-05-19)
3. 61067954ce1 (cache.h: eliminate SHA-1 deprecation warnings on Mac OS X, 2013-05-19)
4. 32205655dc7 (fsmonitor OSX: compile with DC_SHA1=YesPlease, 2022-10-19)

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---

The 1st hunk here depends on the "base" topic which prepares the docs
for this small change:
https://lore.kernel.org/git/cover-v3-0.9-00000000000-20221020T223946Z-avarab@gmail.com/

But otherwise this applies on "master".

Junio: I see in the meantime you've queued your own
https://lore.kernel.org/git/cover-v3-0.9-00000000000-20221020T223946Z-avarab@gmail.com/;
which is currently in "seen".

That patch will merge smoothly with this one, both textually and
semantically, but if we have this it's all that's needed to flip the
default and give us pretty much the same OSX CI coverage.

"Pretty much" because an unstated effect of your patch is to disable
all use of the "Apple Common Crypto" library on "osx-clang", which
includes (but is not limited to) giving us another SHA-1 backend.

Range-diff:
1:  392fabdb456 < -:  ----------- fsmonitor OSX: compile with DC_SHA1=YesPlease
2:  7ae22276aa7 < -:  ----------- Makefile: create and use sections for "define" flag listing
3:  78ef8636c57 < -:  ----------- Makefile: really use and document sha1collisiondetection by default
4:  f1fb9775b33 < -:  ----------- Makefile: rephrase the discussion of *_SHA1 knobs
-:  ----------- > 1:  1f4e39be97b Makefile: use sha1collisiondetection by default on OSX and Darwin

 Makefile  | 10 ++++------
 ci/lib.sh |  3 +++
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Makefile b/Makefile
index 36d6bffd1f1..fb4f240e28b 100644
--- a/Makefile
+++ b/Makefile
@@ -529,10 +529,8 @@ include shared.mak
 # Define BLK_SHA1 to make use of optimized C SHA-1 routines bundled
 # with git (in the block-sha1/ directory).
 #
-# Define NO_APPLE_COMMON_CRYPTO on OSX to opt-out of using the
-# "APPLE_COMMON_CRYPTO" backend for SHA-1, which is currently the
-# default on that OS. We'll define NO_APPLE_COMMON_CRYPTO on Mac OS
-# 10.4 or older ("Tiger", released in early 2005).
+# Define APPLE_COMMON_CRYPTO_SHA1 to use Apple's CommonCrypto for
+# SHA-1.
 #
 # === SHA-256 backend ===
 #
@@ -1873,7 +1871,7 @@ ifdef NO_POSIX_GOODIES
 	BASIC_CFLAGS += -DNO_POSIX_GOODIES
 endif
 
-ifdef APPLE_COMMON_CRYPTO
+ifdef APPLE_COMMON_CRYPTO_SHA1
 	# Apple CommonCrypto requires chunking
 	SHA1_MAX_BLOCK_SIZE = 1024L*1024L*1024L
 endif
@@ -1890,7 +1888,7 @@ ifdef BLK_SHA1
 	LIB_OBJS += block-sha1/sha1.o
 	BASIC_CFLAGS += -DSHA1_BLK
 else
-ifdef APPLE_COMMON_CRYPTO
+ifdef APPLE_COMMON_CRYPTO_SHA1
 	COMPAT_CFLAGS += -DCOMMON_DIGEST_FOR_OPENSSL
 	BASIC_CFLAGS += -DSHA1_APPLE
 else
diff --git a/ci/lib.sh b/ci/lib.sh
index 1b0cc2b57db..fda7e008f26 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -264,6 +264,9 @@ macos-latest)
 esac
 
 case "$jobname" in
+osx-clang)
+	MAKEFLAGS="$MAKEFLAGS APPLE_COMMON_CRYPTO_SHA1=Yes"
+	;;
 linux32)
 	CC=gcc
 	;;
-- 
2.38.0.1178.g509f5fa8ce0

Re: [PATCH] Makefile: use sha1collisiondetection by default on OSX and Darwin

[Junio C Hamano]

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

> Junio: I see in the meantime you've queued your own
> https://lore.kernel.org/git/cover-v3-0.9-00000000000-20221020T223946Z-avarab@gmail.com/;
> which is currently in "seen".

Yes, as I said, I intend to merge it to 'next' in tomorrow's
pushout, and then fast track all three topics (Peff's "-O0",
Eric/Ævar's "use git_SHA_CTX abstraction", and "osx-clan uses
sha1dc") down to 'master'.  As you chose to make this topic hostage
to the other multi-part topic, which is likely to be slowed down and
require rerolls for typofixes and possible bikeshedding, by the time
this topic becomes ready, it is likely that it would already be in
'master' and you'd have to rebase on that.

Isn't this step of much higher importance than the other multi-part
topic?  I do not see why you chose to take it a hostage to the other
one.  Let's all learn to give priorities to produce sufficiently
focused fixes that also sufficiently cover important issues.  Frills
and niceties can come on top later.

Re: [PATCH] Makefile: use sha1collisiondetection by default on OSX and Darwin

[Ævar Arnfjörð Bjarmason]

On Thu, Oct 20 2022, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
>
>> Junio: I see in the meantime you've queued your own
>> https://lore.kernel.org/git/cover-v3-0.9-00000000000-20221020T223946Z-avarab@gmail.com/;
>> which is currently in "seen".

[B.t.w. that link is wrong, I meant
https://lore.kernel.org/git/xmqq35bitooc.fsf@gitster.g/]

> Yes, as I said, I intend to merge it to 'next' in tomorrow's
> pushout, and then fast track all three topics (Peff's "-O0",
> Eric/Ævar's "use git_SHA_CTX abstraction", and "osx-clan uses
> sha1dc") down to 'master'.  As you chose to make this topic hostage
> to the other multi-part topic, which is likely to be slowed down and
> require rerolls for typofixes and possible bikeshedding, by the time
> this topic becomes ready, it is likely that it would already be in
> 'master' and you'd have to rebase on that.
>
> Isn't this step of much higher importance than the other multi-part
> topic?  I do not see why you chose to take it a hostage to the other
> one.  Let's all learn to give priorities to produce sufficiently
> focused fixes that also sufficiently cover important issues.  Frills
> and niceties can come on top later.

I don't see why we're in any rush to get this change down to "master"
(either this [1], or the base [2]), nor your jc/ci-osx-with-sha1dc[3].

Your list in [4] has two fixes for issues on "master" which we should
get there sooner than later.

But the 3rd is just addressing a CI blind spot that we've had for at
least 2 years, and since 2017 if we're talking about the default SHA-1
backend on OSX.

Yes, we had some unportable code sneak in recently, but there's no
reason I can see for why we'd expect that to happen tomorrow. It's been
one such issue from 2017 until now, so at this rate we should expect the
next one in 2027, not next week :)

In any case, I figured you might want to fast-track it anyway, or
whatever, which is why I crafted this series to give you easy options
given your [4]. Namely (and in no particular order):

A. You can queue the base topic[2] and this [1] on top of "seen" and
   your jc/ci-osx-with-sha1dc and they won't conflict.

B. This applies directly on "master" if you peel off the first hunk. If
   you wanted this faster than the "doc" change it could be queued like
   that, and we could fix the docs later.

C. You could eject your [3] and we could let this simmer at the normal
   rate, but that's assuming the "no rush" outlined above.

D. You could proceed with your [3], and I can eventually rebase on top
   of it (we'll probably want to undo the nothing-to-do-with-SHA-1
   change, presumably?)

E. You don't need to pick this up at all at this time. Nothing's broken
   now that hasn't been broken for the years by us not using DC_SHA1 on
   OSX by default.

1. https://lore.kernel.org/git/patch-1.1-1f4e39be97b-20221020T225305Z-avarab@gmail.com/
2. https://lore.kernel.org/git/cover-v3-0.9-00000000000-20221020T223946Z-avarab@gmail.com/
3. https://lore.kernel.org/git/xmqq35bitooc.fsf@gitster.g/
4. https://lore.kernel.org/git/xmqqtu3yqhm2.fsf@gitster.g/

[PATCH v2] Makefile: use sha1collisiondetection by default on OSX and Darwin

[Ævar Arnfjörð Bjarmason]

When the sha1collisiondetection library was added and made the default
in [1] the interaction with APPLE_COMMON_CRYPTO added in [2] and [3]
seems to have been missed. On modern OSX and Darwin we are able to use
Apple's CommonCrypto both for SHA-1, and as a generic (but partial)
OpenSSL replacement.

This left OSX and Darwin without protection against the SHAttered
attack when building Git in its default configuration.

Let's also use sha1collisiondetection on OSX, to do so we'll need to
split up the "APPLE_COMMON_CRYPTO" flag into that flag and a new
"APPLE_COMMON_CRYPTO_SHA1".

Because of this we can stop conflating whether we want to use Apple's
CommonCrypto at all, and whether we want to use it for SHA-1.  This
makes the CI recipe added in [4] simpler.

1. e6b07da2780 (Makefile: make DC_SHA1 the default, 2017-03-17)
2. 4dcd7732db0 (Makefile: add support for Apple CommonCrypto facility, 2013-05-19)
3. 61067954ce1 (cache.h: eliminate SHA-1 deprecation warnings on Mac OS X, 2013-05-19)
4. 1ad5c3df35a (ci: use DC_SHA1=YesPlease on osx-clang job for CI,
   2022-10-20)

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
Range-diff against v1:
1:  1f4e39be97b ! 1:  3de7cdbd260 Makefile: use sha1collisiondetection by default on OSX and Darwin
    @@ Commit message
         split up the "APPLE_COMMON_CRYPTO" flag into that flag and a new
         "APPLE_COMMON_CRYPTO_SHA1".
     
    -    Let's also change the CI for "osx-clang" to test with the new
    -    APPLE_COMMON_CRYPTO_SHA1 knob ("osx-gcc" uses the new
    -    sha1collisiondetection default).
    -
    -    In practice this will spot issues like the one noted in [4], as
    -    testing with just two backends should be enough to spot unportable
    -    code. Ideally we'd have other CI jobs to test the various SHA-1
    -    combinations, but for now we have better CI coverage than before.
    +    Because of this we can stop conflating whether we want to use Apple's
    +    CommonCrypto at all, and whether we want to use it for SHA-1.  This
    +    makes the CI recipe added in [4] simpler.
     
         1. e6b07da2780 (Makefile: make DC_SHA1 the default, 2017-03-17)
         2. 4dcd7732db0 (Makefile: add support for Apple CommonCrypto facility, 2013-05-19)
         3. 61067954ce1 (cache.h: eliminate SHA-1 deprecation warnings on Mac OS X, 2013-05-19)
    -    4. 32205655dc7 (fsmonitor OSX: compile with DC_SHA1=YesPlease, 2022-10-19)
    +    4. 1ad5c3df35a (ci: use DC_SHA1=YesPlease on osx-clang job for CI,
    +       2022-10-20)
     
         Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
     
    @@ Makefile: include shared.mak
      #
     -# Define NO_APPLE_COMMON_CRYPTO on OSX to opt-out of using the
     -# "APPLE_COMMON_CRYPTO" backend for SHA-1, which is currently the
    --# default on that OS. We'll define NO_APPLE_COMMON_CRYPTO on Mac OS
    --# 10.4 or older ("Tiger", released in early 2005).
    +-# default on that OS. On macOS 01.4 (Tiger) or older,
    +-# NO_APPLE_COMMON_CRYPTO is defined by default.
     +# Define APPLE_COMMON_CRYPTO_SHA1 to use Apple's CommonCrypto for
     +# SHA-1.
      #
    - # === SHA-256 backend ===
    - #
    + # If don't enable any of the *_SHA1 settings in this section, Git will
    + # default to its built-in sha1collisiondetection library, which is a
     @@ Makefile: ifdef NO_POSIX_GOODIES
      	BASIC_CFLAGS += -DNO_POSIX_GOODIES
      endif
    @@ Makefile: ifdef BLK_SHA1
      else
     
      ## ci/lib.sh ##
    -@@ ci/lib.sh: macos-latest)
    - esac
    - 
    - case "$jobname" in
    -+osx-clang)
    -+	MAKEFLAGS="$MAKEFLAGS APPLE_COMMON_CRYPTO_SHA1=Yes"
    -+	;;
    - linux32)
    - 	CC=gcc
    +@@ ci/lib.sh: macos-*)
    + 		MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=$(which python3)"
    + 	else
    + 		MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=$(which python2)"
    +-		MAKEFLAGS="$MAKEFLAGS NO_APPLE_COMMON_CRYPTO=NoThanks"
    +-		MAKEFLAGS="$MAKEFLAGS NO_OPENSSL=NoThanks"
    ++		MAKEFLAGS="$MAKEFLAGS APPLE_COMMON_CRYPTO_SHA1=Yes"
    + 	fi
      	;;
    + esac

 Makefile  | 10 ++++------
 ci/lib.sh |  3 +--
 2 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/Makefile b/Makefile
index 0f7d7ab1fd2..db447d07383 100644
--- a/Makefile
+++ b/Makefile
@@ -511,10 +511,8 @@ include shared.mak
 # Define BLK_SHA1 to make use of optimized C SHA-1 routines bundled
 # with git (in the block-sha1/ directory).
 #
-# Define NO_APPLE_COMMON_CRYPTO on OSX to opt-out of using the
-# "APPLE_COMMON_CRYPTO" backend for SHA-1, which is currently the
-# default on that OS. On macOS 01.4 (Tiger) or older,
-# NO_APPLE_COMMON_CRYPTO is defined by default.
+# Define APPLE_COMMON_CRYPTO_SHA1 to use Apple's CommonCrypto for
+# SHA-1.
 #
 # If don't enable any of the *_SHA1 settings in this section, Git will
 # default to its built-in sha1collisiondetection library, which is a
@@ -1911,7 +1909,7 @@ ifdef NO_POSIX_GOODIES
 	BASIC_CFLAGS += -DNO_POSIX_GOODIES
 endif
 
-ifdef APPLE_COMMON_CRYPTO
+ifdef APPLE_COMMON_CRYPTO_SHA1
 	# Apple CommonCrypto requires chunking
 	SHA1_MAX_BLOCK_SIZE = 1024L*1024L*1024L
 endif
@@ -1928,7 +1926,7 @@ ifdef BLK_SHA1
 	LIB_OBJS += block-sha1/sha1.o
 	BASIC_CFLAGS += -DSHA1_BLK
 else
-ifdef APPLE_COMMON_CRYPTO
+ifdef APPLE_COMMON_CRYPTO_SHA1
 	COMPAT_CFLAGS += -DCOMMON_DIGEST_FOR_OPENSSL
 	BASIC_CFLAGS += -DSHA1_APPLE
 else
diff --git a/ci/lib.sh b/ci/lib.sh
index 706e3ba7e93..db7105e8a8d 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -258,8 +258,7 @@ macos-*)
 		MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=$(which python3)"
 	else
 		MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=$(which python2)"
-		MAKEFLAGS="$MAKEFLAGS NO_APPLE_COMMON_CRYPTO=NoThanks"
-		MAKEFLAGS="$MAKEFLAGS NO_OPENSSL=NoThanks"
+		MAKEFLAGS="$MAKEFLAGS APPLE_COMMON_CRYPTO_SHA1=Yes"
 	fi
 	;;
 esac
-- 
2.39.0.rc2.1048.g0e5493b8d5b

Re: [PATCH v2] Makefile: use sha1collisiondetection by default on OSX and Darwin

[Junio C Hamano]

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

> Let's also use sha1collisiondetection on OSX, to do so we'll need to
> split up the "APPLE_COMMON_CRYPTO" flag into that flag and a new
> "APPLE_COMMON_CRYPTO_SHA1".

That's well reasoned

This leaves these in Makefile:

        # Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X
        # and do not want to use Apple's CommonCrypto library.  This allows you
        # to provide your own OpenSSL library, for example from MacPorts.

        ifndef NO_APPLE_COMMON_CRYPTO
                NO_OPENSSL = YesPlease
                APPLE_COMMON_CRYPTO = YesPlease
                COMPAT_CFLAGS += -DAPPLE_COMMON_CRYPTO
        endif

Because we only mention what it does to use NO_APPLE_COMMON_CRYPTO
here, without promising anything about what happens otherwise, we
can do this change without breaking any promises ;-)

However there is this bit:

        ifdef APPLE_COMMON_CRYPTO
                LIB_4_CRYPTO += -framework Security -framework CoreFoundation
        endif

So, if one says 

    make NO_APPLE_COMMON_CRYPTO=NoThanks APPLE_COMMON_CRYPTO_SHA1=YesPlease

presumably the end result will fail to link?  I _think_ that falls
into "if it hurts, don't do that", and 

 (1) automatically disabling the latter when the former is set would
     be more confusing than helpful.

 (2) explicitly detecting the situation and issue an error message
     from the Makefile might appear nicer, but if the linker does
     the failing with a messaage fine, that would be sufficient.

so in the end, the posted patch as-is should be fine, I think.