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