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
