Bug 243963
| Summary: | mail/spamd: Fails to compile with openssl 1.1.1 on 12.1-p2 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | AS <asharp> | ||||
| Component: | Individual Port(s) | Assignee: | Olli Hauer <ohauer> | ||||
| Status: | Closed Overcome By Events | ||||||
| Severity: | Affects Only Me | CC: | yds | ||||
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(ohauer) |
||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Created attachment 211589 [details]
unbreaks the build by always linking LibreSSL
unbreaks the build by always linking LibreSSL
fix lifted from net/openntpd
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? (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? 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? (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. Understood. cols, overcome by event |
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);