Re: Combining APPLE_COMMON_CRYPTO=1 and NO_OPENSSL=1 produces unexpected result

[David Aguilar <davvid@gmail.com>]

On Sun, Dec 27, 2015 at 06:29:29PM -0800, Junio C Hamano wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
> 
> > So, it might be easier to think of NO_OPENSSL as really meaning NO_SSL
> > (that is, "disable all SSL-related functionality"). Since the only SSL
> > implementation Git knows how to use is OpenSSL, perhaps one can
> > consider the name NO_OPENSSL a historic anomaly.
> 
> That is a good explanation of what is observed.  I am not sure if it
> is a good justification, though.  If you tell somebody who needs to
> link an implementation of SHA-1 in that you (1) do not want to use
> OpenSSL (or do not want to have SSL at all), and (2) do not mind
> using Apple's CommonCrypto, and if you _know_ that CommonCrypto is
> a possible source of the SHA-1 implementation, then I would think it
> is reasonable to expect that CommonCrypto SHA-1 to be used.
> 
> 	Note. To further explain the situation, the only reason we
> 	added CommonCrypto knob in the build system was to allow
> 	people to use OpenSSL as the SSL implementation.  Those who
> 	added the knob weren't making a conscious decision on which
> 	SHA-1 implementation to use in that scenario---they may not
> 	even have been aware of the fact that SHA-1 was offered by
> 	CommonCrypto for that matter.

My original motivation for going down the CommonCrypto route was,
"bummer, git is not compiling.. let me try to fix that, somehow".

I think the best long-term solution would be to abandon the
CommonCrypto backend, if possible.  There's not a strong reason
for its existence.  It always seemed kinda hacky, and bolted-on.

> A few questions we should be asking Apple users are:
> 
>  - Is there a strong-enough reason why those who do not want to use
>    SSL should be able to choose the SHA-1 implementation available
>    from CommonCrypto over block-sha1?

IMO, no.

>  - Is CommonCrypto SHA-1 a better implementation than block-sha1?

I do not believe this to be true.

My gut feeling is that we cannot rely on the long-term stability
and availability of Apple's APIs.  Block-sha1 works fine on
the current Apple hardware and I suspect that it (or openssl)
will continue to work fine in the future.

> Depending on the answers to these questions, we might want to:
> 
>  - add a knob to allow choosing between two available
>    implementations (i.e. when NO_APPLE_COMMON_CRYPTO is unset) of
>    SHA-1, regardless of the setting of NO_OPENSSL.
> 
>  - decide which one between CommonCrypto and block-sha1 should be
>    the default.

How about, drop support for CommonCrypto so that there's no need
for the end-user to choose?  That means we would get block-sha1
by default.

> If we end up deciding that we use block-sha1 as the default, we
> should do so even when both NO_OPENSSL and NO_APPLE_COMMON_CRYPTO
> are left unset.  If we decide that block-sha1 should merely be a
> fallback when no other SHA-1 implementation is availble, on the
> other hand, we should be using CommonCrypto SHA-1 as long as the
> user did not set NO_APPLE_COMMON_CRYPTO explicitly, even when we are
> building with NO_OPENSSL.
> 
> If people do not care, we can leave things as they are.  It would
> seem mysterious to use block-sha1 when we are not using CommonCrypto
> for SSL (i.e. NO_OPENSSL), and otherwise CommonCrypto SHA-1, and
> would invite a puzzlement we saw in this thread, though.

I'm curious to see what others think about dropping CommonCrypto.
It seems like a good choice from a maintenance POV.
-- 
David