Hans Leidekker hans@codeweavers.com wrote:
On Tue, 2017-10-17 at 16:08 +0800, Dmitry Timoshkov wrote:
Hans Leidekker hans@codeweavers.com wrote:
Hans, are you planning to somehow reuse our patches or still prefer your own way of adding Kerberos support?
I don't see an immediate need to split the Kerberos code into a new dll. Do you have an application that depends on this?
Yes, I have an application that indirectly depends on this: it's a security provider that installs its own DLL (GOST), adds it onto the list of existing SSPs in the registry, and expects that secur32 would load it on the applications' requests.
I see. In that case, would you be willing to upstream your SSP loader code?
The thing is that the secur32.dll already has the SPP loading code, however it lacks the LSA Authentication Package (AP) manager, and the AP is another part of the security provider DLL.
Also separating Kerberos implementation moves external dependencies out of secur32.dll.
Well, if we load them dynamically there wouldn't be any difference in practice.
Sure.