OpenBSD 7.5 build fails because EVP_add_cipher_alias() no longer exists in OpenBSD libcrypto

[infrastation]

$ make -s CFLAGS=-Werror
print-esp.c: In function 'esp_init':
print-esp.c:681:9: error: implicit declaration of function 'EVP_add_cipher_alias' [-Werror=implicit-function-declaration]
  681 |         EVP_add_cipher_alias(SN_des_ede3_cbc, "3des");
      |         ^~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
*** Error 1 in /home/buildbot-worker/openbsd-amd64/tmpfs/tcpdump-openbsd-amd64/build (Makefile:68 'print-esp.o': egcc -W -Wall -Wcast-qual -...)
*** Error 1 in target 'print-esp.o'

In OpenBSD 7.4 the header defines EVP_add_cipher_alias() as follows:

#define EVP_add_cipher_alias(n,alias) \
        OBJ_NAME_add((alias),OBJ_NAME_TYPE_CIPHER_METH|OBJ_NAME_ALIAS,(n))

In OpenBSD 7.5 it does not define the macro since revision 1.122 (2024-03-02). One way to resolve this would be to make the alias conditional, another would be to stop using it (it was introduced in commit 0d821a5).

[infrastation]

Using MATRIX_CRYPTO=no masks this problem meanwhile.

[spbkaizo]

This also causes a failed ssl linked build on Linux when only libressl is installed to.

[infrastation]

Could you post the steps to reproduce?

[spbkaizo]

Sure,

<simonb@odin:~/src/bpf/ping>
zsh/2 1221 % openssl version
LibreSSL 3.9.2

Usual configure:

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var

Output snipped:

checking whether to use OpenSSL/libressl libcrypto... yes, if available
checking openssl/crypto.h usability... yes
checking openssl/crypto.h presence... yes
checking for openssl/crypto.h... yes
checking for DES_cbc_encrypt in -lcrypto... yes
checking openssl/evp.h usability... yes
checking openssl/evp.h presence... yes
checking for openssl/evp.h... yes
checking for EVP_CIPHER_CTX_new... yes
checking for EVP_DecryptInit_ex... yes
...

A warning is emitted during make, the build continues though:

gcc  -DHAVE_CONFIG_H   -I. -I/usr/include/libnl3 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include  -g -O2 -c ./print-esp.c
./print-esp.c: In function 'esp_init':
./print-esp.c:686:9: warning: implicit declaration of function 'EVP_add_cipher_alias' [-Wimplicit-function-declaration]
  686 |         EVP_add_cipher_alias(SN_des_ede3_cbc, "3des");
      |         ^~~~~~~~~~~~~~~~~~~~

and finally:

ranlib libnetdissect.a
gcc  -DHAVE_CONFIG_H   -I. -I/usr/include/libnl3 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include  -g -O2  -o tcpdump fptype.o tcpdump.o libnetdissect.a -lcap-ng -lcrypto -lpcap 
/usr/bin/ld: libnetdissect.a(print-esp.o): in function `esp_init':
/usr/src/misc/tcpdump-4.99.4/./print-esp.c:686:(.text+0xe26): undefined reference to `EVP_add_cipher_alias'
collect2: error: ld returned 1 exit status
make: *** [Makefile:395: tcpdump] Error 1

Which is hardly surprising, as:

<simonb@odin:/usr/src/misc/tcpdump-4.99.4>
zsh/2 1233 [1] % nm /usr/lib/libcrypto.so | grep EVP_add_cipher_alias || echo notfound
notfound
<simonb@odin:/usr/src/misc/tcpdump-4.99.4>
zsh/2 1234 % nm /usr/lib/libssl.so | grep EVP_add_cipher_alias || echo notfound
notfound

[infrastation]

Thank you. Which Linux distribution is this?

[spbkaizo]

It's an LFS system - I've only myself to blame!

LFS does use upstream vanilla openssl, I deviated from that by installing libressl and omitting openssl.

Edit: I just removed the call with:

687 #ifndef LIBRESSL_VERSION_NUMBER                                                                                                                                                               
688     EVP_add_cipher_alias(SN_des_ede3_cbc, "3des");                                                                                                                                            
689 #endif                                                                                                                                                                                        
690 }    

[infrastation]

OpenBSD 7.5 has the following:

$ openssl version
LibreSSL 3.9.0

Then LibreSSL is the key factor rather than OpenBSD. Version 3.9.2 is available on FreeBSD as a port and may provide an easy way to confirm the bug fix in future.

[guyharris]

Apparently EVP_add_cipher_alias() was never documented and "[is an internal macro] and not really suitable for the Brave New Provider World".

At least as far back as OpenSSL 0.9.6, EVP_add_cipher_alias(n,alias) expands to OBJ_NAME_add((alias),OBJ_NAME_TYPE_CIPHER_METH|OBJ_NAME_ALIAS,(n)), and OBJ_NAME_add() is documented, so we should probably use that, instead; it appears to be in libressl, and documented there as well.

[guyharris]

Unfortunately, OpenBSD 7.5's libressl doesn't have OBJ_NAME_add(), either.

[infrastation]

Well, then perhaps making the line conditional on LIBRESSL_VERSION_NUMBER as suggested above would be the best immediate workaround, and removing obsolete ciphers altogether would be the best long-term solution. The latter would also require redoing the tests for print-isakmp.c, many of which are for 3DES.

[infrastation]

On OpenBSD 7.5 disabling the call affects make check as follows:

FILE: /home/denis/gitrepos/tcpdump/tests/crypto.tests
    esp1                                    : TEST FAILED(exit core=0/diffstat=1,0/r=256) with error messages:
reading from file 02-sunrise-sunset-esp.pcap, link-type EN10MB (Ethernet), snapshot length 1536
tcpdump: WARNING: failed to find cipher algo 3des
    esp2                                    : TEST FAILED(exit core=0/diffstat=1,0/r=256) with error messages:
reading from file 08-sunrise-sunset-esp2.pcap, link-type EN10MB (Ethernet), snapshot length 1536
tcpdump: WARNING: failed to find cipher algo 3des
tcpdump: WARNING: failed to find cipher algo 3des
    esp3                                    : TEST FAILED(exit core=0/diffstat=1,0/r=256) with error messages:
reading from file 02-sunrise-sunset-esp.pcap, link-type EN10MB (Ethernet), snapshot length 1536
tcpdump: WARNING: failed to find cipher algo 3des
    esp4                                    : TEST FAILED(exit core=0/diffstat=1,0/r=256) with error messages:
reading from file 08-sunrise-sunset-esp2.pcap, link-type EN10MB (Ethernet), snapshot length 1536
tcpdump: WARNING: failed to find cipher algo 3des
tcpdump: WARNING: failed to find cipher algo 3des
    esp5                                    : passed with error messages:
reading from file 08-sunrise-sunset-aes.pcap, link-type EN10MB (Ethernet), snapshot length 1536
tcpdump: WARNING: failed to find cipher algo 3des
tcpdump: WARNING: failed to find cipher algo 3des
    espudp1                                 : TEST FAILED(exit core=0/diffstat=1,0/r=256) with error messages:
reading from file espudp1.pcap, link-type EN10MB (Ethernet), snapshot length 1536
tcpdump: WARNING: failed to find cipher algo 3des
tcpdump: WARNING: failed to find cipher algo 3des
    isakmp4                                 : passed with error messages:
reading from file isakmp4500.pcap, link-type EN10MB (Ethernet), snapshot length 1536
tcpdump: WARNING: failed to find cipher algo 3des
tcpdump: WARNING: failed to find cipher algo 3des

So the workaround should amend the conditions on that these tests run.

[infrastation]

My working copy has a working version of the workaround, this is going to be a pull request later today.

[guyharris]

failed to find cipher algo 3des

What happens if you replace "3des" with "DES3" (all caps) in the appropriate file in TESTS.

[infrastation]

Both "des3" and "DES3" work: with OpenSSL on Linux, with LibreSSL on OpenBSD (without the offending function call). For reference, the workaround I had in mind is #1206, but now the proper solution seems to be deprecating the alias.

[infrastation]

Meanwhile Buildbot is using MATRIX_CRYPTO=no for OpenBSD again.

[guyharris]

So we now do the mapping of "3des" to a supported name for triple DES in tcpdump rather than attempting to set up "3des" as an alias for the triple DES cipher in libcrypto.

[infrastation]

Thank you. Buildbot no longer uses MATRIX_CRYPTO=no on OpenBSD and the builds pass. This fix will need a change log entry at some point.

[guyharris]

This fix will need a change log entry at some point.

Backported to the 4.99 branch in 87b050965700b9b35f196d3774d004f8ce92d749, and added to the 4.99 section in CHANGES in both the main and 4.99 branches.