>>>>> 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.
app_RAND_load_file is in openssl.exe application. Do you invoke openssl.exe from your application??? I was under impression that *your* application is *linked* with OpenSSL *library*... So that when I referred to "OpenSSL" I referred to the *library*, not openssl.exe. Or you might compile one of apps/*.c modules with your application. In which case http://cvs.openssl.org/chngview?cn=19557 would still do the trick... > I cannot oversee > whether OpenSSL (library) really Never calls this function. Most > probably, the library will not. When I said "it doesn't call it" there was no "probably." This implies that you a) take my word for it; b) verify the statement and tell that it's wrong in case it is. In latter case, if the statement will be proven wrong, it will be considered as bug and will be fixed. But there is nothing one can do about "I cannot oversee." >> 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. ??? RAND_screen would be the *only* candidate for NEED_OLD_FUNCTIONALITY, but it's not the only place where user32 calls are made... > 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. What are the means of forbidding? Not having user32.lib on link command line you tell developers to use? How do you link with openssl library? Statically or dynamically? If statically, then add stub module of own design with handful of empty functions called by OpenSSL library and exclude gdi32/user32 from link command line. Or consider switching to dynamic link, i.e. with OpenSSL *dlls*, because if linked dynamically, then you don't need user32.lib on *your* link command line at all. > I would > like not to use user32.dll at all in our code. Then don't. Just demand discipline from your developers. Tell them why it's important, they'll understand. >> 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). What is real risk/concern here? That product is shipped to end-user, who discovers that amount of users can start application in question in service context is lower than expected. Just add the check for user32.dll being mapped at run-time to your test cycle and handle the problem prior release... A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
