Bug 243963 - mail/spamd: Fails to compile with openssl 1.1.1 on 12.1-p2
Summary: mail/spamd: Fails to compile with openssl 1.1.1 on 12.1-p2
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Olli Hauer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-02-07 20:41 UTC by AS
Modified: 2020-02-18 06:17 UTC (History)
1 user (show)

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


Attachments
unbreaks the build by always linking LibreSSL (1.15 KB, patch)
2020-02-12 13:43 UTC, yds
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description AS 2020-02-07 20:41:23 UTC
spamd (4.9.1) fails to compile when OpenSSL 1.1.1 is utilized.

Relevant portion of compile output:

cc  -O2 -pipe  -I/usr/local/include -fstack-protector-strong -fno-strict-aliasing  -Wall -Wstrict-prototypes   -MD  -MF.depend.sync.o -MTsync.o -std=gnu99 -fstack-protector-strong    -Qunused-arguments  -c sync.c -o sync.o
sync.c:442:11: error: variable has incomplete type 'HMAC_CTX' (aka 'struct hmac_ctx_st')
        HMAC_CTX ctx;
                 ^
/usr/local/include/openssl/ossl_typ.h:102:16: note: forward declaration of 'struct hmac_ctx_st'
typedef struct hmac_ctx_st HMAC_CTX;
               ^
sync.c:458:2: warning: implicit declaration of function 'HMAC_CTX_init' is invalid in C99 [-Wimplicit-function-declaration]
        HMAC_CTX_init(&ctx);
        ^
sync.c:458:2: warning: this function declaration is not a prototype [-Wstrict-prototypes]
sync.c:459:2: warning: 'HMAC_Init' is deprecated [-Wdeprecated-declarations]
        HMAC_Init(&ctx, sync_key, strlen(sync_key), EVP_sha1());
        ^
/usr/local/include/openssl/hmac.h:30:1: note: 'HMAC_Init' has been explicitly marked deprecated here
DEPRECATEDIN_1_1_0(__owur int HMAC_Init(HMAC_CTX *ctx, const void *key, int len,
^
/usr/local/include/openssl/opensslconf.h:158:34: note: expanded from macro 'DEPRECATEDIN_1_1_0'
# define DEPRECATEDIN_1_1_0(f)   DECLARE_DEPRECATED(f)
                                 ^
/usr/local/include/openssl/opensslconf.h:121:55: note: expanded from macro 'DECLARE_DEPRECATED'
#   define DECLARE_DEPRECATED(f)    f __attribute__ ((deprecated));
                                                      ^
sync.c:519:2: warning: implicit declaration of function 'HMAC_CTX_cleanup' is invalid in C99 [-Wimplicit-function-declaration]
        HMAC_CTX_cleanup(&ctx);
        ^
sync.c:519:2: warning: this function declaration is not a prototype [-Wstrict-prototypes]
sync.c:530:11: error: variable has incomplete type 'HMAC_CTX' (aka 'struct hmac_ctx_st')
        HMAC_CTX ctx;
                 ^
/usr/local/include/openssl/ossl_typ.h:102:16: note: forward declaration of 'struct hmac_ctx_st'
typedef struct hmac_ctx_st HMAC_CTX;
               ^
sync.c:540:2: warning: implicit declaration of function 'HMAC_CTX_init' is invalid in C99 [-Wimplicit-function-declaration]
        HMAC_CTX_init(&ctx);
        ^
sync.c:541:2: warning: 'HMAC_Init' is deprecated [-Wdeprecated-declarations]
        HMAC_Init(&ctx, sync_key, strlen(sync_key), EVP_sha1());
        ^
/usr/local/include/openssl/hmac.h:30:1: note: 'HMAC_Init' has been explicitly marked deprecated here
DEPRECATEDIN_1_1_0(__owur int HMAC_Init(HMAC_CTX *ctx, const void *key, int len,
^
/usr/local/include/openssl/opensslconf.h:158:34: note: expanded from macro 'DEPRECATEDIN_1_1_0'
# define DEPRECATEDIN_1_1_0(f)   DECLARE_DEPRECATED(f)
                                 ^
/usr/local/include/openssl/opensslconf.h:121:55: note: expanded from macro 'DECLARE_DEPRECATED'
#   define DECLARE_DEPRECATED(f)    f __attribute__ ((deprecated));
                                                      ^
sync.c:576:2: warning: implicit declaration of function 'HMAC_CTX_cleanup' is invalid in C99 [-Wimplicit-function-declaration]
        HMAC_CTX_cleanup(&ctx);
Comment 1 yds 2020-02-12 13:43:35 UTC
Created attachment 211589 [details]
unbreaks the build by always linking LibreSSL

unbreaks the build by always linking LibreSSL
fix lifted from net/openntpd
Comment 2 AS 2020-02-12 16:49:19 UTC
Linking with LibreSSL in environments that have standardized on openssl will create significant havoc.  Based on the previous patches that were going around that made changes to adjust for the openssl calls - wouldn't that be the better route?  Especially if/when LibreSSL goes down the same path?  Apps that support the updated openssl calls would (?likely?) not be compliant with the older calls as used in LibreSSL, no?
Comment 3 yds 2020-02-12 17:55:52 UTC
(In reply to A Sharp from comment #2)
LibreSSL is not installed as a dependency
LibreSSL is statically linked during the build
no conflict with OpenSSL in base or from ports.
the patch I provided is how I do it in my local ports tree.
the same method of statically linking LibreSSL during build is used by a few other ports of OpenBSD projects like net/openntpd and net/relayd
if it works there why not here?
Comment 4 AS 2020-02-12 18:51:59 UTC
OK - Wasn't focusing on the "static linking" v. dependency part.  Given that, perhaps the only question is - are there any drawbacks or gotchas that may arise out of everything using openssl and this being statically linked against LibreSSL?  Would this obscure the [logical] dependency if there's a vulnerability/bugfix/etc in terms of LibreSSL from a port auditing/update perspective?
Comment 5 yds 2020-02-13 06:14:40 UTC
(In reply to A Sharp from comment #4)
not /everything/ else is using OpenSSL. many ports link with GNUTLS or some other SSL library.  If/when LibreSSL gets a version bump then this and every other port statically and/or dynamically linking to it will need a PORTREVISION bump.  That's kinda how it is now with many other libraries. When a lib get updated it sometimes forces all dependent ports to get a PORTREVISION bump. that's upto the port maintainers to work out when/if/how to force an update.

It seems that almost every port originating from OpenBSD, such as this one, needs to link with LibreSSL which is the system SSL lib on OpenBSD.  These ports are written to the LibreSSL API.

if you want this port to build, then this patch I lifted from net/openntpd is the quickest and surest way to get there.  Otherwise these ports need to be rewritten to the OpenSSL 1.1.1 API -- that's a lot more work and that patch set is unlikely to be accepted upstream where these ports are part of the base OpenBSD system along with LibreSSL.  That means that the OpenSSL API patch set would need to be maintained here, and not upstream.  or we can just link against LibreSSL and be done with it. other than an occasional version bump.
Comment 6 AS 2020-02-18 06:17:46 UTC
Understood.