[PATCH] imap-send: eliminate HMAC warnings on OS X 10.8

[PATCH] imap-send: eliminate HMAC warnings on OS X 10.8

[David Aguilar]

Mac OS X Mountain Lion warns that HMAC_Init() and friends are
deprecated.  Use CommonCrypto's HMAC to eliminate the warnings.

Signed-off-by: David Aguilar <davvid@gmail.com>
---
This builds upon the patch I sent earlier, so technically it's 2/2

While researching these errors I found this:

http://opensource.apple.com/source/Git/Git-37/src/git/imap-send.c

The approach in this patch is similar in spirit, but simpler since
it avoids pushing #ifdefs into the function bodies.

 Makefile    |  5 +++++
 imap-send.c | 10 ++++++++++
 2 files changed, 15 insertions(+)

diff --git a/Makefile b/Makefile
index d8a45b4..7e12999 100644
--- a/Makefile
+++ b/Makefile
@@ -1055,6 +1055,7 @@ ifeq ($(uname_S),Darwin)
 		endif
 	endif
 	COMMON_DIGEST_SHA1 = YesPlease
+	COMMON_DIGEST_HMAC = YesPlease
 	PTHREAD_LIBS =
 endif
 
@@ -1399,6 +1400,10 @@ else
 endif
 endif
 endif
+
+ifdef COMMON_DIGEST_HMAC
+	BASIC_CFLAGS += -DCOMMON_DIGEST_FOR_HMAC=1
+endif
 ifdef NO_PERL_MAKEMAKER
 	export NO_PERL_MAKEMAKER
 endif
diff --git a/imap-send.c b/imap-send.c
index d9bcfb4..1b2e69c 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -29,8 +29,18 @@
 #ifdef NO_OPENSSL
 typedef void *SSL;
 #else
+#ifdef COMMON_DIGEST_FOR_HMAC
+#include <CommonCrypto/CommonHMAC.h>
+#define HMAC_CTX CCHmacContext
+#define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, len)
+#define HMAC_Update CCHmacUpdate
+#define HMAC_Final(hmac, hash, ptr) CCHmacFinal(hmac, hash)
+#define HMAC_CTX_cleanup
+#define EVP_md5() kCCHmacAlgMD5
+#else
 #include <openssl/evp.h>
 #include <openssl/hmac.h>
+#endif
 #include <openssl/x509v3.h>
 #endif
 
-- 
1.8.3.rc1.46.g9f9589e

Re: [PATCH] imap-send: eliminate HMAC warnings on OS X 10.8

[Jonathan Nieder]

David Aguilar wrote:

> Mac OS X Mountain Lion warns that HMAC_Init() and friends are
> deprecated.  Use CommonCrypto's HMAC to eliminate the warnings.

Makes sense, and if the #define trick stops working some day
due to some conflicting macro in an openssl header some day, it
would just break the build, so this should be safe.  For what it's
worth,

Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

[...]
> This builds upon the patch I sent earlier, so technically it's 2/2

I'm less sure about whether patch 1/2 is a good idea.  Luckily the
conflicts when trying to untangle the two are only textual.

Thanks,
Jonathan