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

[Junio C Hamano <gitster@pobox.com>]

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.

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?

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

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.

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.