Hi Dave,
On Tue, Nov 15, 2016 at 11:22:16PM +0100, Dave Cottlehuber wrote:
> cc -Iinclude -Iebtree -Wall -O2 -pipe -fno-omit-frame-pointer
> -fstack-protector -fno-strict-aliasing -DFREEBSD_PORTS -DTPROXY
> -DCONFIG_HAP_CRYPT -DUSE_GETADDRINFO -DUSE_ZLIB -DENABLE_POLL
> -DENABLE_KQUEUE -DUSE_CPU_AFFINITY -DUSE_OPENSSL -DUSE_LUA
> -I/usr/local/include/lua53 -DUSE_PCRE -I/usr/local/include
> -DUSE_PCRE_JIT -DCONFIG_HAPROXY_VERSION=\"1.7-dev6-d5d890b\"
> -DCONFIG_HAPROXY_DATE=\"2016/11/09\" -c -o ebtree/ebistree.o
> ebtree/ebistree.c
> src/ssl_sock.c:1966:8: warning: implicit declaration of function
> 'SSL_CTX_add1_chain_cert' is invalid in C99
OK so there's no SSL_CTX_add1_chain_cert() in LibreSSL. This one was
introduced last year to permit loading both RSA, DSA and ECDSA certs.
Maybe this is not possible with LibreSSL ?
> [-Wimplicit-function-declaration]
> if (!SSL_CTX_add1_chain_cert(ctx, ckch->chain_certs[i]))
> {
> ^
> src/ssl_sock.c:2270:12: warning: incompatible integer to pointer
> conversion assigning to 'pem_password_cb *' (aka 'int (*)(char *, int,
> int, void *)') from 'int' [-Wint-conversion]
> passwd_cb = SSL_CTX_get_default_passwd_cb(ctx);
> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This one comes from the support of the new OpenSSL 1.1.0 API. Maybe it
can be emulated differently ?
> src/ssl_sock.c:3521:6: error: use of undeclared identifier
> 'OSSL_HANDSHAKE_STATE'
> OSSL_HANDSHAKE_STATE state =
> SSL_get_state((SSL
> *)conn->xprt_ctx);
> ^
Same here. What is annoying is that every time it appears, it's protected
by a #if OPENSSL_VERSION_NUMBER >= 1.1.0 so that means that LibreSSL is
spoofing OpenSSL version numbers without providing compatibility. If so,
that will become quite painful to support.
> There's a partial patch here
> https://github.com/HardenedBSD/hardenedbsd-ports/commit/b0c5e0fd15cdf9b6059e5c66e66f9e81b4e7f252
> via HardenedBSD project but I can't tell if this would break other SSL
> library combinations.
Maybe this one will help a bit and will need to be extended. But now
I'm realizing that LibreSSL-based implementations will miss some of
the important features that people want to use. That's sad, maybe they
went a little bit too much on the extreme cleanup side ?
If you have a patch to provide which fixes the build for you and which
doesn't break other implementations (ie only disables code for libressl)
then it's something we can merge.
Willy