date:20100316

RE: [openssl.org #2194] Unwanted dependencies to user32.dll

2010-03-16 Thread Kees Dekker via RT

> -Original Message-
> From: Andy Polyakov via RT [mailto:r...@openssl.org] 
> Sent: Tuesday, March 16, 2010 22:23
> To: Kees Dekker
> Cc: openssl-dev@openssl.org
> Subject: Re: [openssl.org #2194] Unwanted dependencies to user32.dll
> 
> > When building openSSL on Windows with:
> > 
> > *   CONFIG=VC-WIN64A or CONFIG=VC-WIN32
> > *   no-shared no-threads -DWINVER==0x0501 
> -D_CRT_NON_CONFORMING_SWPRINTFS
> > *   With Visual Studio 2005
> > 
> > I get dependencies to user32.dll, when using libeay32.lib, e.g:
> > 
> > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved 
> external symbol __imp__delet...@4
> > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved 
> external symbol __imp__deleteobj...@4
> > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved 
> external symbol __imp__getbitmapb...@12
> > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved 
> external symbol __imp__bit...@36
> > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved 
> external symbol __imp__getobje...@12
> > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved 
> external symbol __imp__selectobj...@8
> > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved 
> external symbol __imp__createcompatiblebit...@12
> > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved 
> external symbol __imp__getdevicec...@8
> > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved 
> external symbol __imp__createcompatibl...@4
> > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved 
> external symbol __imp__create...@16
> > 2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved 
> external symbol __imp__getuserobjectinformati...@20
> > 2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved 
> external symbol __imp__getprocesswindowstat...@0
> > 2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved 
> external symbol __imp__getdesktopwin...@0
> > 2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved 
> external symbol __imp__messageb...@16
> >  
> > These dependencies are unwanted for our application, since using 
> > user32.dll will result in Windows desktop exhaustion if too 
> many users 
> > are logged in to a Windows system (via a service) and use 
> our application.
> > I would like to have an option to prevent any interaction to UI 
> > (user32.dll) related code. Can you please add such option?
> >  
> > As far as I could see, the code in rand_win.c/cryptlib.c 
> are related to:
> > - OPENSSL_isservice(), which uses GetDesktopWindow(), 
> > GetProcessWindowStation(), GetUserObjectInformationW()
> > - and a number of functions in rand_win.c e.g. readscreen()
> > - readscreen() seems to be used only in RAND_SCREEN() and has some 
> > comments that the function exists only for backward 
> compatibility. If 
> > this compatibility can be turned off, much of the dependencies to 
> > user32.dll are removed then.
> >  
> > I don't know how to fix this. But I would like to share 
> some thoughts:
> > 
> > * Windows 2008/Vista does not allow to call MessageBox() if the
> >   calling process is a service (and running in session 0). So
> >   MessageBox() is only useful if a normal user, connected to an
> >   interactive Windows Desktop, will call openssl executables.
> 
> This is misconception. It's not like 2008/Vista does not 
> allow to call 
> MessageBox in service, it's just that you don't see nor can 
> you interact 

You are right. However, an invisible message box is not very useful for 
end-users. 
I agree that OPENSSL_isservice() cannot be changed, but you can decide to log 
an event always. So all if (OPENSSL_isservice()) can be removed. Or change it 
to a define for configure: OPENSSL_DO_EVENTLOG_REPORTING? The if 
(!OPENSSL_isservice()) prevents to do more things with user32.dll, and 
delayload will help in this region.

I'm not sure whether I understand the code in readscreen() correctly, but if 
the code is used for generating a random number, I would prefer not use 
functions from user32.dll but some other approach... (if that is possible)

> with it. Secondly [and more importantly!] openssl won't call 
> MessageBox 
> if it finds itself running in Windows service context. 
> Instead it will 
> log the message to event log.
> 
> > * I saw a lot of NT4 code.
> 
> What NT4 code? You must be referring to _WIN32_WINNT macro 
> sometimes set 
> to 0x400. It does not denote NT4-specific code, it denotes 
> that NT4 is 
> required *minimum*. Meaning that it targets *all* Windows versions 
> *past* 4: 2000, XP, 2003, Vista, 2008, 7, etc.

Example: rand_win.c, check on osverinfo.dwMajorVersion < 5 (i.e. NT4).
And all places, using GetVersion() >= 0x8000 points to Win9x code.
But, please ignore this remark. My key point is the dependency to user32.dll. 
Sorry for causing confusion.

> 
> > * Background information on desktop exhaustion:
> >   
> http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-h
eap-overview.aspx
> >   
>

Re: [openssl.org #2194] Unwanted dependencies to user32.dll

2010-03-16 Thread Andy Polyakov via RT

> When building openSSL on Windows with:
> 
> *   CONFIG=VC-WIN64A or CONFIG=VC-WIN32
> *   no-shared no-threads -DWINVER==0x0501 -D_CRT_NON_CONFORMING_SWPRINTFS
> *   With Visual Studio 2005
> 
> I get dependencies to user32.dll, when using libeay32.lib, e.g:
> 
> 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
> __imp__delet...@4
> 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
> __imp__deleteobj...@4
> 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
> __imp__getbitmapb...@12
> 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
> __imp__bit...@36
> 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
> __imp__getobje...@12
> 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
> __imp__selectobj...@8
> 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
> __imp__createcompatiblebit...@12
> 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
> __imp__getdevicec...@8
> 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
> __imp__createcompatibl...@4
> 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
> __imp__create...@16
> 2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol 
> __imp__getuserobjectinformati...@20
> 2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol 
> __imp__getprocesswindowstat...@0
> 2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol 
> __imp__getdesktopwin...@0
> 2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol 
> __imp__messageb...@16
>  
> These dependencies are unwanted for our application, since using 
> user32.dll will result in Windows desktop exhaustion if too many users 
> are logged in to a Windows system (via a service) and use our application.
> I would like to have an option to prevent any interaction to UI 
> (user32.dll) related code. Can you please add such option?
>  
> As far as I could see, the code in rand_win.c/cryptlib.c are related to:
> - OPENSSL_isservice(), which uses GetDesktopWindow(), 
> GetProcessWindowStation(), GetUserObjectInformationW()
> - and a number of functions in rand_win.c e.g. readscreen()
> - readscreen() seems to be used only in RAND_SCREEN() and has some 
> comments that the function exists only for backward compatibility. If 
> this compatibility can be turned off, much of the dependencies to 
> user32.dll are removed then.
>  
> I don't know how to fix this. But I would like to share some thoughts:
> 
> * Windows 2008/Vista does not allow to call MessageBox() if the
>   calling process is a service (and running in session 0). So
>   MessageBox() is only useful if a normal user, connected to an
>   interactive Windows Desktop, will call openssl executables.

This is misconception. It's not like 2008/Vista does not allow to call 
MessageBox in service, it's just that you don't see nor can you interact 
with it. Secondly [and more importantly!] openssl won't call MessageBox 
if it finds itself running in Windows service context. Instead it will 
log the message to event log.

> * I saw a lot of NT4 code.

What NT4 code? You must be referring to _WIN32_WINNT macro sometimes set 
to 0x400. It does not denote NT4-specific code, it denotes that NT4 is 
required *minimum*. Meaning that it targets *all* Windows versions 
*past* 4: 2000, XP, 2003, Vista, 2008, 7, etc.

> * Background information on desktop exhaustion:
>   
> http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx
>   
> 
>   and
>   http://blogs.technet.com/markrussinovich/archive/2010/02/24/3315174.aspx
>   
> 

As already implied, when executed in Windows service context, openssl is 
programmed to abstain from making user32 and gdi32 calls and won't 
interact with UI. But user32.dll is mapped and this does mean that some 
session memory is consumed, *but* *not* beyond absolute minimum implied 
by mere initialization of user32.dll. The only situation I can think of 
when resource exhaustion could be a problem is when a separate *process* 
is created for every user/connection. Is it your case? If not, then it 
shouldn't even be a concern. If yes, i.e. a separate *process* is 
created for every user/connection, then I'd suggest to modify 
OPENSSL_isservice() to immediately return 1(**) and /delayload:gdi32.dll 
/delayload:user32.dll and keep it is as private customization. A.

(*) For reference, most of Microsoft services have user32.dll mapped 
into their address spaces, meaning that they also consume at least some 
bare minimum.

(**) Alternative to returning 1 could be enumerating handles, 
identifying windowstation one, pulling and fi

Re: [openssl.org #2194] Unwanted dependencies to user32.dll

2010-03-16 Thread Yang Tse

2010/3/16, Kees Dekker via RT wrote:

>  *   I saw a lot of NT4 code. It may be worth to consider that Windows
> 2000 is not supported by Microsoft anymore for many years (see
> http://support.microsoft.com/lifecycle/?p1=3071). You may
> like to drop some ancient Windows flavors? It will save code too, e.g.
> dynamically loading DLLs on e.g. Windows 9x variants (also very ancient).

Two facts:
1) W2k has not reached yet the end of the MS extended support period.
2) MicrosoftUpdate is, regularly, still providing security updates
even for W2k professional.

I do not agree with unconditionally removing W9x and W2k support from
OpenSSL code base. Opt out, or opt in, conditional compilation support
would be a different matter.

-- 
-=[Yang]=-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2194] Unwanted dependencies to user32.dll

2010-03-16 Thread Kees Dekker via RT

Hi,

When building openSSL on Windows with:

*   CONFIG=VC-WIN64A or CONFIG=VC-WIN32
*   no-shared no-threads -DWINVER==0x0501 -D_CRT_NON_CONFORMING_SWPRINTFS
*   With Visual Studio 2005

I get dependencies to user32.dll, when using libeay32.lib, e.g:

2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
__imp__delet...@4
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
__imp__deleteobj...@4
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
__imp__getbitmapb...@12
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
__imp__bit...@36
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
__imp__getobje...@12
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
__imp__selectobj...@8
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
__imp__createcompatiblebit...@12
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
__imp__getdevicec...@8
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
__imp__createcompatibl...@4
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol 
__imp__create...@16
2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol 
__imp__getuserobjectinformati...@20
2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol 
__imp__getprocesswindowstat...@0
2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol 
__imp__getdesktopwin...@0
2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol 
__imp__messageb...@16

These dependencies are unwanted for our application, since using user32.dll 
will result in Windows desktop exhaustion if too many users are logged in to a 
Windows system (via a service) and use our application.
I would like to have an option to prevent any interaction to UI (user32.dll) 
related code. Can you please add such option?

As far as I could see, the code in rand_win.c/cryptlib.c are related to:
- OPENSSL_isservice(), which uses GetDesktopWindow(), 
GetProcessWindowStation(), GetUserObjectInformationW()
- and a number of functions in rand_win.c e.g. readscreen()
- readscreen() seems to be used only in RAND_SCREEN() and has some comments 
that the function exists only for backward compatibility. If this compatibility 
can be turned off, much of the dependencies to user32.dll are removed then.

I don't know how to fix this. But I would like to share some thoughts:
*   Windows 2008/Vista does not allow to call MessageBox() if the calling 
process is a service (and running in session 0). So MessageBox() is only useful 
if a normal user, connected to an interactive Windows Desktop, will call 
openssl executables.
*   I saw a lot of NT4 code. It may be worth to consider that Windows 2000 
is not supported by Microsoft anymore for many years (see 
http://support.microsoft.com/lifecycle/?p1=3071). You may like to drop some 
ancient Windows flavors? It will save code too, e.g. dynamically loading DLLs 
on e.g. Windows 9x variants (also very ancient).
*   Background information on desktop exhaustion: 
http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx 
and http://blogs.technet.com/markrussinovich/archive/2010/02/24/3315174.aspx

Met vriendelijke groet/Best regards,

Kees Dekker | senior software engineer, ERP LN Development | Infor |
Baron van Nagellstraat 89 | 3771 LK Barneveld | Phone +31 (0)342 428706 | Fax 
+31 (0)342 428796 | E-mail kees.dek...@infor.com







Hi,
 
When building openSSL on Windows with: 
 

CONFIG=VC-WIN64A or CONFIG=VC-WIN32no-shared no-threads -DWINVER==0x0501 -D_CRT_NON_CONFORMING_SWPRINTFSWith Visual Studio 2005
 
I get dependencies to user32.dll, when using libeay32.lib, e.g:
 
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__delet...@4
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__deleteobj...@4
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__getbitmapb...@12
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__bit...@36
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__getobje...@12
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__selectobj...@8
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__createcompatiblebit...@12
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__getdevicec...@8
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__createcompatibl...@4
2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__create...@16
2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol __imp__getuserobjectinformati...@20
2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol __imp__getprocesswindowst

[PATCH] hurd target fixes

2010-03-16 Thread Matthias Lanzinger

Hi,
Currently the hurd target for openssl is lacking the table entry for
SHLIB_EXT which makes the install of shared libs fail.
I also bumped the march up to 686 because I dont see any reason to
still use 486. But the important part is the SHLIB_EXT entry.

Cheers,
Matthias


--- openssl-0.9.8m/Configure2009-11-09 15:14:26.0 +0100
+++ openssl-0.9.8m/Configure2010-03-16 06:57:04.283092191 +0100
@@ -537,7 +537,7 @@
 "newsos4-gcc","gcc:-O -DB_ENDIAN::(unknown):NEWS4:-lmld
-liberty:BN_LLONG RC4_CHAR RC4_CHUNK DES_PTR DES_RISC1 DES_UNROLL
BF_PTR",

 # GNU Hurd
-"hurd-x86",  "gcc:-DL_ENDIAN -DTERMIOS -O3 -fomit-frame-pointer
-march=i486 -Wall::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-fPIC",
+"hurd-x86",  "gcc:-DL_ENDIAN -DTERMIOS -O3 -fomit-frame-pointer
-march=i686 -Wall::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",

 # OS/2 EMX
 "OS2-EMX", "gcc",
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL 1.0.0 beta5 release v. VMS

2010-03-16 Thread Steven M. Schweda

> Date: Thu, 18 Feb 2010 06:28:04 -0600 (CST)
> 
> From: Arpadffy Zoltan 
> 
> > Also if it is not too late, it would be nice to add 32 at the end of the
> > sharable images if the are build with 32 bits pointer size (64 is the
> > default).
> > 
> > I mean to have like this:
> > LIBCRYPTO32.OLB;1
> > LIBSSL32.OLB;1
> > LIBCRYPTO.OLB;1
> > LIBSSL.OLB;1
> > SSL_LIBCRYPTO_SHR32.EXE;1
> > SSL_LIBSSL_SHR32.EXE;1
> > SSL_LIBCRYPTO_SHR.EXE;1
> > SSL_LIBSSL_SHR.EXE;1
> 
>For the record, HP's shareable images look like this:
> 
> Directory SYS$COMMON:[SYSLIB]
> 
> SSL$LIBCRYPTO_SHR.EXE;1
> SSL$LIBCRYPTO_SHR32.EXE;1
> SSL$LIBSSL_SHR.EXE;1
> SSL$LIBSSL_SHR32.EXE;1
> 
>While not entirely trivial, it would be relatively easy to re-jigger
> the VMS builders to use different product-file directories for builds
> with /POINTER_SIZE = 32 and /POINTER_SIZE = 64 ('ARCH = ARCH+ "32"', or
> whatever), and then to produce (and install) the results with
> HP-like names.  Also, I know of nothing which would stop users from
> linking (SET FILE /ENTER) any desired old names to the newer (better)
> "SSL_LIB*[32]" names.  So, why, exactly, aren't we doing this?

   Did I miss the discussion when this was all resolved?  Or is no
decision the decision, so it'll all stay as it is (that is, different
from, and not so good as, HP's scheme)?

   Other lingering complaints...

   "vms/install.com" still hard-codes the procedure's own location
inside OPENSSL_STARTUP.COM, which causes everything to fail if the user
renames the installation directory.  I'd prefer that OPENSSL_STARTUP.COM
use its own location to find the installation directory, as previously
suggested.

   "makevms.com" still writes architecture-specific stuff into a
generated OPENSSLCONF.H file.  I claim that all that stuff could be done
(once) in the "opensslconf.h.in" source file, as previously suggested.

   When I last looked, "makevms.com" was still copying various source
and test files around, cluttering/corrupting the original source tree in
an unnecessary attempt to complensate for the lack of symbolic links on
VMS file systems (until recently, at least).  Revised builder schemes to
avoid this have been previously suggested.

   There are probably more items which belong here, but it's been a
while since I went through this frustrating exercise.

   Or would evryone be happier if I just went away?  (Or is VMS itself
(even) more of a nuisance than I am?)



   Steven M. Schweda   s...@antinode-info
   382 South Warwick Street(+1) 651-699-9818
   Saint Paul  MN  55105-2547
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: [openssl.org #2194] Unwanted dependencies to user32.dll

Re: [openssl.org #2194] Unwanted dependencies to user32.dll

Re: [openssl.org #2194] Unwanted dependencies to user32.dll

[openssl.org #2194] Unwanted dependencies to user32.dll

[PATCH] hurd target fixes

Re: OpenSSL 1.0.0 beta5 release v. VMS

6 matches

Site Navigation

Mail list logo

Footer information