>
> > 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.
May be there is another method to check wether a windows process is a service,
without using user32.dll.
At least for windows 2008/vista etc, you can assume that a process is a
service, if it is running in session 0 (e.g. see
WTSGetActiveConsoleSessionId(), supported from Windows 2003 onwards)
However, processes can run as non-service, but that will not necessary mean
that there is a visible console (e.g. another process may call the process
using OPENSSL_isservice(), but not redirect stdout or stderr). I would highly
appreciate if a define can be used (configurable with Configure) to tell that
we want [no] unconditional logging to the evenviewer.
My feeling is - but I can't prove - that if applications load user32.dll, some
init code in user32.dll will already occupy some bytes in the windows heap.
We are building openSSL on a number of platforms, and I like to use the OpenSSL
code unchanged, otherwise, if we make modifications, and if I move to a new
openSSL release, I've to replay all our own modifications. Until now, we could
working with OpenSSL as it is.
>
> > 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.
True. Thanks for hint.
>
> > 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?
Our application is a VM, like Java. Users can execute their own code within
that VM.
Based on their code used, openSSL (and cURL) can be used or not...
As I understand correctly (I'm not sure), RAND_screen(), and effictively
read_screen() is used to generate a seed.
Is it not possible to create a seed, without using gdi32.dll and/or user32.dll?
I.e. is it not possible for Windows to use a platform independent approach,
similar to Unix?
Some comments in Randomizer.cpp already say (which may point to some
disadvantages of the current READ_screen() implementation):
* OpenSSL provides the function RAND_screen(), by G. van
Oosten, which hashes the contents of the screen to generate a
seed. This is not useful for an extension or for an
application which launches at startup time, since the screen
is likely to look identical from one launch to the next. This
method is also rather slow.
>
> > 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.
>
>
>
I will try to keep this option as last one. I still prefer some (configurable)
change in openSSL.
As far as I could see, the places are the only ones using user32.dll/gdi32.dll
code.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
