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

Reply via email to