2009/1/28, Daniel Stenberg wrote:

> What is secur32.lib and why do we need it with the GSSAPI change?

Library which provides the following Windows SSPI functions used
_directly_ by Markus Moeller's patch: DecryptMessage, EncryptMessage,
QueryContextAttributes, QueryCredentialsAttributes,
DeleteSecurityContext, FreeContextBuffer, InitializeSecurityContext,
FreeCredentialsHandle, AcquireCredentialsHandle

Depending on Windows version these functions are available at run time
through security.dll/lib or secur32.dll/lib

> Why didn't we need it before?

Not because libcurl wasn't already using any of those functions. But
certainly because libcurl wasn't binding/linking directly with any
function from such library at compilation stage. libcurl was first
loading the appropiate dll depending on Windows varsion, finding the
address of the SecurityFunctionTable using InitSecurityInterface() [1]
and afterwards calling such SSPI functions through the
SecurityFunctionTable [2] dispatch table.

All this is the approach followed in http_ntlm.c, see
Curl_ntlm_global_init() and function calls done through s_pSecFn [3].
A little bit convoluted, but the most portable approach across Windows
versions.

> Will it have any drawbacks for those who don't care about SOCKS support?

For libcurl consistency and maintainability sake the Windows SSPI
interface should probably be used only in one fashion, linking
directly with the SSPI library or the more portable late binding using
the function dispatch table which avoids direct linking.

Late binding also implies that Windows security fixes that affect SSPI
will be 'active' in libcurl as soon as the OS is fixed, otherwise
libcurl recompilation is obviously required.

[1]: http://msdn.microsoft.com/en-us/library/aa376103(VS.85).aspx
[2]: http://msdn.microsoft.com/en-us/library/aa380125(VS.85).aspx
[3]: http://cool.haxx.se/cvs.cgi/curl/lib/http_ntlm.c?rev=1.75&content-type=text/vnd.viewcvs-markup

-- 
-=[Yang]=-