On Thu, Aug 07, 2003, Richard Levitte - VMS Whacker wrote:
> In message <[EMAIL PROTECTED]> on Thu, 07 Aug 2003 11:12:59 +0100, Martin Kochanski
> <[EMAIL PROTECTED]> said:
>
[Toolhelp stuff]
Haven't been following this thread too closely but I've a vague recollection
that ages ago when I did a
In message <[EMAIL PROTECTED]> on Thu, 07 Aug 2003 11:12:59 +0100, Martin Kochanski
<[EMAIL PROTECTED]> said:
cardbox> Beautiful. Thank you for the quick response.
cardbox>
cardbox> That'll work until MS put a dummy CloseToolhelp32Snapshot
cardbox> call into the main Windows DLLs and then tell y
The reason that we go to all this trouble to examine alternative sources
of randomness other than CryptGetRandom() is that Microsoft has refused
to publish the sources of randomness which are used. Therefore, we have
no ability to know whether or not the randomness reported by Windows is
in fa
In message <[EMAIL PROTECTED]> on Thu, 07 Aug 2003 08:54:19 +0100, Martin Kochanski
<[EMAIL PROTECTED]> said:
openssl> There are three related issues here, all to do with the use of
CreateToolhelp32Snapshot in RAND_poll() in rand_win.c. I'm using OpenSSL 0.9.6g, and
the relevant call is at line
In message <[EMAIL PROTECTED]> on Thu, 07 Aug 2003 08:54:19 +0100, Martin Kochanski
<[EMAIL PROTECTED]> said:
openssl> 1. Minor bug:
openssl>
openssl> Line 443 of rand_win.c reads (reformatted)
openssl>
openssl>&& (handle = snap(TH32CS_SNAPALL,0))!= NULL
openssl>
openssl> ["snap" is a vari
I don't understand what to do to handle this: can you help. I really would like to have this protection.
Randy Shaw
Director of Admin. & Operations
City Mission Ministries
[EMAIL PROTECTED]
(909) 757-9748
<>
Hello Noel,
You may as well try to find a way to workaround this problem for your
platform, instead of just removing the offending code (which may break
other things) ...
This is taken from the MSDN library description of
CreateToolhelp32Snapshot():
Windows NT/2000/XP: Included in Windows 200
