On Sun, Dec 27, 2015 at 06:29:29PM -0800, Junio C Hamano wrote: > Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html