Yes, what are the next steps? I updated my test PR with the latest changes from HAProxy master and it is still passing [1]. With a cached AWS-LC build the HAProxy build + test takes 2 minutes. Attached are the updated patch files, I can also combine them since they’re both small.
For the defines: we already have OPENSSL_IS_AWSLC and I agree that’s reasonable to use if there is a spot we need to branch on, but the goal is not to need it. For the OPENSSL_VERSION_NUMBER we are currently not 100% 1.1.1 API compatible, we are working to improve that so other projects can easily migrate. [2] will make the version string behavior match OpenSSL’s. We are compatible for HAPRoxy’s current use of OpenSSL after [3], [4], [5] were merged in. [1] https://github.com/andrewhop/haproxy/pull/1 [2] https://github.com/aws/aws-lc/pull/767 [3] https://github.com/aws/aws-lc/pull/1032 [4] https://github.com/aws/aws-lc/pull/1055 [5] https://github.com/aws/aws-lc/pull/1070 From: Илья Шипицин <chipits...@gmail.com> Date: Wednesday, August 9, 2023 at 11:26 PM To: William Lallemand <wlallem...@haproxy.com> Cc: Willy Tarreau <w...@1wt.eu>, "Hopkins, Andrew" <and...@amazon.com>, Aleksandar Lazic <al-hapr...@none.at>, "haproxy@formilux.org" <haproxy@formilux.org> Subject: RE: [EXTERNAL] [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. shall we unfreeze this activity? вт, 18 июл. 2023 г. в 10:46, William Lallemand <wlallem...@haproxy.com<mailto:wlallem...@haproxy.com>>: 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
0001-BUILD-ssl-Build-with-new-cryptographic-library-AWS-LC.patch
Description: 0001-BUILD-ssl-Build-with-new-cryptographic-library-AWS-LC.patch
0002-Add-build-cache-for-AWS-LC.patch
Description: 0002-Add-build-cache-for-AWS-LC.patch
