On Tue, Dec 9, 2014 at 6:18 AM, Stuart Henderson <[email protected]> wrote: > On 2014/12/09 12:30, Lukas Tribus wrote: >> Hi, >> >> I'm linking haproxy (current git master) against libressl 2.1.2 >> portable on linux, but seeing 2 issues (not present in previous >> libressl 2.1.1): >> >> >> Issue number one (not sure what happens here): >> >> include/openssl/ssl.h:503:2: error: unknown type name ‘uint8_t’ >> uint8_t *tlsext_ecpointformatlist; /* peer's list */ >> ^ >> include/openssl/ssl.h:505:2: error: unknown type name ‘uint16_t’ >> uint16_t *tlsext_ellipticcurvelist; /* peer's list */ >> ^ >> include/openssl/ssl.h:1146:2: error: unknown type name ‘uint8_t’ >> uint8_t *tlsext_ecpointformatlist; /* our list */ >> ^ >> include/openssl/ssl.h:1148:2: error: unknown type name ‘uint16_t’ >> uint16_t *tlsext_ellipticcurvelist; /* our list */ >> ^ > > It looks like ssl.h users now need to pull in stdint.h..? > I guess we may find some more of these after a bulk ports build.
No, ssl.h should just include stdint.h as-needed, like bio.h does. Thanks for the notice. >> Issue number two is quite clear: libressl 2.1.2 defines >> TLSEXT_TYPE_application_layer_protocol_negotiation but doesn't support >> ALPN, while in haproxy the ALPN callers are ifdef'ed around that >> symbol, which obviously fails: >> >> src/ssl_sock.c: In function ‘ssl_sock_prepare_ctx’: >> src/ssl_sock.c:1650:3: warning: implicit declaration of function >> ‘SSL_CTX_set_alpn_select_cb’ [-Wimplicit-function-declaration] >> SSL_CTX_set_alpn_select_cb(ctx, ssl_sock_advertise_alpn_protos, >> bind_conf); >> ^ >> src/ssl_sock.c: In function ‘smp_fetch_ssl_fc_alpn’: >> src/ssl_sock.c:3590:2: warning: implicit declaration of function >> ‘SSL_get0_alpn_selected’ [-Wimplicit-function-declaration] >> SSL_get0_alpn_selected(conn->xprt_ctx, >> ^ >> make: *** [src/ssl_sock.o] Error 1 >> >> >> >> I know nginx uses this symbol as-well to determine whether there >> is ALPN support. I don't think it makes much sense to define this >> symbol unless there is actually ALPN support in the code, does it? > > I agree. It seems reasonable for programs to just use this macro in an > #ifdef because it was added to OpenSSL at the same time as ALPN support, > otherwise a more complicated check is needed to try linking one of the > functions (e.g. SSL_get0_alpn_selected) and see if it fails. > > In OpenBSD ports, there is just a hack in the nginx port to work around > this, #undef the macro after pulling in openssl headers until libressl > gains ALPN support. Not exactly a nice way to do it though. > If an app calls a function, it should probably check if that function exists during configuration time, rather than inferring if define A exists, function B and C must exist. Especially things that are just protocol constant definitions. If they are using autoconf, a call to AC_CHECK_FUNCS would be better, IMHO. But, I believe jsing@ has a patch in-review to merge the rest ALPN support any way.
