http://bugs.winehq.org/show_bug.cgi?id=19212
Summary: secur32.SECUR32_initNegotiateSP() is unused Product: Wine Version: 1.1.25 Platform: All OS/Version: All Status: NEW Keywords: source Severity: normal Priority: P2 Component: secur32 AssignedTo: wine-bugs@winehq.org ReportedBy: fgouget@codeweavers.com
secur32.SECUR32_initNegotiateSP() is unused.
See this thread: http://www.winehq.org/pipermail/wine-devel/2008-December/071368.html
Kai Blin said:
This function would (and at some point did) register the Negotiate security provider. It's not called right now because the provider is not implemented and registering it broke some applications. The better solution here would be to completely remove negotiate.c and readd it once it's implemented.
But removing negotiate.c entirely would make it harder to work around bug 16905.
http://bugs.winehq.org/show_bug.cgi?id=19212
--- Comment #1 from Kai Blin kai.blin@gmail.com 2009-07-06 03:09:49 --- Yeah, looks like we'll have to implement it. That's going to be a pain, as we either need to do the ASN.1 parsing ourselves or build on top of some ASN.1 library out there. Alternatively, we could base our SSPI code on top of Heimdal GSSAPI and hope that MIT GSSAPI catches up on the NTLM support soon (I heard RedHat was working on this). We'd still have to do SSL (SCHANNEL) ourselves, but IIRC you can only Negotiate (SPNEGO, as per RFC) between NTLM and Kerberos.
My estimate is that any of these solutions will take about two to four weeks development time to evaluate and implement, and testing this is going to be non-trivial as well. My preference would be to go via one of the GSSAPI libraries, as that'd allow us to care less about all of this. Given that I don't have time to implement anything in this area right now, that probably won't count much.
http://bugs.winehq.org/show_bug.cgi?id=19212
--- Comment #2 from Juan Lang juan_lang@yahoo.com 2009-07-06 13:22:06 --- (In reply to comment #1)
Yeah, looks like we'll have to implement it. That's going to be a pain, as we either need to do the ASN.1 parsing ourselves or build on top of some ASN.1 library out there. Alternatively, we could base our SSPI code on top of Heimdal GSSAPI and hope that MIT GSSAPI catches up on the NTLM support soon (I heard RedHat was working on this). We'd still have to do SSL (SCHANNEL) ourselves, but IIRC you can only Negotiate (SPNEGO, as per RFC) between NTLM and Kerberos.
What do we need to parse? crypt32 has done some asn.1 parsing for some time, the code there could be of use.
http://bugs.winehq.org/show_bug.cgi?id=19212
--- Comment #3 from Kai Blin kai.blin@gmail.com 2009-07-10 00:59:25 --- See RFC4178 (http://tools.ietf.org/html/rfc4178)
http://bugs.winehq.org/show_bug.cgi?id=19212
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|All |Other OS/Version|All |other
http://bugs.winehq.org/show_bug.cgi?id=19212
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #4 from Austin English austinenglish@gmail.com 2010-07-23 15:39:53 --- Looks like it's used now: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/secur32/secur32.c#l564
http://source.winehq.org/git/wine.git/?a=commitdiff;h=dfb2b429
http://bugs.winehq.org/show_bug.cgi?id=19212
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Alexandre Julliard julliard@winehq.org 2010-07-30 12:57:11 --- Closing bugs fixed in 1.3.0.
-
wine-bugs＠winehq.org