вт, 18 июл. 2023 г. в 09:14, Willy Tarreau <w...@1wt.eu>: > Hi Andrew, > > On Tue, Jul 18, 2023 at 06:26:45AM +0000, Hopkins, Andrew wrote: > > Willy you're correct. AWS-LC does have support for the QUIC primitives > > HAProxy needs, we just need to fix some of the names [1] in either > HAProxy's > > code or AWS-LC in a follow up change. > > OK, thanks for confirming :-) > > 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)" >
AWSLC_VERSION_NAME ? aws-lc/include/openssl/base.h at 1dd5cf92e96edd4092bc307b14969dae5eaaa507 · aws/aws-lc (github.com) <https://github.com/aws/aws-lc/blob/1dd5cf92e96edd4092bc307b14969dae5eaaa507/include/openssl/base.h#L194> > 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. > > > 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. > > > Willy that's an interesting idea for library name conflict avoidance. I > did > > not know that's how quictls solved this problem, it seems like it would > work > > for simple applications with only one dependency on libcrypto (such as > > HAProxy). However, I don't think it would solve the issue of transitive > > dependencies mixing libcrypto implementations, e.g. an application > depends on > > 2 libraries that each depend on libcrypto, if one library moves to > AWS-LC the > > application will get symbol conflicts. > > Sure, but that application couldn't work otherwise anyway if some of > its dependencies rely on openssl's libcrypto, because if you replace > it with yours it'll get a different one than the one that was expected > by all the macros, struct definitions and inline funtions anyway. That's > already the problem we've faced with quictls: some applications with many > dependencies (e.g. curl) need to have all these dependencies rebuilt > against it anyway, so the application and its dependencies need to be > explicitly built against the new lib. And at least with a distinct > version number you don't need to rebuild the whole system, only the > components that directly depend on aws-lc and their dependencies. This > also allows to know better what depends on what. > > Just my two cents, > Willy > >
