> I agree that OPENSSL_isservice() cannot be changed, ??? My suggestion for *you* was to modify it to unconditionally return 1...
> but you can > decide to log an event always. ... so that messages will be forced to event log. > 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. Don't forget gdi32.dll. > 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) Comment next to RAND_screen, the only function that calls randscreen, mentions that it, RAND_screen, is kept for backward compatibility. It's not called from anywhere in openssl *libraries*. However! There seem to be a bug there: first if should be inverted... My bad, it's being fixed... >> 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. > > Yes, we do start a new process for every user/connection. I can of > course add /delayload:user32.dll, but the risc is that users will too > easy use code from user32.dll. ??? I don't understand. If users don't have an option to invoke code of their choice, then /delayload-ed library will remain unmapped and it won't be a problem. But if they have such option, then how not having it linked with openssl would prevent them from mapping it and consuming session memory? > It would be very useful if all references to user32.dll have been > removed. If you don't want to modify OPENSSL_isservice and feel that you absolutely must get rid of reference to user32.dll [and gdi32.dll], then write small module that implements stubs for functions in question (i.e. functions that don't do real work, but mostly simply return) and link it with your copy of openssl. I see no reason to modify the base-line code, as the situation in question doesn't seem to be common. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
