Yubico / libfido2

Provides library functionality for FIDO2, including communication with a device over USB or NFC.
Other
581 stars 153 forks source link

Add -Wno-deprecated-declarations for Linux/Mac build. #761

Closed James-ZHANG closed 8 months ago

James-ZHANG commented 8 months ago

We witnessed the following compile errors when building libfido2 on our MacOS build environment (Ventura with Xcode 14.3.1):

<our custom path>/libfido2/src/cbor.c:759:13: error: 'HMAC_CTX_new' is deprecated [-Werror,-Wdeprecated-declarations]
        if ((ctx = HMAC_CTX_new()) == NULL ||
                   ^
/usr/local/include/openssl/hmac.h:33:1: note: 'HMAC_CTX_new' has been explicitly marked deprecated here
OSSL_DEPRECATEDIN_3_0 HMAC_CTX *HMAC_CTX_new(void);
^
/usr/local/include/openssl/macros.h:193:49: note: expanded from macro 'OSSL_DEPRECATEDIN_3_0'
#   define OSSL_DEPRECATEDIN_3_0                OSSL_DEPRECATED(3.0)
                                                ^
/usr/local/include/openssl/macros.h:62:52: note: expanded from macro 'OSSL_DEPRECATED'
#     define OSSL_DEPRECATED(since) __attribute__((deprecated))

IIUC this is because either -Wall or -Wextra includes -Wdeprecated-declarations and -Werror turns that into an error.

I'm not sure why the upstream did not have this error: maybe it's a specific issue for XCode 14.3.1 only?

Since we are still supporting OpenSSL 1.1, I think it makes sense to add -Wno-deprecated-declarations explicitly until we bump OpenSSL version to 3.0 (from the NEWS file Yubico is going to do so in 1.16?).

LDVG commented 8 months ago

Hi,

This should already have been handled by us setting OPENSSL_API_COMPAT:

https://github.com/Yubico/libfido2/blob/de45438604e0eea0864818615fbd175376245491/CMakeLists.txt#L328

Is it possible your (custom?) build is missing this define?

James-ZHANG commented 8 months ago

Is it possible your (custom?) build is missing this define?

Yes, exactly :). I knew OpenSSL has a way to avoid the deprecation warning and you reminded me.

My problem is that our build mistakenly includes the system-default OpenSSL@3 headers under /usr/local/, instead of an OpenSSL@1.1 one we build from source and install at a custom location. Our intent is to use the self-built OpenSSL@1.1 as dependency, thus when cmake resolves the libcrypto location, it finds our custom built one, sees it's OpenSSL@1.1, and therefore does not set the OPENSSL_API_COMPAT flag.