CryptoAPI (no, this has nothing to do with licensing! YAY!)

[David Elliott]

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