@deryck1031 what's the motivation of this request?

GnuTLS's LGPL license is probably the most challenging one if end users like to vendor and static linking all of the dependent 3rd party libs.

Would like to poll the reasons why gnutls was chosen instead of boringssl or openssl ? Thanks !

IIRC API stability of older OpenSSL releases. I think it's much better now. If you want to replace gnutls with openssl, post a patch.

If you want to replace gnutls with openssl, post a patch.

Would the desire by the scylla team be that GnuTLS still be supported in Seastar or would you accept that patch that completely removes it and replaces it with OpenSSL?

Furthermore, how "compatible" would you desire this patch to be against older versions of OpenSSL. Your statement about API stability is spot on and can cause implementors to have to write preprocessor conditionals in order to be compatible against multiple different versions of OpenSSL (thinking versions 1.0.2 and older). Writing against 1.1.1 and newer is easier as the API is significantly more stable (and those versions are still supported). The desire of course would be to not adversely effect any seastar user that happens to be running on older distros or using older versions of OpenSSL.

I also noticed in your documentation that a FIPS 140-2 certified OpenSSL library is used. Is this referencing your client or does the scylladb product have support for using OpenSSL for its TLS stack outside of seastar?

/cc @elcallio

If you want to replace gnutls with openssl, post a patch.

Would the desire by the scylla team be that GnuTLS still be supported in Seastar or would you accept that patch that completely removes it and replaces it with OpenSSL?

This type of question is very dangerous since it's easy for the maintainer to say "yes" (costs them nothing) and leave you stuck doing extra work.

Much better for you to build a case why an openssl replacement would be better.

Furthermore, how "compatible" would you desire this patch to be against older versions of OpenSSL. Your statement about API stability is spot on and can cause implementors to have to write preprocessor conditionals in order to be compatible against multiple different versions of OpenSSL (thinking versions 1.0.2 and older). Writing against 1.1.1 and newer is easier as the API is significantly more stable (and those versions are still supported). The desire of course would be to not adversely effect any seastar user that happens to be running on older distros or using older versions of OpenSSL.

I see openssl 3 was release 2 years ago so it's conceivable to support only that. If we can support 1.1.1 that's a bonus.

I expect most Seastar applications ship their libraries alongside so compatibility with very old releases isn't a priority.

I also noticed in your documentation that a FIPS 140-2 certified OpenSSL library is used. Is this referencing your client or does the scylladb product have support for using OpenSSL for its TLS stack outside of seastar?

We're using it for encryption at rest. From our point of view, unification of in-flight and at-rest encryption would be an improvement.

Hi again @avikivity ! I wanted to give you guys a heads up that we have been busy these last few months integrating OpenSSL with Seastar. It's not quite ready for us to upstream (there's some dependency clean up we need to do) but it's very close. If you want a sneak peak, the majority of the changes are here: https://github.com/redpanda-data/seastar/blob/v24.2.x/src/net/ossl.cc