On Tue, Jul 18, 2023 at 09:11:33AM +0200, Willy Tarreau wrote: > I'll let the SSL maintainers check all this, but my sentiment is that in > general if there are differences between the libs, it would be better if > we have a special define for this one as well. It's easier to write and > maintain "#if defined(OPENSSL_IS_BORINGSSL) || defined(OPENSSL_IS_AWSLC)" > than making it appear sometimes as one of them, sometimes as the other. > That's what we had a long time ago and it was a real pain, every single > move in any lib would cause breakage somewhere. Being able to reliably > identify a library and handle its special cases is much better. I agree, we could even add a build option OPENSSL_AWSLC=1 like we've done with wolfssl, since this is a variant of the Openssl API. Then every supported features could be activated with the HAVE_SSL_* defines in openssl-compat.h. Discovering the features with libreSSL and boringSSL version defines was a real mess, we are probably going to end up with a matrix of features supported by different libraries.
I'm seeing multiple defines that can be useful in haproxy: - OPENSSL_IS_AWSLC could be used as Willy said, that could enough and we maybe won't need the build option. - OPENSSL_VERSION_NUMBER it seems to be set to 0x1010107f but is this 100% compatible with the openssl 1.1.1 API? - AWSLC_VERSION_NUMBER_STRING It seems to be the OPENSSL_VERSION_TEXT counterpart but I don't see the equivalent as a number, in OpenSSL there is OPENSSL_VERSION_NUMBER which is used for doing #if (OPENSSL_VERSION_NUMBER >= 0x1010107f) in the code for example, this is really important for maintenance if we want to support multiple versions of aws-lc. - AWSLC_API_VERSION maybe this would be enough instead of the VERSION_NUMBER. We could activate the HAVE_SSL_* defines using OPENSSL_VERSION_NUMBER and this. > > To Alex's concern on API compatibility: yes AWS-LC is aiming to provide a > > more stable API. We already run integration tests with 6 other projects [2] > > including HAProxy. This will help ensure API compatibility going forward. > > What is your specific concern with ABI compatibility? Are you looking to > > take > > the haproxy executable built with OpenSSL libcrypto/libssl and drop in > > AWS-LC > > without recompiling haproxy? Or do that between AWS-LC libcrypto/libssl > > versions? > > I personally have no interest in cross-libs ABI compatibility because > that does not make much sense, particularly when considering that Openssl > does not support QUIC so by definition there will be many symbol-level > differences. Regarding aws-lc's libs over time, yes for the users it > would be desirable that within a stable branch it's possible to update > the library or the application in any order without having to rebuild > the application. We all know that it's something that only becomes > possible once the lib stabilizes enough to avoid invasive backports in > stable branches. I don't know what the current status is for aws-lc's > stable branches at the moment. > Agreed, cross-libs ABI is not useful, but the ABI should remain stable between minor releases so the library package could be updated without rebuilding every software that depends on it. Regards, -- William Lallemand
