On Wed, Nov 25, 2015 at 10:10 AM, Jack Nagel <jacknagel@xxxxxxxxx> wrote: > When compiling git on OS X (where APPLE_COMMON_CRYPTO=1 is the > default) and specifying NO_OPENSSL=1, the resulting git uses the > BLK_SHA1 implementation rather than the functions available in > CommonCrypto. > > $ make NO_OPENSSL=1 > [...] > $ nm git | grep _SHA1_ > 0000000100173f00 t _blk_SHA1_Block > 0000000100174e80 T _blk_SHA1_Final > 000000010018fbb0 s _blk_SHA1_Final.pad > 0000000100173de0 T _blk_SHA1_Init > 0000000100173e10 T _blk_SHA1_Update NO_OPENSSL disables all SSL-related functionality in Git, not just SHA1 computation, however, Git still needs to compute SHA1 hashes for other reasons, so it uses its own BLK_SHA1 versions when OpenSSL is unavailable. > However, with OpenSSL available, it does use the CommonCrypto functions: > > $ make > [...] > $ nm git | grep _SHA1_ > U _CC_SHA1_Final > U _CC_SHA1_Init > U _CC_SHA1_Update > > I would not expect the presence of NO_OPENSSL=1 to change the behavior > here, since neither case actually makes use of the OpenSSL SHA1 > functions. Apple's CommonCrypto headers present OpenSSL-compatible API. When CommonCrypto is enabled in the Git makefile, aside from pulling in the CommonCrypto header and linking against the CommonCrypto framework, from Git's perspective, it still thinks it's using OpenSSL, and all SSL-related functionality is enabled (including the SHA1 functions). 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. -- 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