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

From: David Aguilar <davvid@gmail.com>
Date: Jan 2, 2016, 23:49 UTC
Message-ID: <20160102234923.GA14424@gmail.com>
In-Reply-To: <xmqqy4cf9ugm.fsf@gitster.mtv.corp.google.com>

On Sun, Dec 27, 2015 at 06:29:29PM -0800, Junio C Hamano wrote:

Show 22 quoted lines

> 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.

Show 5 quoted lines

> 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.

Show 8 quoted lines

> 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.

Show 12 quoted lines

> 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