I suggest to submit (i.e. send to mailing list as mentioned in
CONTRIBUTING) changes in src/build-ssl.sh separately. Those changes are
good and they do not affect any further steps.
nowadays we do not benefit from echo "${AWS_LC_VERSION}" > "${HOME}
/opt/.aws_lc-version"
we used to use that for travis-ci caching earlier, today some people still
use it for local caching
as for further steps, there were several ideas
1) add aws-lc to push based vtest
2) add aws-lc to weekly ci
3) add dedicated USE_OPENSSL_AWSLC (similar to USE_OPENSSL_WOLFSSL)
чт, 17 авг. 2023 г. в 00:49, Hopkins, Andrew <and...@amazon.com>:
> 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>:
>
> 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
>
>
