Bug 278018 - sysutils/rsyslog8 8.2402.0 does not build with LibreSSL 3.8.3
Summary: sysutils/rsyslog8 8.2402.0 does not build with LibreSSL 3.8.3
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Matthew Seaman
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-03-29 00:29 UTC by Dave Hayes
Modified: 2024-04-01 19:29 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (matthew)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Hayes 2024-03-29 00:29:30 UTC
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();
Comment 1 Matthew Seaman freebsd_committer freebsd_triage 2024-03-31 10:48:22 UTC
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
Comment 2 Dave Hayes 2024-03-31 19:23:02 UTC
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.
Comment 3 Dave Hayes 2024-03-31 19:31:32 UTC
https://github.com/rsyslog/rsyslog/issues/5353
Comment 4 commit-hook freebsd_committer freebsd_triage 2024-03-31 22:37:03 UTC
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(-)
Comment 5 Matthew Seaman freebsd_committer freebsd_triage 2024-03-31 22:46:27 UTC
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.
Comment 6 Dave Hayes 2024-04-01 03:32:32 UTC
Thanks for the rapid response, your commit builds just fine here. :)
Comment 7 Matthew Seaman freebsd_committer freebsd_triage 2024-04-01 09:32:05 UTC
(In reply to Dave Hayes from comment #6)

Building is one thing, but does it perform correctly?
Comment 8 Dave Hayes 2024-04-01 19:29:54 UTC
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. :)