Hi,
>> Well, I really hope you're right. This patch looks in the cipher's >> description instead of its name. Sorry about the mess. > > > in src/ssl_sock.c:1582:11: >> ciphers = ctx->cipher_list; > > can we use the API instead of accessing cipher_list directly? > With [1] perhaps? > > > Background: I'm playing with the new OpenSSL forks BoringSSL and > LibreSSL (with some #ifdef'ing), and when compiling with BoringSSL > I see: > src/ssl_sock.c: In function 'ssl_sock_prepare_ctx': > src/ssl_sock.c:1582:11: warning: assignment from incompatible pointer \ > type [enabled by default] > ciphers = ctx->cipher_list; > > > One of the (new) OpenSSL roadmap goals [2] is to deprecated those > supposed-to-be-private APIs, so this may not be a bad idea > anyway? Be that as it may, BoringSSL changed the internal structure because of a specific feature, so whether we use the API or access directly is irrelevant because the structure is different: https://boringssl.googlesource.com/boringssl/+/858a88daf27975f67d9f63e18f95645be2886bfb%5E!/ Perhaps we should #ifdef the particular code in haproxy out when boringssl is used (and be silent or simply assume that DHE is used). Regards, Lukas
