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. > 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.
