On 17/04/07, Juan Lang wrote:
Sorry for the late reply.
I'm working on schannel at the moment. schannel is not a regular SSP, and the functions in wrapper.c can't load native. I've implemented the proper loading code in my local tree and I'm sending it in obvious pieces. no-op cleanups is the first step.
I'm curious how schannel gets loaded, and how you figured it out. Could you enlighten me?
Robert's patch to add schannel.dll that forwards to secur32.dll tipped me. All the regular SSP (Security Support Provider) functions are forwarded to secur32, including enumeration and initialization. secur32 has to get its entry points somehow, so I looked into the few functions that are not forwarded.
It turns out that schannel is implemented as an SSP/AP (Authentication Package), which means that it is loaded into the address space of lsass too. Later reading suggested that this was done to enable single-sign-on using client certificates. I just load it into the user address space and faked the callbacks/copytouser/copyfromuser.
A side effect would be that it would also load kerberos.dll and msv1_0.dll, but we don't really need them. Using native posix krb5 is not hard and would integrate with the system better.
If you need reviews of this, I'm happy to look at early patches.
I'll send you off-list after a small cleanup.
The current stage is that native schannel loads and initializes, but builtin rsaenh does not supply everything it needs, so it can't complete the ssl handshake. Native rsaenh requires unimplemented stuff in ntdll.
What stuff, out of curiosity?
Small functions mostly. You'll see it in wine-patches soon.
I'm very interested to see progress in this area. Thanks!
I'm silently tracking your work in this area for years (and later Kai's). I was just busy with another open source project. I dropped from that one and now I have time for wine :-).
--Juan