On Wednesday, December 19, 2001 10:12 pm, you wrote:
On 2001.12.19 20:08 Alexandre Julliard wrote:
David Elliott dfe@tgwbd.org writes:
What bothers me though is that it does not get Intenret Explorer to load up the RSA CSP. The LoadLibrary fails because the DllMain function in the CSP returns FALSE. I speculate this has something to do with the fact that a real CSP needs to have its image verified before it will load. Or maybe it is something different entirely.
Is this rsabase.dll? If so this is because of a problem with LOAD_LIBRARY_AS_DATAFILE; I have a patch for this somewhere.
-- Alexandre Julliard julliard@winehq.com
Actually, rsaenh.dll. I am running IE 5.5 and accessing https://internetbanking.suntrust.com/. Not that this site doesn't work with Galeon anyway, but it seemed like a fairly simple way to test the crypto functionality.
Running wine --debugmsg +crypt IEXPLORE.EXE I get:
[...] trace:crypt:CryptAcquireContextA (phProv=0x7741b7d4, szContainer=(null), szProvider=Microsoft Enhanced Cryptographic Provider v1.0, dwProvType=1, dwFlags=f0000000) trace:crypt:CryptAcquireContextA Provider is Microsoft Enhanced Cryptographic Provider v1.0 trace:crypt:CryptAcquireContextA DLL is rsaenh.dll trace:crypt:CryptAcquireContextA Signature is 136 bytes long trace:crypt:CryptAcquireContextA Type is 1 trace:crypt:CRYPTOAPI_LoadCSP ImagePath=rsaenh.dll trace:crypt:CRYPTOAPI_LoadCSP pCspInfo->ImagePath=rsaenh.dll err:crypt:CRYPTOAPI_LoadCSP Could not LoadLibrary 1114 err:crypt:CryptAcquireContextA Could not load CSP trace:crypt:CryptAcquireContextA (phProv=0x7741b7d4, szContainer=(null), szProvider=Microsoft Enhanced Cryptographic Provider v1.0, dwProvType=1, dwFlags=f0000000) trace:crypt:CryptAcquireContextA Provider is Microsoft Enhanced Cryptographic Provider v1.0 trace:crypt:CryptAcquireContextA DLL is rsaenh.dll trace:crypt:CryptAcquireContextA Signature is 136 bytes long trace:crypt:CryptAcquireContextA Type is 1 trace:crypt:CRYPTOAPI_LoadCSP ImagePath=rsaenh.dll trace:crypt:CRYPTOAPI_LoadCSP pCspInfo->ImagePath=rsaenh.dll err:crypt:CRYPTOAPI_LoadCSP Could not LoadLibrary 1114 err:crypt:CryptAcquireContextA Could not load CSP [...]
I just tried running with +crypt,+relay and I get a crash before the main window comes up (with the non-drawn splash screen above everything) in INT21_FindFirstFCB on line 788 which is else pFCB = (FINDFILE_FCB *)fcb;
For some reason I cannot use the enter key in the console and trying to paste an enter from another window doesn't work either. So using the debugger does not work, hitting Ctrl-C in the console does work though. Is this a problem other people are having? I would have thought someone would have reported it by now if that was the case.
Anyway, if you think the patch you have might help me get RSAENH.DLL loaded and a bit further then I could probably have https sites working in IE shortly.
In any case I think if I just look over this code a little bit and make sure there are no absolutely glaring errors there should be no reason not to put it in the tree, even if it can't actually load a real CSP for some other reason.
-Dave
Actually I too, have been hacking away at the CryptoAPI (advapi32.dll) and was going to submit a full patch for it at the end of the week. My patch, however, has almost a completely different approach to the problem! Attached is my version (not quite complete or clean).
These are the main differences and issues I see between our patches:
1) I can successfully acquire/release a context (tested with MSDN sample code). I have not experienced any problems with <loading> a CSP. 2) Currently the ms CSPs can perform but all launch pstores.exe - the protected stores service. This is fine except that it eventually crashes with an unhandled exception c0000005 and then becomes unwilling to start again. 3) Dependancy functions of pstores and M$ providers not implemented: (advapi:RevertToSelf, ntdll:NtOpenProcessToken, advapi:SetThreadToken, mpr:WNetGetCachedPassword, etc.) 4) I do not create any list of providers. This should not be required as the registry is supposed to contain the list of available providers. Once a handle is acquired then we can gain access to the provider by this handle. Note: Key and hash objects need to link to the provider handle, when they are created. 5) I have not yet considered thread or process safing/locking. Nor have I done any reference counting. 6) Seting and getting Key/Hash/Prov Params doesn't consider flags not used by the CSP and have meaning in advapi32.dll. 7) I currently do not allow a CSP to drop any of the stardard functions. This only affects a few functions, however, as MSDN states these functions are *required* for the CSP to have. If they are not implemented they must set the last error as ERROR_CALL_NOT_IMPLEMENTED. 8) You seem to make not use
Anyway I think the correct thing to do right now is to co-ordinate our work to make a single patch and implementation.
I am currently testing this code against windows 98.
- Travis