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
