>>> 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?
> 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.
> 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)
You most likely mean ProcessIdToSessionId for current process.
> 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).
Which reminds me. *If* you redirect stderr to a file when you start your
application and never call RAND_screen (once again, openssl itself does
not call it), then /delayload-ing user32.dll and gdi32.dll will do the
trick. This is because OPENSSL_isservice is *not* called if stderr is
redirected or attached to console window.
> 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.
> 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.
Can't you run main(){getchar();LoadLibrary("user32.dll");getchar();} and
*see* that with dheapmon? "feeling" should not be part of programmer's
vocabulary.
>>> 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...
Question was if they can LoadLibrary("user32.dll") or make any other
call *of their choice* that would bring user32.dll into process address
space? But it's more of a rhetorical question for me, because it appears
that you don't formulate the problem correctly.
> 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?
Once again, openssl *itself* doesn't call RAND_screen. *Application* can
call it to possibly improve seed quality, but the decision is left to
application.
> Some comments in Randomizer.cpp
What's 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.
Correct. Which is why the decision is left to application and the
intention was not to read screen when application is executed in service
context. "Intention" refers to the fact that we've established that
there is a bug in first "if" statement in readscreen. A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
