2011/8/21 Steve Holme wrote:

Last remaining bits extracted from
0001-Moved-ntlm-specific-code-into-separate-curl_ntlm-mod_3.patch have
just been pushed to master. Is there really a need for so long names?
65 chars wow!

> Many thanks - it is much appreciated. I spent just over 2 days (about 20
> hours) writing the original modification to Libcurl and since then nearly 35
> hours on producing the various patches.

We really appreciate your efforts and time in the same way we do with
ours, with the added responsibility, efforts and time, on our side of
trying not to break existing code and functionality when new features,
or important changes, are introduced in order to keep libcurl top
notch.

Sometimes in order to achieve this it is necessary to push other,
apparently non-related, changes in between.

> At what stage are we now? I see there hasn't been any feedback about the
> code moving to curl_ntlm.[ch] so can we start to introduce the smtp code
> changes to introduce the NTLM feature?

Stage one is to be considered finished with last commit already done.
So I would say, in front of stage two or three. This really depends if
there are still pending changes to existing code that are independent
of NTLM support for other protocols than http.

For example, in first message of this thread you said:

> * Modified the order of the preferred authentication method to AUTH NTLM,
> AUTH CRAM-MD5, AUTH LOGIN then AUTH PLAIN. AUTH PLAIN should be the last as
> it is the most insecure.

That would be stage two. Please start a new thread with proposed patch
for that, and whatever comments you desire to convince others that the
fix/change is convenient.

You also said:

> * Added the ability for the user to specify whether authenticated
> connections (AUTH NTLM, AUTH LOGIN and AUTH PLAIN) send the initial response
> in the AUTH command or in the next command. This can be set via the
> CURLOPT_MAIL_SINGLE_AUTH option but defaults to TRUE to maintain
> compatibility with the v7.21.7 source.

Given that CURLOPT_MAIL_SINGLE_AUTH would be a new option this should
be considered stage three as a whole.

On the other hand I understand that some glue has to be introduced in
existing NTLM code in order to allow handling new option while
retaining existing behavior when not used. So there has to be part of
that whole that can be introduced now in preparation of stage three
and that currently would simply keep existing NTLM operation relative
to initial response sending.

Provide patch for this preparation on this thread. But please, keep it
to the minimum ;-) Don't squash something you have over current git.

Ball on your side,

-- 
-=[Yang]=-
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html