cURL / Mailing Lists / curl-library / Single Mail


RE: Windows SSPI Schannel implementation ready

From: Steve Holme <>
Date: Wed, 13 Jun 2012 19:36:29 +0100

Hi Guenter,

> to shorten this never-ending discussion I did
> just change the string to "SSL-Windows-native"
> for 3 reasons:
> 3) At least we have 2 of us agree on this (me and Marc).

Three (me) - I was simply against the package name as SChannel, although
Marc, Yang and I didn't have a problem with the string "WinSSPI" although
what you suggested is consistent with the IDN string and people that know
me, know I have an issue with consistency ;-)

> TODOs:
> 1) we should make sure this string appears *only*
> if SSL functionality is provided via schannel, sspi,
> whatever ...

I still think it is worth having the string there when SSPI is included when
it compiled in security context mode / SSO (auth stuff as you call it) as it
is using the same library. For example, you don't remove the libssh string
when it isn't compiled with zlib ;-) I slight bad analogy but hopefully you
understand my point there.

Now without checking email history yet again, and to be honest I am just
about out of patients on this, considering the amount of time and effort I
have already put into it, I thought Marc and Daniel agreed here.

> 2) it should remain possible to build with SSPI
> auth stuff and without native SSL stuff -> we
> need still *two* defines

I'm a little confused here... are you talking about makefile options or the
USE_* #defines or something else?

In Visual Studio I had curl building with 1) Just the security context / SSO
capabilities and 2) These plus SChannel SSL with last night's version of the
code base - I haven't rebuilt todays changes so I don't know if something
has changed to affect that.

USE_WINDOWS_SSPI should build just the security context / SSO capabilities.
USE_WINDOWS_SSPI and USE_SCHANNEL should additionally build in the SChannel
SSL stuff.

Kind Regards


List admin:
Received on 2012-06-13