Am 23.04.2012 16:35, schrieb Yang Tse:
> On Mon, Apr 23, 2012 at 3:46 PM, Marc Hoersken <info_at_marc-hoersken.de> wrote:
>
>>>> 1) Revert 2976de48 and subsequent related commits. And...
>>>> 2) Rename USE_WINDOWS_SSPI to USE_WINDOWS_SSO. And...
>>>> 3) Rename feature SSPI to SSO. And...
>>>> 4) Verify if usage of USE_WINDOWS_SSO seems appropriate wherever it is used.
>>>>
>>> +1 - sounds reasonable ...
>>
>
> I've just reverted mentioned commits.
>
>> Sure, that's a good plan, but I don't think that USE_WINDOWS_SSPI is
>> misused everythere.
>> The NTLM and other authentication parts should probably use
>> USE_WINDOWS_SSO, but IMHO for example the shared curl_sspi.[ch] file
>> should actually stay with USE_WINDOWS_SSPI.
>
> Please provide patch relative to current head that does the renaming
> (and comment fixes) as you deem necessary without introducing new
> stuff yet and that is supposed to not break existing head builds yet.
>

Before I begin my work on the SSPI/SSO reorganization, I would like to
analyze the existing code base with you. I took a look at the following
files and identified their usage of the term SSPI:

lib\curl_ntlm.c:
lib\curl_ntlm_core.[ch]:
lib\curl_ntlm_msgs.[ch]:
Provide NTLM fallback to GnuTLS/OpenSSL/NSS if SSPI is not enabled.

Generally speaking this means that the combination of USE_NTLM and
USE_WINDOWS_SSPI is actually equal to the proposed USE_WINDOWS_SSO.

USE_NTLM works with USE_OPENSSL, USE_GNUTLS_NETTLE, USE_GNUTLS, USE_NSS
or USE_WINDOWS_SSPI. I think it should stay like it is, because this way
NTLM uses whatever crypto library/provider is available. And as Windows
SSPI can be compared to OpenSSL, they should be handled the same.

Introducing a new define like USE_WINDOWS_SSO just for USE_NTLM could be
compared to adding a USE_OPENSSL_X define for every OpenSSL feature X

lib\curl_sspi.[ch]:
Provides generally SSPI shared library loader functionality.

As explained earlier, I think this should also stay with
USE_WINDOWS_SSPI and provide a general interface for all other SSPI
features to use.

lib\setup.h:
lib\http_negotiate.h:
lib\http_negotiate_sspi.c:
Provides Single-Sign-On functionality for USE_HTTP_NEGOTIATE.

This might be a functionality there it would make sense to introduce a
new define. At the moment setup.h defines USE_HTTP_NEGOTIATE as soon as
HAVE_GSSAPI or USE_WINDOWS_SSPI. So setup.h should probably be changed
to require a special define to enable USE_HTTP_NEGOTIATE. It currently
provides checks the defines CURL_DISABLE_HTTP and CURL_DISABLE_NTLM to
disable this functionality.

The same applies to NTLM functionality. Instead of requiring USE_NTLM to
be defined by configure, USE_NTLM is defined as soon as HAVE_GSSAPI or
USE_WINDOWS_SSPI is defined.

Generally speaking this means that setup.h is currently the place where
everything is flipped. Instead of requiring special feature defines, it
defines them as soon as the library/provider defines exist.

lib\url.c:
lib\urldata.h:
Provide general functionality for SSPI integration. Not relevant IMHO.

lib\easy.c:
lib\smtp.c:
Perform SSPI cleanup if initialized by NTLM support. Not relevant IMHO.

lib\socks.[ch]
lib\socks_sspi.c:
Provides Kerberos functionality for SOCKS5.

I am really not sure about this one. This time USE_WINDOWS_SSPI is used
as the Windows alternative and fallback to HAVE_GSSAPI.

It is used for Single-Sign-On, right?

lib\version.c:
Provide SSPI version information. Will need to be adapted eventually.

src\tool_*.c:
Provide curl parameter and version information integration. Will need
to be adapted eventually.

So, I am not sure where to start and for what features we want to have a
separate define. I think USE_WINDOWS_SSPI should be used for the swap-in
library/provider code where SSPI actually does not provide a standalone
feature, but hosts an alternative to other crypto libraries.

What's your opinion on this? We may want to plan this before any code
changes are made.

Best regards,
Marc
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-05-13