Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support WolfSSL #498

Open
segoon opened this issue Feb 29, 2024 · 1 comment · May be fixed by #523
Open

support WolfSSL #498

segoon opened this issue Feb 29, 2024 · 1 comment · May be fixed by #523
Labels
big A big feature help wanted We would appreciate PR

Comments

@segoon
Copy link
Collaborator

segoon commented Feb 29, 2024

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.

@segoon segoon added the help wanted We would appreciate PR label Feb 29, 2024
@theg4sh
Copy link
Contributor

theg4sh commented Mar 28, 2024

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

theg4sh added a commit to theg4sh/userver that referenced this issue Apr 14, 2024
closes userver-framework#498

This PR provides minimal changes which replaces internal usage of openssl.
It does not checked for other libraries used in userver.
Some openssl features does not implemented by wolfssl itself.
(has found some typos during investigation, see wolfSSL/wolfssl#7423).

BTW, wolfssl v5.7.0-stable requires few small patches which also
included into the PR.

Finally, "short path" to support wolfssl is not available, because of the lib does not implements some of used functions. It also does not provide `ENGINE_*`, but have not been tried with wolfengine lib yet.

PR is building with commands:
```
mkdir -p build_debug
cd build_debug

cmake \
  -Wdev \
  -DCMAKE_CXX_COMPILER=clang++-17 \
  -DUSERVER_FEATURE_WOLFSSL=ON \
  -DUSERVER_DOWNLOAD_PACKAGE_WOLFSSL=ON \
  -DUSERVER_FEATURE_GRPC=OFF \
  -DUSERVER_FEATURE_POSTGRESQL=OFF \
  -DUSERVER_FEATURE_MYSQL=OFF \
  -DUSERVER_FEATURE_STACKTRACE=OFF \
  -DUSERVER_FEATURE_CLICKHOUSE=OFF \
  -DUSERVER_USE_LD=lld \
  ..
```

Patch might be re-applied with command:
```(test -d build_debug/_deps/wolfssl-src && cd build_debug/_deps/wolfssl-src && git checkout -- .)```

Final error will be attached in comments to this PR.
Help needed.
@theg4sh theg4sh linked a pull request Apr 14, 2024 that will close this issue
@apolukhin apolukhin added the big A big feature label Apr 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
big A big feature help wanted We would appreciate PR
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants