[stunnel-users] public domain [PATCH] to stunnel 4.34 for Windows CE / Windows Mobile, "no service" CRITICAL bug and unicode bugs fixed

[Pierre DELAAGE]

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.




-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stunnel_patchTo_434.txt
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20100927/a78c9e13/attachment.txt>