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
Received on 2012-05-17