[Bug]: 5.8.0 does not compile on Windows, if WOLFSSL_USER_IO is defined

[vaintroub]

Contact Details

No response

Version

5.8.0

Description

It is MariaDB.

We do not use ./configure. We do not use Visual Studio solution. We use (our own) CMake, cross-plattform, and we do define WOLFSSL_USER_IO in the user_settings.h header file, because we already have our own IO level. That fails on Windows since the last release, with errors and warnings like

'INVALID_SOCKET': undeclared identifier
'INVALID_SOCKET': undeclared identifier
'INVALID_SOCKET': undeclared identifier
'INVALID_SOCKET': undeclared identifier
'InetPton' undefined; assuming extern returning int
'htons' undefined; assuming extern returning int
'closesocket' undefined; assuming extern returning int
'AF_INET': undeclared identifier
'AF_INET': undeclared identifier

I see, there is an effort to avoid including winsock.h or winsock2.h, when including windows.h .
If you do this, the above winsock definitions still need to come from some other place. Or else, this code should not be compiled if WOLFSSL_USER_IO is given

Reproduction steps

No response

define WOLFSSL_USER_IO when compiling on Windows

Relevant log output

1>E:\10.6\extra\wolfssl\wolfssl\src\bio.c(2876,31): error C2065: 'INVALID_SOCKET': undeclared identifier
1>(compiling source file 'src/ssl.c')
1>E:\10.6\extra\wolfssl\wolfssl\src\bio.c(2882,31): error C2065: 'INVALID_SOCKET': undeclared identifier
1>(compiling source file 'src/ssl.c')
1>E:\10.6\extra\wolfssl\wolfssl\src\bio.c(3033,37): error C2065: 'INVALID_SOCKET': undeclared identifier
1>(compiling source file 'src/ssl.c')
1>E:\10.6\extra\wolfssl\wolfssl\src\bio.c(3033,34): warning C4389: '!=': signed/unsigned mismatch
1>(compiling source file 'src/ssl.c')
1>E:\10.6\extra\wolfssl\wolfssl\src\bio.c(3035,21): warning C4013: 'closesocket' undefined; assuming extern returning int
1>(compiling source file 'src/ssl.c')
1>E:\10.6\extra\wolfssl\wolfssl\src\bio.c(3225,28): error C2065: 'INVALID_SOCKET': undeclared identifier

[kareem-wolfssl]

Hi @vaintroub ,

Thanks for the report, my colleague will be reviewing this further.

Please share exactly which toolchain/build environment you are using CMake with.

[gojimmypi]

Hi @vaintroub

I realize you are not using Visual Studio, nor ./configure on Windows... but I have some ideas that might be of some help: I've been recently working with the Open Watcom V2 on Windows, building with the Visual Studio CMake.

Platform-specific files of interest: wolfssl/wolfio.h (docs) and wolfssl/wolfcrypt/settings.h. See also Porting Guide.

On a related note: When building the C# wrapper, there's a Windows ws2_32.lib that's added as an additional dependency. But as you mentioned it is cross platform, I'd need to know the target if not Windows. For Watcom, see the two lines, below:

  library ws2_32.lib ^
  library clib3r.lib

I'll be able to help more once I know your specifics, but in the meantime here's an example on Windows using Watcom compiler with VS CMake that may be helpful to you:

Environment

From a Visual Studio Developer Command Prompt (only for the CMake)

set WATCOM=C:\watcom
set PATH=%WATCOM%\binnt;%WATCOM%\binw;%PATH%
set INCLUDE=%WATCOM%\h;%WATCOM%\h\nt
set EDPATH=%WATCOM%\eddat
set WIPFC=%WATCOM%\wipfc
set LIB=%WATCOM%\lib386;%WATCOM%\lib386\nt

Configure:

rmdir /s /q .\build-watcom

cmake -B build-watcom -G "Watcom WMake" ^
  -DCMAKE_C_FLAGS="-DWOLFSSL_DLL -DBUILDING_WOLFSSL" ^
  -DWOLFSSL_DEBUG_CERTS=YES ^
  -DCMAKE_SYSTEM_NAME=Windows ^
  -DCMAKE_EXECUTABLE_SUFFIX=.exe ^
  -DCMAKE_SYSTEM_PROCESSOR=i386 ^
  -DCMAKE_VERBOSE_MAKEFILE=TRUE ^
  -DWOLFSSL_ASM=NO ^
  -DWOLFSSL_EXAMPLES=YES ^
  -DWOLFSSL_CRYPT_TESTS=NO ^
  -DWOLFSSL_SINGLE_THREADED=YES ^
  -DBUILD_SHARED_LIBS=NO ^
  -DCMAKE_POLICY_DEFAULT_CMP0136=NEW ^
  -DCMAKE_WATCOM_RUNTIME_LIBRARY=SingleThreaded
if errorlevel 1 (
    echo "Config 2 failed!"
    exit /b
)
cmake --build build-watcom --target client || (echo "Build 2 failed!" && exit /b)
call wlink_dll.bat

DLL linker

cd C:\workspace\wolfssl-pr-cert\build-watcom

wlink name wolfssl.dll system nt_dll debug all option implib=wolfssl.lib ^
  file { ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\hmac.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\hash.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\cpuid.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\kdf.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\random.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\sha256.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\rsa.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\sp_int.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\aes.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\sha.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\sha512.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\logging.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\wc_port.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\error.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\wc_encrypt.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\signature.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\wolfmath.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\memory.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\dh.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\asn.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\coding.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\poly1305.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\pwdbased.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\pkcs12.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\chacha.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\chacha20_poly1305.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\integer.c.obj ^
    CMakeFiles\wolfssl.dir\wolfcrypt\src\ecc.c.obj ^
    CMakeFiles\wolfssl.dir\src\internal.c.obj ^
    CMakeFiles\wolfssl.dir\src\wolfio.c.obj ^
    CMakeFiles\wolfssl.dir\src\keys.c.obj ^
    CMakeFiles\wolfssl.dir\src\ssl.c.obj ^
    CMakeFiles\wolfssl.dir\src\ocsp.c.obj ^
    CMakeFiles\wolfssl.dir\src\tls.c.obj ^
    CMakeFiles\wolfssl.dir\src\tls13.c.obj ^
  } ^
  library ws2_32.lib ^
  library clib3r.lib

cd ..

Test client app

build-watcom\examples\client\client.exe -v 4 -h localhost -p 12345

[vaintroub]

Sorry, I'm not using any Watcom or exotic compilers. The build is using MSVC in this case. We are not using Visual Studio solution nor we're using ./configure. Our project is CMake, so we're using CMake consistently. We're building your code with our CMakeLists.txt, because we have some special needs.

The context is MariaDB, which uses WolfSSL sometimes, mostly on Windows

Ok, if you like to reproduce as I, or CI did, clone https://github.com/mariadb/server , checkout this commit 842e1c5ca1b0941ba03ac49d457817f22ee7a6e6

then, from the checkout directory, in cmd.exe, or in powershell

mkdir bld
cd bld
cmake ..
cmake --build . --target wolfssl

You'd need some resent bison.exe in path and git to checkout submodules, or cmake will fail at configuration step.

https://buildbot.mariadb.org/#/builders/234/builds/40565 is what we see on our CI, when we try to use latest WolfSSL release.

I'm unsure why you need all these details. I think we shared them before.
It would be nice, if WolfSSL did not break our build every time new release comes out, and checked that Windows actually builds, and does not produce warnings, with newest MSVC, and ideally clang-cl, but we kinda already learned to live with it, every time some new workaround is added, and this time it is not an exception

[vaintroub]

If you like to see what I see, easily, without MariaDB build, you can just add the mentioned define, and build with your VS solution

diff --git a/IDE/WIN/user_settings.h b/IDE/WIN/user_settings.h
index a1011abf8..e96d2fb3d 100644
--- a/IDE/WIN/user_settings.h
+++ b/IDE/WIN/user_settings.h
@@ -7,6 +7,7 @@
 #endif

 #define USE_WOLFSSL_IO
+#define WOLFSSL_USER_IO
 #define HAVE_AESGCM
 #define WOLFSSL_TLS13
 #define HAVE_HKDF

and then try to build wolfssl-VS2022.vcxproj

Sorry, if I did not make it clear before, I thought 5.8.0 does not compile on Windows, if WOLFSSL_USER_IO is defined should be enough to get an idea how to reproduce.

[gojimmypi]

Hi @vaintroub that's all helpful information, thank you.

I'm unsure why you need all these details. I think we shared them before.

I was not aware of the details. This issue is the first I've heard of your topic. I do see that you had and issue earlier: #8430

if WOLFSSL_USER_IO is defined should be enough to get an idea how to reproduce.

Certainly if you define wolfssl_user_io with no implementation, I'd expect that errors would occur. I'm assuming you have your custom I/O callbacks implemented in the MariaDB? Apologies, but I'm not familiar with it, so if you could kindly point me in the direction of the custom I/O code location and how you are initializing them in wolfSSL, it would be a great time saver rather than me digging in on my own.

Ideally it would be great if you could provide a small reproducer code example to illustrate the issue.

Thank you, I look forward to helping you with this.

[vaintroub]

If you follow the steps to compile WolfSSL in MariaDB, which I outlined above, then you can easily find the place we use IO callbacks.

switch to the cloned directory, and issue git grep wolfSSL_Set to find the places. It should spit out something like this

C:\path\to\server> git grep wolfSSL_Set
vio/viossl.c:  wolfSSL_SetIOReadCtx(ssl, vio);
vio/viossl.c:  wolfSSL_SetIOWriteCtx(ssl, vio);
vio/viosslfactories.c:   wolfSSL_SetIORecv(ssl_fd->ssl_context, wolfssl_recv);
vio/viosslfactories.c:   wolfSSL_SetIOSend(ssl_fd->ssl_context, wolfssl_send);

And here is where we do define IO callbacks. And this is why it is OK for us to define WOLFSSL_USER_IO. You can open file, examine implementations of wolfssl_send and wolfssl_recv, they are good. They worked for us since 2019.

The problem however is not the callbacks. The problem is that on Windows, even with WOLFSSL_USER_IO, WolfSSL uses socket code without including winsock.h or winsock2.h, and makes sure windows.h does not include it either. And this is why compilation fails

[gojimmypi]

Hi @vaintroub thanks for your patience in explaining the problem.

Please try this:

Given the v5.8.0 user_settings.h:

Remove the #define USE_WOLFSSL_IO on line 9 and add these lines in place of that:

#define WOLFSSL_USER_IO
#define WOLFSSL_NO_SOCK
#define INVALID_SOCKET ((SOCKET_T)(-1))

[vaintroub]

Thanks, I already know this workaround MariaDB/server@685e45f

I would like WolfSSL to fix it properly.

[gojimmypi]

Please see #9008 - will that work for you?

[vaintroub]

Thanks It is step in the right direction, but I believe something like patch is more appropriate.

Why I think so

• We do not really use that v5.8.0 user_settings.h, we generate , using CMake's configure_file, our own from this one . It was just easier for me to use this header to explain the problem, in case you would not like to replicate MariaDB build. And the problem is not in VS project header, it is strictly speaking not part of the library, it is an example, one of very many in IDE directory.
  But, wolfio.h is very much part of the core library, and WOLFSSL_USER_IO automatically define WOLFSSL_NO_SOCK should be there, so that users do not get closesocket() not defined warning.

• There is no need to redefine INVALID_SOCKET. This definition belongs to Windows headers. Throughout WolfSSL code SOCKET_INVALID is used

diff --git a/wolfssl/wolfcrypt/wc_port.h b/wolfssl/wolfcrypt/wc_port.h
index a33fbf46f..9e753b835 100644
--- a/wolfssl/wolfcrypt/wc_port.h
+++ b/wolfssl/wolfcrypt/wc_port.h
@@ -1119,7 +1119,11 @@ WOLFSSL_ABI WOLFSSL_API int wolfCrypt_Cleanup(void);
         #endif
     #endif
     #ifndef SOCKET_INVALID
-        #define SOCKET_INVALID INVALID_SOCKET
+        #ifndef INVALID_SOCKET
+            #define SOCKET_INVALID ((SOCKET_T)(-1))
+        #else
+            #define SOCKET_INVALID INVALID_SOCKET
+        #endif
     #endif
 #else
     #ifndef SOCKET_T
diff --git a/wolfssl/wolfio.h b/wolfssl/wolfio.h
index de45a18b5..c5503cf7b 100644
--- a/wolfssl/wolfio.h
+++ b/wolfssl/wolfio.h
@@ -547,6 +547,10 @@ WOLFSSL_API  int wolfIO_RecvFrom(SOCKET_T sd, WOLFSSL_BIO_ADDR *addr, char *buf,
 
 #endif /* USE_WOLFSSL_IO || HAVE_HTTP_CLIENT */
 
+#if defined(WOLFSSL_USER_IO) && !defined(WOLFSSL_NO_SOCK)
+  #define WOLFSSL_NO_SOCK
+#endif
+
 #ifndef WOLFSSL_NO_SOCK
 #ifdef USE_WINDOWS_API
     #ifndef CloseSocket

[gojimmypi]

Hi @vaintroub and thanks very much for all your feedback and suggestions.

There is no need to redefine INVALID_SOCKET. This definition belongs to Windows headers

Agreed.

We do not really use that v5.8.0 user_settings.h, we generate , using CMake's configure_file

Ah, good. Thanks for the confirmation.

the problem is not in VS project header

Agreed. And the solution should not be there, either.

WOLFSSL_USER_IO automatically define WOLFSSL_NO_SOCK should be there

At one point I would have agreed, but I reached out to @JacobBarthelmeh internally and he stated:

I think WOLFSSL_NO_SOCK is a workaround for an unfixed version of wolfSSL
I don't think it should be required with WOLFSSL_USER_IO once wolfSSL is fixed
All WOLFSSL_USER_IO should do in my opinion is handling of the IO callbacks, not telling wolfSSL that there is no socket support with the build

After considering those comments, I agree that enabling the WOLFSSL_USER_IO for custom user send and receive functions should have nothing to do with whether there's socket support or not.

Given all this, I've made some revisions to #9008 - please let know what you think & if those changes work in your environment.

Warm Regards,

Jim