Hi again,

On Tue, 12 Jun 2012, Yang Tse wrote:

Apologies if any of what I write sounds a little off or abrupt... it isn't
my intention!

I was tucked up in bed keeping warm as I'm really not feeling too good, I
currently have a temperature yet am cold and am feeling sick at the same
time, but I saw the email come in on my phone so I thought I should respond
properly at the keyboard whilst things are still fresh in everyone's mind.

> > There are two reasons for including Windows SSPI in the version
> > information.
> >
> > 1) curl displays the SSL library in its version string and as such
> > should display something when SSL through Windows SSPI is
> > enabled.
>
> Should? Why? What does it provide besides completeness?

If we don't put anything in here then what will a programmer who is using
ssl_version from the result of curl_version_info() get?

Surely we need to include something if CURL_VERSION_SSL is indicated in the
features flags?

> SSL support is indicated by 'https', 'ftps', etc in the supported
protocols list, and that SSPI is in use in the features list.

> > 2) Windows SSPI can be thought of as the equivalent to OpenSSL or
> > better still GNUTLS as it is a provider of security related features
> > and provides libcurl with the following:
>
> I still find no need to expose it in this new way which has been
introduced.

Why? I'm not sure if I have missed something but can you please explain what
you don't like about it?

Is it the fact that Windows SSPI is listed in the version string, or that it
uses the version number of secur32.dll for example, or that it uses
version.lib to statically link with ?

> > From discussion with Daniel, and to a certain degree from your email
> > of 23 April, I believe that the feature of SSPI as listed in curl's
> > feature string actually represents the SSO capability of Windows SSPI
> > and not everything that Windows SSPI provides (or at least it
> > shouldn't represent all of SSPI as otherwise you wouldn't display
GSS-Negotiate and NTLM for example).
>
> Ah, forget that mail of mine, I wrote it out of memory.

I'm sorry but how are Marc and I supposed to know that?

This, if my memory serves me right, was the last thing your wrote on the
forums about this.

Since then we have asked for feedback about USE_WINDOWS_SSPI vs
USE_WINDOWS_SSO as well as the version information but only received limited
responses. SSL using Windows SSPI Schannel was something that Daniel wanted
to see in the upcoming 7.27.0 release. Since then I have, possibly, wasted
two Sunday's assisting Marc in trying to sort out the version information
sorted as I was under the impression that this is something that needs to be
present in ssl_version, and subsequently curl's version string, in help get
the schannel additions into this release.

> The fact is that SSPI feature actually represents that security.dll or
> secur32.dll is in use. Very long-long time ago it represented SSO
> but that was changed also long time ago to what it represents
> currently.

I do believe that SSPI shouldn't be listed in the features list as it
currently is - as per the emails from last night.

I have already documented a new section in docs\TODO to either replace /
remove CURL_VERSION_SSPI from the next major version number but haven't
pushed it in light of this discussion.

As such I would like to see individual features such as SSO listed instead -
as you also wrote that NTLM_WB does / could / should provide.

> > WinSSPI is a short friendly name, or package name if you like, for
> > security.dll / secur32.dll just as OpenSSL is the package name for
> > libssl32.dll and libeay32.dll. Originally, Mark had this as SChannel
> > which we decided wasn't a good name.
>
> I also find it a good name, but no need to use it.

Again why not?

> SSPI might use schannel.dll, ntlmssp.dll, kerberos.dll, cryptdll.dll
> and any other that gets properly injected into the system.
> Should we also show the version of those libs?

No not at all - and I think the fact that we have used the version
information from secur32.dll is a bit of a hack to get a version number as I
would prefer to call a function in SSPI to get the version number. Now
please don't think I'm shifting the blame here, I'm not, but this was how
Marc had written Curl_version_info() - I have tried to take that, clean it
up a little and make it more general as to display the fact the Windows SSPI
is in use as a provider of security features like as I have already said
GNUTLS and other security providers are displayed by curl.

Given the hack and after some digging around in system32... sspicli.dll
would be a better library to use for the version information as like you say
Windows SSPI might pull in other libraries.

> > > The user/developer has very  little choice relative to which version
> > > is used.
> >
> > This is very true... and I guess it would be similar to something like
> > OpenSSL being pre-installed as part of Solaris for example ;-)
>
> Even on Solaris a user might build on its own a different OpenSSL
> version and use it, thing which is absolutely impossible on Windows
> for security.dll, secur32.dll and all MS system libs. So my question
> remains why do we need to expose MS system lib version?

Guenter has mention that the Windows IDN version number is not shown - so it
might be that is the way to go here as well.

It depends whether we want to show the version numbers for the libraries
that are in the version string. Equally you could argue that we should
display the version number for Windows IDN as well ;-)

> Well, its clear we have different opinions on this.

It would seem so :( I would really like to understand your objection so if
you could clarify that, that would be great?

Many thanks

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-06-12