secur32: invert error handling conditions in order to decrease indentation in secur32/wrapper.c.
On Saturday 14 April 2007 00:56, Yuval Fledel wrote:
- the patch is a no-op.
While I like to do the same to functions I work on, is there any reason you need to change this for wrapper.c? It hasn't been changed for quite a while and seems feature complete.
Kai
Hi Kai,
Please reply-to-all next time. I've found your reply on the archive.
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 could implement schannel as a normal SSP and use the current code. However, if I can do something closer to what native does, I'd better do it.
Not that loading native schannel is a piece of cake. It does require faking lsass (done), and implementing lots of functions everywhere (userenv, crypt32, ntdll, rsaenh: I'll send after a cleanup and writing tests).
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.
On Saturday 14 April 2007 00:56, Detlef wrote:
I suggest to modify only one Function per Patch (max. two Functions, when they work together and the total Patch-size is small).
Will do.
On Monday 16 April 2007 13:20, Yuval Fledel wrote:
Please reply-to-all next time. I've found your reply on the archive.
Sure, sorry about that.
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.
Ok, fair enough. If you are going to work on this, feel free to clean up.
I could implement schannel as a normal SSP and use the current code. However, if I can do something closer to what native does, I'd better do it.
Sure. I guess Juan Lang will be interested in this (I've CCed him), as he's been working on this for quite some time now.
Not that loading native schannel is a piece of cake. It does require faking lsass (done), and implementing lots of functions everywhere (userenv, crypt32, ntdll, rsaenh: I'll send after a cleanup and writing tests).
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.
Interesting. I'll keep an eye out for those patches.
Cheers, Kai
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?
Not that loading native schannel is a piece of cake. It does require faking lsass (done), and implementing lots of functions everywhere (userenv, crypt32, ntdll, rsaenh: I'll send after a cleanup and writing tests).
If you need reviews of this, I'm happy to look at early patches.
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?
I'm very interested to see progress in this area. Thanks! --Juan
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
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
-
Juan Lang -
Kai Blin -
Yuval Fledel