Hi,
1st of all: I have no strong opinion either for or against the string ...

Am 12.06.2012 19:21, schrieb Steve Holme:
> On Tue, 12 Jun 2012, Yang Tse wrote:
> 1) curl displays the SSL library in its version string and as such should
> display something when SSL through Windows SSPI is enabled.
k, but the version info is surely not important - it would in this case
equal to the Windows version, and we didnt display it before (nor did we
f.e. for WinIDN), and we dont display the kernel version on Linux either.

> 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).
but we DO display 'SSL' as a feature as well ...

>> These two are system libraries the same as all other
>> system libs that might be used, such as kernel32,
>> normaliz, wldap32 and ws2_32, for which we don't
>> show any version info.
>
> I guess there is a fine line between what package and version information
> curl should show versus what it shouldn't and Windows muddies the water a
> little by provided low level libraries such as ws2_32.dll (Winsock 2) and
> other high level libraries that give the functionality of Windows SSPI or
> implement the LDAP protocol. For example, if we wanted to show what third
> party LDAP libraries curl might use, we could display OpenLDAP and Windows
> LDAP (the later would probably want to show the version number from
> wldap32.dll to be consistent), however, we don't want to show the
> information for low level libraries such as ws2_32.dll.
goot example for not adding a version info: up to now we dont show
version info for any LDAP lib, and that although the user *has* a choice
over wldap32 vs. OpenLDAP, NovellLDAP, MozillaLDAP ...

>> The user/developer has very little choice relative
>> to which version is used.
true.

>> Additionally showing that info introduces another
>> library dependency which didn't exist up to now.
>
> Again this is true and as you are aware, getting version information out of
> a dll on Windows requires using version.dll - As this was introduced as a
> system dll in Windows 2000 I don't have a problem with that or statically
> linking against it. However, I've only been part of the development team for
> the last 12 months, and don't have the wealth of experience that you do, so
> don't know the full history of the product and demographic of users and the
> variants of Windows that curl is used on - In that respect I honestly can't
> say if that is an issue or not. If we decide it is an issue then I would
> recommend that we bind to the dll dynamically thus allowing
> Curl_sspi_vesion() to fail gracefully and display "WinSPPI/unknown" (as it
> does now if any part of the function fails) or just "WinSSPI" if preferred.
>
>> My opinion is to get rid of it, unless someone tells us why we badly need
> it.
well, perhaps a compromise would be if we just display
"SSL-Windows-native" like we do with WinIDN ? That would drop the new
dependency to the version lib while remaining the information that SSL
is provided through a Windows system lib rather than through an
expternal lib (same as with WinIDN).
Here's an output of a build with WinIDN:

curl 7.26.0 (x86_64-pc-win32) libcurl/7.26.0 OpenSSL/1.0.0j zlib/1.2.7
IDN-Windows-native libssh2/1.4.2
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3
pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN Largefile NTLM SSL SSPI libz

Gün.

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