Hi all, On Wed, 16 May 2012, Daniel Stenberg wrote:
> > I think USE_WINDOWS_SSPI should be used for the swap-in > > library/provider code where SSPI actually does not provide a > > standalone feature, but hosts an alternative to other crypto libraries. > > > > What's your opinion on this? We may want to plan this before any code > > changes are made. > > I think that can be used too, as long as no other crypto option has been used. > I can't see any particular drawback with it. I agree. I think this is the point I was trying to make in my original email where I proposed that the version info contain SSPI and we remove it from the feature list (I appreciate I may have failed here!) as essentially it is another provider of security information and as such shouldn't be classified as a feature but instead as a library like OpenSSL and the other libraries we use for generating security information such as Kerberos etc.. ;-) > But then I'm not the one most familiar and oriented in the SSPI world of > details so I'll listen to what others have to say as well! I have used Windows SSPI a couple of times in my career and again recently for 1) Verifying the SMTP NTLM work I did for libcurl, 2) I've been looking at it again recently in order to add GSSAPI to SMTP and 3) researching it's use in LDAP when calling ldap_sasl_bind() and ldap_sasl_bind_s(). Unfortunately, all my experience is the relatively simple stuff (if that term can be used when talking about Windows SSPI) to ask for a security provider, via AcquireCredentialsHandle(), and then when creating a security context / data packet via InitializeSecurityContext() for example. Anyway, that's my two pennies worth which I hope helps. Kind Regards Steve ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
