On Monday 08 November 2004 13:41, you wrote:
Michael Jung wrote:
I fear that the problems with crypt.c and the crash are related to rsaenh.dll, which is pretty new in wine cvs. I can't reconstruct the test failures on my system. There are some entries in the initial registry, which did change due to rsaenh.dll. Could please retry without an existent .wine directory?
Done. (I even rebooted with nosmp.) That seems to have helped the crypt test; now I just get
../../../../wine/tools/runtest -q -P wine -M rsaenh.dll -T ../../.. -p rsaenh_test.exe.so ../../../../wine/dlls/rsaenh/tests/rsaenh.c && touch rsaenh.ok fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40200f90): not verifying image fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40200fb0): not verifying image fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40202598): not verifying image
which is benign, right?
Yes, it is. I would even opt for removing this fixme (or changing it to a trace) and let the VerifyImage function always return TRUE. Implementing it in a sensible way would be a large effort, which would not buy us any additional functionality. This function was meant to provide two things: 1.) Enforcing US export regulations, which we should not care about (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/s...). 2.) Preventing tampering with CSP dlls, which has long been by-passed (it seems to be possible to exchange the unused NSAKEY in the binary advapi32.dll - and if you don't have write access to advapi32.dll you probably don't have write access to rsaenh.dll also).
Greetings, Michael