Re: [PATCH v4 3/3] cache.h: eliminate SHA-1 deprecation warnings on OS X 10.8

From: David Aguilar <davvid@gmail.com>
Date: May 14, 2013, 07:22 UTC
Message-ID: <CAJDDKr7hYvDMWLo6VWNuS0E2FYdKqmuDrLEG6CPr+6f0uCS9_g@mail.gmail.com>
In-Reply-To: <CAPig+cQwhhwyt+XHXz2_PLqmZ=goy7pz-GC3kFqOHm1R6=70YA@mail.gmail.com>

On Mon, May 13, 2013 at 6:32 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:

Show 23 quoted lines

> On Mon, May 13, 2013 at 4:23 AM, David Aguilar <davvid@gmail.com> wrote:
>> Mac OS X Mountain Lion prints warnings when building git:
>>
>>         warning: 'SHA1_Init' is deprecated
>>         (declared at /usr/include/openssl/sha.h:121)
>>
>> Silence the warnings by using the CommonCrytpo SHA-1
>> functions for SHA1_Init(), SHA1_Update(), and SHA1_Final().
>>
>> Add a COMMON_DIGEST_SHA1 option to the Makefile to allow
>> choosing this implementation and define it by default on Darwin.
>
> The approach of adding a Makefile option for each CommonCrypto
> facility does not really scale well. For instance, these days, I
> generally build git against OpenSSL from MacPorts, which gives me a
> warning-free git build since MacPorts/OpenSSL lacks those
> Apple-specific deprecation flags. With this patch series introducing
> several Makefile knobs, people wishing to use MacPorts/OpenSSL will
> have to tweak each knob. These patches already introduce two knobs
> (COMMON_DIGEST_SHA1, COMMON_DIGEST_HMAC). Adding more knobs to silence
> the remaining 29 deprecation warnings will make the build more
> cumbersome for those who prefer OpenSSL. Instead, introducing a single
> knob (such as APPLE_COMMON_CRYPTO) would avoid this problem.

That sounds like a good idea. In the very least these patches should be redone to do that.

Show 7 quoted lines

> More generally, is the approach of trying to figure out CommonCrypto
> replacements for DIGEST, HMAC, and the other 29 warnings worthwhile?
> After all, Apple introduced deprecation warnings due to the
> ABI-instability of OpenSSL, not due to any particular flaw in OpenSSL
> or its API. A more manageable approach might simply be to disable that
> particular warning on Darwin (via CFLAGS or perhaps '#pragma GCC
> diagnostic ignored' for more fine-grained control).

My only fear would be that these deprecation warnings would one day become errors due to the functions being removed. I don't know how else to interpret "deprecated".

If we can accomplish the same thing without deprecated APIs (and not harm other platforms) then that is a good thing. I doubt we can find 1:1 replacements. It'll probably have to be fleshed out in compat/.

Warnings in 1 file (imap-send.c) is much better than warnings in 20 files (git grep -l SHA1_Final), which is the itch I'm currently scratching. I'll be mindful of making sure that the users can still plug in their own compliant OpenSSL. -- David