Question: Does wolfssl vcpkg port currently build with HAVE_EX_DATA set by default

[cppdev123]

trafficstars

I'm building a library for async io and networking for c++ 20 like asio but prefers coroutines over handlers. Among other things there is an async ssl support with a ssl backend selected at runtime. There are currently two backends : openssl and wolfssl. From experiencing with both I find wolfssl somehow easier for async stuff since it is very easy to use custom io functions where in openssl it was not possible until version 1.1 But for wolfssl backend the macro HAVE_EX_DATA must be defined and I had to define it manually for windows and linux builds. I'm currently willing to port the library to vcpkg and use wolfssl as an optional dependency however I can't see in wolfssl port file a feature to enable this macro or is it enabled by default ?

[cppdev123]

currently the macros added are NO_WOLFSSL_STUB, HAVE_SNI and HAVE_EX_DATA HAVE_SNI is essential since some sites will not accept the ssl connection without setting the host name NO_WOLFSSL_STUB prevents link error due to duplicate symbols when using both openssl and wolfssl by the same application

[embhorn]

Hi @pubg-hacks

Thanks for your kind words regarding the wolfSSL Async support!

I am guessing you are already using our vcpkg install: https://github.com/wolfSSL/wolfssl/blob/2eee35ef8f313bc047000f857c1b2620cb519644/INSTALL#L239-L256

Surely there is a method for configuring a library before installing with vcpkg. I'll check with the team.

[embhorn]

I did a quick search through the vcpkg docs, and this sounds promising: https://vcpkg.io/en/docs/maintainers/ports/vcpkg-cmake/vcpkg_cmake_configure.html

[embhorn]

Hmm... Maybe that wouldn't work. The below makes it sounds like vcpkg has not fully solved the issue of custom configs for vcpkg libraries.

https://vcpkg.io/en/docs/about/faq.html

Can I use my own/specific flags for rebuilding libs? Yes. In the current version, there is not yet a standardized global way to change them, however you can edit individual portfiles and tweak the exact build process however you'd like. By saving the changes to the portfile (and checking them in), you'll get the same results even if you're rebuilding from scratch in the future and forgot what exact settings you used.

[cppdev123]

From what I saw in the docs there are currently two ways to overcome this: 1- Add a patch to wolfssl portfile.cmake to add desired macros but this will work locally only 2- Wolfssl should be updated to use vcpkg features to enable multiple configuration at compile time. These features are transformed to macros by porfile.cmake and the build continues as usual. There is an explanation for it here: https://vcpkg.io/en/docs/maintainers/vcpkg_check_features.html for example there may be features to enable aesni, sni, ... this is not currently possible to enable with vcpkg without patching the library

[embhorn]

Hi @pubg-hacks

That sounds like a great option. If you were willing to implement the changes, we could open PR in vcpkg to get it merged in.

It would be great if there were a general purpose config, similar to what we did for the STM32 Cube: https://github.com/wolfSSL/wolfssl/blob/master/IDE/STM32Cube/default_conf.ftl

[cppdev123]

I tried adding features support to vcpkg builds but the current commit does not seem to compile with vcpkg I made a new portfile.cmake and used the current commit:

vcpkg_from_github(
    OUT_SOURCE_PATH SOURCE_PATH
    REPO wolfssl/wolfssl
    REF 2a96d62
    SHA512 f6ae7a36da9bbf63add662a482a1fa6bddb9327860166801c204fe2054d693b2156344c225a1e61b025abe49dff8870793384950dbc47a4a948985f82646758e
    HEAD_REF master
    PATCHES
      wolfssl_pr5529.diff
    )

but the patch was not applicable and gave an error and it seems it is already applied in wolfssl so I built without the patch:

vcpkg_from_github(
    OUT_SOURCE_PATH SOURCE_PATH
    REPO wolfssl/wolfssl
    REF 2a96d62
    SHA512 f6ae7a36da9bbf63add662a482a1fa6bddb9327860166801c204fe2054d693b2156344c225a1e61b025abe49dff8870793384950dbc47a4a948985f82646758e
    HEAD_REF master
#    PATCHES
#      wolfssl_pr5529.diff
    )

But I'm always getting an error in wolfcrypto/src/evp.c in the lines 6728 and 6729 because uint32_t is not defined! I could add include stdint.h but I don't know if this is due to configuration on my side or it is an error and the current commit does not support being built with vcpkg ?

[cppdev123]

After adding stdint.h include to wolfcrypto/src/evp.c the build completed but with this option -DWOLFSSL_OPENSSLEXTRA=yes being set by default which is not what I want so I removed it and I got an error in wolfcrypto/src/asn.c in this code block:

        /* Parse and store the issuer name. */
        dcrl->issuerSz = GetASNItem_Length(dataASN[CRLASN_IDX_TBS_ISSUER],
                            buff);
        dcrl->issuer   = (byte*)GetNameFromDer((byte*)GetASNItem_Addr(
                            dataASN[CRLASN_IDX_TBS_ISSUER], buff),
                            (int)dcrl->issuerSz);
        /* Calculate the Hash id from the issuer name. */
        ret = CalcHashId(GetASNItem_Addr(dataASN[CRLASN_IDX_TBS_ISSUER], buff),
                dcrl->issuerSz, dcrl->issuerHash);
        if (ret < 0) {
            ret = ASN_PARSE_E;
         }

because issuerSz and issuer is defined only in their struct when building with OPENSSL_EXTRA enabled so I surrounded this code with #ifdef OPENSSL_EXTRA ... #endif and the build completed. Is this intended or I'm having -DWOLFSSL_OPENSSLEXTRA=yes can no longer removed ? I recall that this used to be off by default

[cppdev123]

after trials with vcpkg features and portfile.cmake it turned out that vcpkg will set features as follows "-DFEATURE=ON/OFF" while wolfssl uses "yes/no" instead of "ON/OFF" and it seems to be impossible to build a list inside portfile.cmake so had to edit CmakeLists.txt to use camke's option() with boolean types for at least WOLFSSL_SNI, WOLFSSL_EX_DATA and WOLFSSL_NO_STUB

[cppdev123]

I opened the pull request https://github.com/wolfSSL/wolfssl/pull/5598 after transforming vcpkg ON/OFF to yes/no