search

userver-framework / userver

Production-ready C++ Asynchronous Framework with rich functionality
https://userver.tech
Apache License 2.0
2.3k stars 262 forks source link

support WolfSSL #498

Open segoon opened 4 months ago

segoon commented 4 months ago

OpenSSL is thread safe in general, but it doesn't guarantee anything for the same object - working with the same BIO/SSL_CTX from multiple threads is not safe at all. It leads to being unable to read/write from the same SSL socket from 2 coroutines (unlike TCP socket - you CAN read/write from 2 coroutines simultaneously at the same time).

WolfSSL seems to provide the needed guarantees. We need its support, probably via OpenSSL compatability layer.

theg4sh commented 3 months ago

I have briefly investigated the issue. wolfSSL distributes its own openssl/ directory with header files replacing those of the original OpenSSL. Given this, the migration to wolfSSL appears to be relatively straightforward, as it involves pre-inserting the include path to the library headers during the compilation process of an executable.

However, there is a need for further investigation regarding libraries distributed with the server. In particular, simply integrating a wolfSSL implementation in the core/universal components does not eliminate the requirement for installing the original OpenSSL library in the system, for example, for PostgreSQL. I have not delved too deeper into the wolfSSL headers, but it's suficite to say that builded .a/.so files will not completely replaces the original OpenSSL library as the wolf's library lacks of certain exporting symbols (due to its #define-ing OpenSSL's function names).

By the way, I'm making some progress on this issue. At the moment, I'm stuck on describing the CMakeFiles. Does any documentation on the userver.tech that describes the rules for the location of CMake files for libraries? It would be great if there provides any example of "how to download external library sources when certain flags are enabled" :)