Re: CryptoAPI (no, this has nothing to do with licensing! YAY!)
On 2001.12.20 11:52 Travis Michielsen wrote: [BIG SNIP]
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. Umm, yes, I can successfully acquire and release when testing with the MSDN sample as well, but not with RSAENH.DLL that IE wants.
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.
Pardon my ignorance, but I didn't realize that that was what pstores did.
3) Dependancy functions of pstores and M$ providers not implemented: (advapi:RevertToSelf, ntdll:NtOpenProcessToken, advapi:SetThreadToken, mpr:WNetGetCachedPassword, etc.)
Yup, if pstores is necessary, we'll need pstores working, so that's something to add to the task list.
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. As for the key and hash: Yes, I am well aware of this, there is a blatant FIXME in the code since I haven't gotten there yet.
And I don't know where you get that I am making a list of all CSPs. What I am doing is making a list of any CSPs which are in use and storing the appropriate function pointers in that object. I could simply do a loadlibrary each time the CSP is loaded and store all of that information for every context. But I thought it would be better to do it the way I did so that if multiple contexts are acquired from the same provider we don't have duplicate information in memory.
5) I have not yet considered thread or process safing/locking. Nor have I
done any reference counting. Well, I am not so sure about my thread safety but I think theoretically it is okay. I wrote the thread safety in from the beginning.
6) Seting and getting Key/Hash/Prov Params doesn't consider flags not used by the CSP and have meaning in advapi32.dll. Haven't even really gotten that far yet.
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.
Well, CSP.DLL from the CSPDK does not provide a couple things. Originally I required every function to be provided but when I found that CSP.DLL did not provide one of them I decided to err the other way and only require the bare essentiallys like Acquire/ReleaseContext.
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.
YES, definitely. Sorry to be stepping on your toes here. Most of the CryptAcquireContext function, specifically the parts that look up which CSP we need to load, I implemented rather quickly months ago. I didn't have time to do anything until a few days ago when I wrote everything else and posted it on wine-devel.
I am currently testing this code against windows 98.
Well, I have Win95osr2 running under Win4Lin and I use that as my C: drive in Wine as well. It works a lot better having everything stored on an ext2 drive than on vfat. I have not yet taken a look at your code but will do so as soon as I finish reading the rest of today's wine-devel. -Dave
participants (1)
-
David Elliott