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 > >
