FreeBSD 13.2, ports HEAD as of 6b5a47c1f. Deja vu, but this time the SSL_CONF_CTX api was apparently not supported by rsyslog (LibreSSL does not have this API). Relevant transcript from the build log follows: [00:00:31] /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I.. -pthread -I../runtime -I.. -I../grammar -O2 -pipe -I/usr/local/include -I/usr/local/include -I/usr/local/include -fstack-protector-strong -fno-strict-aliasing -I/usr/local/include/libfastjson -W -Wall -Wformat-security -Wshadow -Wcast-align -Wpointer-arith -Wmissing-format-attribute -Werror=implicit-function-declaration -g -I /usr/local/include -I/usr/local/include -I/usr/local/include -O2 -pipe -I/usr/local/include -I/usr/local/include -I/usr/local/include -fstack-protector-strong -fno-strict-aliasing -W -Wall -Wformat-security -Wshadow -Wcast-align -Wpointer-arith -Wmissing-format-attribute -g -MT lmnsd_ossl_la-net_ossl.lo -MD -MP -MF .deps/lmnsd_ossl_la-net_ossl.Tpo -c -o lmnsd_ossl_la-net_ossl.lo `test -f 'net_ossl.c' || echo './'`net_ossl.c [00:00:31] libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -pthread -I../runtime -I.. -I../grammar -O2 -pipe -I/usr/local/include -I/usr/local/include -I/usr/local/include -fstack-protector-strong -fno-strict-aliasing -I/usr/local/include/libfastjson -W -Wall -Wformat-security -Wshadow -Wcast-align -Wpointer-arith -Wmissing-format-attribute -Werror=implicit-function-declaration -g -I /usr/local/include -I/usr/local/include -I/usr/local/include -O2 -pipe -I/usr/local/include -I/usr/local/include -I/usr/local/include -fstack-protector-strong -fno-strict-aliasing -W -Wall -Wformat-security -Wshadow -Wcast-align -Wpointer-arith -Wmissing-format-attribute -g -MT lmnsd_ossl_la-net_ossl.lo -MD -MP -MF .deps/lmnsd_ossl_la-net_ossl.Tpo -c net_ossl.c -fPIC -DPIC -o .libs/lmnsd_ossl_la-net_ossl.o [00:00:31] net_ossl.c:482:3: error: unknown type name 'SSL_CONF_CTX'; did you mean 'SSL_AEAD_CTX'? [00:00:31] SSL_CONF_CTX *cctx; [00:00:31] ^~~~~~~~~~~~ [00:00:31] SSL_AEAD_CTX [00:00:31] /usr/local/include/openssl/ssl.h:523:32: note: 'SSL_AEAD_CTX' declared here [00:00:31] typedef struct ssl_aead_ctx_st SSL_AEAD_CTX; [00:00:31] ^ [00:00:31] net_ossl.c:483:10: error: call to undeclared function 'SSL_CONF_CTX_new'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration] [00:00:31] cctx = SSL_CONF_CTX_new();
Hi, Thank you for your report. Looks like there has been another issue reported around line 460 of net_ossl.c to do with incompatibilities with SSL libs: https://github.com/rsyslog/rsyslog/issues/5342 Is this basically the same issue? If not, could you report this upstream please? Hmmm..... Looks like the code in net_ossl.c is to support the imdtls and omdtls modules, which don't get built by default in the FreeBSD port. So we can just #ifdef out the problem code. (Really, there should be an option to build those modules.) Note to self: also see 254864
I am no expert on the rsyslog code, thus I can't say for certain whether or not it is basically the same issue. For the same reason, I have no accurate idea if one can ifdef that code out usefully. :) With those caveats in mind, one admittedly naive approach is that the ifdefs in the code that reference the openssl version number are numerous and would all need to add the conditional "defined(LIBRESSL_VERSION_NUMBER)" as it makes sense for the particular section of code. This would be in the hope that the older openssl API is both supported properly in rsyslog8 and in libressl 3.8.3 I did grep -n the net_ossl.c source and there are CTX issues between lines 226 and 1181. That's a fair bit of code to comment out for something that is a key application like rsyslog8. Of course I would prefer that upstream do this delicate task, but given the response to the upstream issue we have both looked at, I'm not sure how productive filing an issue will be. Nevertheless I will open an issue.
https://github.com/rsyslog/rsyslog/issues/5353
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=04edb069f969257247955cca1d9eefd2b359e2c7 commit 04edb069f969257247955cca1d9eefd2b359e2c7 Author: Matthew Seaman <matthew@FreeBSD.org> AuthorDate: 2024-03-31 22:18:21 +0000 Commit: Matthew Seaman <matthew@FreeBSD.org> CommitDate: 2024-03-31 22:36:04 +0000 sysutils/rsyslog8: fix build with libressl, add DTLS option rsyslog8 fails to build with libressl due to lack of support of the SSL_CONF_CTX type. This occurs in a block of code only used by the DTLS input and output modules, which are not enabled by default in the FreeBSD port. Therefore solve the build failure by making the problematic function dependant on LIBRESSL_VERSION_NUMBER being defined (via files/patch-runtime_net__ossl.c, obtained from github issue 5342 for rsyslog). This is similar to previous libressl compatability fixes from PR 254864. While here, add a DTLS option to enable building the imdtls and omdtls modules -- this does require linkage against openssl to compile successfully. Additionally required patches are to add the necessary header files for the pthread_kill(3) and close(2) prototypes. I have not been able to test the functionality of the DTLS modules very effectively and would be glad to hear of anyone's experiences with them. PR: 278018 Reported by: Dave Hayes <dave@jetcafe.org> Obtained from: (partly) https://github.com/rsyslog/rsyslog/issues/5342 sysutils/rsyslog8/Makefile | 8 +++++++- .../rsyslog8/files/patch-plugins_imdtls_imdtls.c (new) | 10 ++++++++++ .../rsyslog8/files/patch-plugins_omdtls_omdtls.c (new) | 10 ++++++++++ .../rsyslog8/files/patch-runtime_net__ossl.c (new) | 18 ++++++++++++++++++ 4 files changed, 45 insertions(+), 1 deletion(-)
So, rsyslog at least builds against libressl with the patches I just committed. It seems the problematic code is all in support of the loadable imdtls and omdtls modules, which were not built as part of the FreeBSD port. So I'm pretty happy to comment out various functions. Of course, having been made aware of the existence of the DTLS capability in rsyslog, I could see no reason why it shouldn't be avaialable in the FreeBSD port, so I added an OPTION to enable building it. Enabling the DTLS option obviously won't combine well with linking against libressl. I'll keep this PR open for a while pending any feedback from upstream.
Thanks for the rapid response, your commit builds just fine here. :)
(In reply to Dave Hayes from comment #6) Building is one thing, but does it perform correctly?
So far it performs correctly. I'm not sure how deeply the SSL functionality was tested, but machines are logging properly so there is that. Note that I will not claim here that it 100% works as I do not possess comprehensive tests. :)
And now as of 2024Q3 this has broken again with libressl. This may be a new issue: [00:00:32] net_ossl.c:232:23: error: call to undeclared function 'ENGINE_get_first'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration] [00:00:32] ENGINE *osslEngine = ENGINE_get_first(); [00:00:32] ^ [00:00:32] net_ossl.c:232:23: note: did you mean 'ENGINE_get_id'? [00:00:32] /usr/local/include/openssl/engine.h:108:13: note: 'ENGINE_get_id' declared here [00:00:32] const char *ENGINE_get_id(const ENGINE *engine); [00:00:32] ^ [00:00:32] net_ossl.c:232:10: error: incompatible integer to pointer conversion initializing 'ENGINE *' (aka 'struct engine_st *') with an expression of type 'int' [-Wint-conversion] [00:00:32] ENGINE *osslEngine = ENGINE_get_first(); [00:00:32] ^ ~~~~~~~~~~~~~~~~~~ [00:00:32] net_ossl.c:237:7: error: call to undeclared function 'ENGINE_get_init_function'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration] [00:00:32] if (ENGINE_get_init_function(osslEngine)) { // Check if engine is initialized [00:00:32] ^ [00:00:32] net_ossl.c:242:16: error: call to undeclared function 'ENGINE_get_next'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration] [00:00:32] osslEngine = ENGINE_get_next(osslEngine); [00:00:32] ^ [00:00:32] net_ossl.c:242:16: note: did you mean 'ENGINE_get_name'? [00:00:32] /usr/local/include/openssl/engine.h:109:13: note: 'ENGINE_get_name' declared here [00:00:32] const char *ENGINE_get_name(const ENGINE *engine); [00:00:32] ^ [00:00:32] net_ossl.c:242:14: error: incompatible integer to pointer conversion assigning to 'ENGINE *' (aka 'struct engine_st *') from 'int' [-Wint-conversion] [00:00:32] osslEngine = ENGINE_get_next(osslEngine); [00:00:32] ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~ [00:00:32] net_ossl.c:733:10: error: call to undeclared function 'net_ossl_genfingerprintstr'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration] [00:00:32] CHKiRet(net_ossl_genfingerprintstr(fingerprint, size, &pstrFingerprint, "SHA1")); [00:00:32] ^ [00:00:32] net_ossl.c:733:10: note: did you mean 'net_ossl_peerfingerprint'? [00:00:32] net_ossl.c:701:1: note: 'net_ossl_peerfingerprint' declared here [00:00:32] net_ossl_peerfingerprint(net_ossl_t *pThis, X509* certpeer, uchar *fromHostIP) [00:00:32] ^ [00:00:32] net_ossl.c:1174:4: error: call to undeclared function 'ENGINE_set_default_DSA'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration] [00:00:32] ENGINE_set_default_DSA(default_engine); [00:00:32] ^ [00:00:32] net_ossl.c:1174:4: note: did you mean 'ENGINE_set_default_RSA'? [00:00:32] /usr/local/include/openssl/engine.h:114:5: note: 'ENGINE_set_default_RSA' declared here [00:00:32] int ENGINE_set_default_RSA(ENGINE *engine); [00:00:32] ^ [00:00:32] net_ossl.c:1175:4: error: call to undeclared function 'ENGINE_set_default_ciphers'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration] [00:00:32] ENGINE_set_default_ciphers(default_engine);
This is a different issue to the original PR that was raised, and should be in a separate ticket. Anyhow, thank you for your report. Initial impressions are that this will have to go upstream -- I won't have a chance to investigate more fully until the weekend though.
Should I open a new ticket?
Close this PR, as the original issue was fixed long ago. Please submit a new PR for the compilation problems mentioned in comment 9 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278018#c9)