Dear All, Please find enclosed a patch in "diff -cr orig patched" format, applying to stunnel4.34 as found here ftp://stunnel.mirt.net/stunnel/. This patch mainly addresses compilation and unicode issues for Windows CE targets + ONE critical issue preventing stunnel to service anything (!).
I use MS EVC 4sp2 compiler with WCE 420 SDK, on a vista host platform. Once debugged the code works fine on WM6 HTC smartphones. Should work on WM5. It needs a windows CE openssl lib (I recompiled MY patched version of openssl 1.0.0a successfully: I will have to log a patch to those gentlemen, hoping that they are open to integrate it, something not so obvious in the past).
I will later post here a link to my patch for openssl 100a pointing to the openssl mailing list. THIS OPENSSL PATCH IS ESSENTIAL : with my older version of openssl 098pre_j for wce, stunnel does not work anymore (it crashes after first cnx).
The present stunnel patch addresses the following issues :
************* I] COMPILATION FAILURES
1/ on common.h "EINVAL redefinition" : in fact the compile options WX (see evc.mak) does not tolerate any warning : The MS evc420 compiler ALWAYS issues a warning on this symbol redefinition. Michal and I are dealing with it since month... But, considering that NEITHER Exxx error codes are used in stunnel, I suggest that in fact ALL these redef should be suppressed.
TODO: In the future a proper rewrite of code in log.c, where hardcoded values of WSA error codes are used instead of symbolic constant, will have to be done.
2/ client.c CreateProcess is a UNICODE function: code was ascii only. Code has been adapted to work in unicode.
3/ evc.mak path to new openssl lib has been redefined. proper location for the libs in openssl tree has been set in the make-install block (although this block is presently USELESS and needs a complete rewrite).
4/ gui.c All code using hmainmenu is OFF under winCE. So some new lines involving it were not compiling.
5/ options.c
linger_val.l_linger and linger_val.l_onoff require ushort values. Strict type checking of the compiler required a proper cast to ushort of the r-values.
stralloc uses "strdup": on Win32 and winCE strdup is _strdup (!).
6/ prototypes.h : _beginthread was defined as returning an int, an a long in sthread.c. After some checking in various documentations, long is the correct type, in particular because _beginthread can return the special error value "-1L". So that unsigned types are illogical. This simplifies the code in some locations, by saving some -now useless- casts.
7/ sthread.c
create_client: suppressed some useless cast to (long) for beginthread.
************* II] OPERATIONAL ERRORS (at run-time) This is a reminder of previous notification to the mailing list : due to beginthread improper code and/or use, It is presently IMPOSSIBLE for stunnel 434 to be used in production on WCE: it is just unable to service any...service. Nothing happens if, for example, you use it to connect to an https server. No log either !
I corrected the code with both Michal patch to gui.c and mine to sthread.c:
gui.c (Michal patch) : _beginthread was called with 0 as stacksize which, cumulated to an improper coding of sthread/beginthread, led to FAILURE of service thread creation.
sthread.c: _beginthread : now supports "0" stacksize value, leading to default linker stack size (1MB by default unless specified differently on the linker command line, something we do not yet perform but could).
************* III] MINOR IMPROVMENT _beginthread: added a log on critical event of "failure" to create a service thread. because I think it is a critical event, isn't it?
I hope you will find this patch useful. Thank you for your excellent work, Yours sincerely,
Pierre Delaage
Note : I use stunnel to establish a simple "vpn" between smartphones and a corporate linux server mainly for HTTPS/POPS/SMTPS support. Stunnel is very relevant in that matter, over solutions based on SSH (although we use also ssh), from a communication cost point of view : ssh establishes permanent socket between client and server, so that the communication is charged by the mobile network provider : and these charges are very expensive. On the contrary stunnel only establishes ssl sockets on demand so that financial charges are limited to strict necessary. Please note that stunnel brings "client based certificate authentication" to POP/SMTP mobile mail user agents which only BASICALLY supports SSL with server authentication, but NO client authentication, such as M$ Outlook for Mobile (unless you pay for an exchange server and exchange client licence). Here again stunnel is very relevant.
Note 2 : the strdup and unicode bug fixes should benefit also to the win32 (for PC) stunnel version for PC.