On Thu, May 30, 2024 at 06:40:42PM +0000, Lucas Gabriel Vuotto wrote:
> Hello ports@,
>
> Here is an update to haproxy to latest version, released yesterday. I
> have been running the -dev versions on-and-off for the last couple of
> weeks without much issue; I don't expect anything to go wrong with
> this last version. Changelog is big and can be found at [0].
>
> Portwise, I didn't see much gain in HAPROXY* vars so I got rid of them.
> That's where most of the churn comes from. I also added USE_PROMEX=1 to
> have a Prometheus / OpenMetrics endpoint. It compiles an additional C
> file without any new dependency.
>
> tb@, the only difference (and the reason why update is WIP) I see here
> with my arm64 server is that now I'll get "Weird server reply" from
> curl if I try to connect with QUIC. The issue is only present when
> using the default cipher suite; removing TLS_CHACHA20_POLY1305_SHA256
> from the proposal makes it work correctly. Is this related to "alert
> issue" you talk about in [1]? In that case, does it make sense to pause
> this update until the issue is solved?
Does this still happen if you apply this on top (which will be a noop
once we bump the libressl version to 4.0)?
Index: include/haproxy/quic_tls.h
--- include/haproxy/quic_tls.h.orig
+++ include/haproxy/quic_tls.h
@@ -140,7 +140,7 @@ static inline const EVP_CIPHER *tls_aead(const SSL_CIP
return EVP_aes_128_gcm();
case TLS1_3_CK_AES_256_GCM_SHA384:
return EVP_aes_256_gcm();
-#if !defined(OPENSSL_IS_AWSLC) && (!defined(LIBRESSL_VERSION_NUMBER) ||
LIBRESSL_VERSION_NUMBER >= 0x4000000fL)
+#if !defined(OPENSSL_IS_AWSLC)
/* WT: LibreSSL has an issue with CHACHA20 running in-place till 3.9.2
* included, but the fix is already identified and will be merged
* into next major version. Given that on machines without AES-NI
