> -----Original Message----- > From: Andy Polyakov via RT [mailto:[email protected]] > Sent: Saturday, April 10, 2010 23:33 > To: Kees Dekker > Cc: [email protected] > Subject: Re: [openssl.org #2194] Unwanted dependencies to user32.dll > > >>>>> I agree that OPENSSL_isservice() cannot be changed, > >>>> ??? My suggestion for *you* was to modify it to unconditionally > >>>> return 1... > >>> Our application can both run in foreground and in service > >> context. So > >>> simply changing to return 1 is not possible. > >> If changing to return 1 is not acceptable, how come conditional > >> compilation freezing to some unconditional behavior is? > > > > Changing to 1 is acceptable, but changing code is very difficult. > > Exactly and the question is why does OpenSSL have to do the difficult > part:-):-):-) > > >>> May be there is another method to check wether a windows process > >>> is a service, without using user32.dll. > >> As mentioned one can do it with Native NT API, but it's quite > >> special and belongs rather in [your] application than in openssl. > > > > Yes and no. As soon as there is any openSSL code, using APIs from > > user32.dll, my application still have a dependency to user32.dll. > > Once again, if you /delayload user32 and never make the call, you're > safe. OpenSSL never calls RAND_screen, your application can, > make sure > it doesn't. OPENSSL_isservice doesn't make user32.dll calls if you > redirect stderr. If called as service start your application with > redirected stderr.
The function app_RAND_load_file() calls RAND_screen. And app_RAND_load_file() is called from many places. I cannot oversee whether OpenSSL (library) really Never calls this function. Most probably, the library will not. > > Rules of conversation imply that you either try to refute the > statement > or confirm it. As opposite to ignoring it and tell what would > you *like* > to do over and over:-):-):-) Ok you can close this request. It was not intended by me to move the 'difficult part' to openSSL. I only suggested - if the code was not used by OpenSSL at all, like you said - just to put it within #ifdef NEED_OLD_FUNCTIONALITY or so. The problem with delayed loading of user32.dll is that developers of our code **can** use user32.dll functionality, while I prefer to forbid it, i.e. explicitly disable linking to user32.dll. I would like not to use user32.dll at all in our code. >From development/compile/link perspective there is no difference in using >user32.lib/dll with regular flags, or with delayed load flags. By using delayed loading, the risc is high that user32.dll is used (either by accident, or by intention of one of our developers). > > >>> I would highly appreciate if a define can be used (configurable > >>> with Configure) to tell that we want [no] > >> unconditional > >>> logging to the evenviewer. > >> No. The maximum I'd go for is a way for application to provide a > >> way to override OPENSSL_isservice. E.g. *application* can dllexport > >> _OPENSSL_isservice and OPENSSL_isservice can check for its > >> presence and in such case invoke it. > > See. http://cvs.openssl.org/chngview?cn=19557. A. > >______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
