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

Reply via email to