tls: fixes for wolfssl + openssl combo builds #10322
Conversation
vszakats
changed the title
1. Add USE_WOLFSSL to the priority list in `lib/curl_ntlm_core.c` 2. Fix `lib/curl_ntlm_core.h` to respect backend priority, bringing this in sync with the above list and `lib/curl_ntlm_core.c` itself. 3. Allow enabling both wolfSSL and OpenSSL at the same time in `lib/Makefile.mk`. Update the logic to select the crypto-specific lib for ngtcp2. Ref: curl#10321 Closes curl#10322
vszakats
force-pushed
the
wolfssl-openssl-1
branch
from
3feffe1
to
41c9061
Compare
|
The reason it was the other way around though was because if OpenSSL came first (like it does in this PR) then |
|
I tend to think that if this combo isn't supported in all cases (which it isn't), we can hardly say it this is a supported combination. It also doesn't seem to be something much tested before. @elms commit says it adds wolfSSL support, but there's no mention of building in parallel with OpenSSL, so this was maybe something not tested or considered. To me the order picked seems to be the result of keeping changes at minimum while extending existing code. As for header confusion (picking the same header from the wrong project): if the header paths are setup correctly this should not happen because wolfSSL ones are referenced under (All of this is mostly guessing, my build attempts always failed with this combo.) |
|
wolfSSL provides an OpenSSL API, that curl partially uses to do some things. The only way we can build curl to use both OpenSSL and wolfSSL simultaneously is if they the two libraries do not share any symbols/function names, which would mean that wolfSSL's OpenSSL API would have to be disabled. That would then make the wolfSSL backend less feature rich. If someone insists on making that work, fine, but I'm not going to personally lose any sleep over us not supporting that. |
|
I plan to commit this as-is. This should help adding further fixes if someone is interested in doing them. It also brings |
1. Add `USE_WOLFSSL` to the TLS backend priority list in `lib/curl_ntlm_core.c`. 2. Fix `lib/curl_ntlm_core.h` to respect TLS backend priority, bringing it in sync with the above list and `lib/curl_ntlm_core.c` itself. Reported-by: Mark Roszko Ref: curl#10321 3. Allow enabling both wolfSSL and OpenSSL at the same time in `lib/Makefile.mk` bringing this in line with cmake/autotools builds. Update logic to select the crypto-specific lib for `ngtcp2`, which supports a single TLS backend at the same time. Closes curl#10322
In specific builds configs, cmake failed to build test `unit1600`,
due missing an OpenSSL (or wolfSSL) header.
The test code relies on `lib/curl_ntlm_core.h`, which in turn included
TLS library headers. But, dependency header directories are not setup
in cmake for tests, because they should not normally be needed.
The issue was hidden in most builds because TLS headers are usually
found under the system prefix. One counterexample is macOS + Homebrew
LibreSSL builds, where OpenSSL is purposefully unlinked from there to
avoid a mixup with LibreSSL that resides under its own prefix. It was
also hidden in autotools, possibly because it sets up header directories
globally, tests included.
The actual bug however is that `lib/curl_ntlm_core.h` should not include
TLS headers. None of its internal users need it, and `curl_ntlm_core.c`
included them already directly.
Fix it by deleting the TLS header includes from this internal header.
Fixes:
```
In file included from curl/tests/unit/unit1600.c:27:
curl/lib/curl_ntlm_core.h:32:12: fatal error: 'openssl/ssl.h' file not found
# include <openssl/ssl.h>
^~~~~~~~~~~~~~~
```
Ref: https://github.com/curl/curl/actions/runs/9912684737/job/27388041520#step:12:1694
Follow-up to 48eb71a #10322
Cherry-picked from #14097
Closes #14172
In specific builds configs, cmake failed to build test `unit1600`,
due missing an OpenSSL (or wolfSSL) header.
The test code relies on `lib/curl_ntlm_core.h`, which in turn included
TLS library headers. But, dependency header directories are not setup
in cmake for tests, because they should not normally be needed.
The issue was hidden in most builds because TLS headers are usually
found under the system prefix. One counterexample is macOS + Homebrew
LibreSSL builds, where OpenSSL is purposefully unlinked from there to
avoid a mixup with LibreSSL that resides under its own prefix. It was
also hidden in autotools, possibly because it sets up header directories
globally, tests included.
The actual bug however is that `lib/curl_ntlm_core.h` should not include
TLS headers. None of its internal users need it, and `curl_ntlm_core.c`
included them already directly.
Fix it by deleting the TLS header includes from this internal header.
Fixes:
```
In file included from curl/tests/unit/unit1600.c:27:
curl/lib/curl_ntlm_core.h:32:12: fatal error: 'openssl/ssl.h' file not found
# include <openssl/ssl.h>
^~~~~~~~~~~~~~~
```
Ref: https://github.com/curl/curl/actions/runs/9912684737/job/27388041520#step:12:1694
Follow-up to 48eb71a curl#10322
Cherry-picked from curl#14097
Closes curl#14172
Add
USE_WOLFSSLto the TLS backend priority list inlib/curl_ntlm_core.c.Fix
lib/curl_ntlm_core.hto respect TLS backend priority, bringing this in sync with the above list andlib/curl_ntlm_core.citself.Reported-by: Mark Roszko
Ref: openssl + wolfssl combo backend build broken #10321
Allow enabling both wolfSSL and OpenSSL at the same time in
lib/Makefile.mk. Update the logic to select the crypto-specific lib forngtcp2, where only one TLS backend is supported at the same time.Closes #10322