On Thu, Jun 20, 2013 at 11:27 AM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> Mark,
>
> Wearing my VisualSVN CTO hat:
> VisualSVN is a commercial company. And CollabNET is a commercial
> company. That's not a surprise.
>
> And it's not a surprise that VisualSVN Server authentication works
> fine after upgrade to Subversion 1.8. We have spent months with
> testing and debugging. It will be surprise if you haven't do the same
> for all configurations that you support. There were huge changes in
> area of authentication. Neon was removed, at least!
Honestly, I am glad to see you finally put your hat on. I have been
intentionally refraining from accusing of you vetoing this for
VisualSVN reasons.
CollabNet has no factor in this at all. We do not support SSPI in any
of our products. Though we have customers that would like to have
automatic authentication, none of them do as we do not provide or
support it. The only hat I am wearing here is as a longtime community
member that knows from forum activity there are a lot of people that
use this. In my past life, where we used Windows on our servers, we
used this. This would have been back in SVN 1.3 days.
> Also please believe that all my technical thoughts are fair and
> related to technical issues only. My veto above is a technical veto.
That is not at all how it sounded. Your reply below is much better
but the original veto sounded like were simply opposed to supporting
NTLM. Again, your reply below in contrast only makes that more clear.
> I may agree that this problem should be fixed. But it should be fixed
> in the proper place and in the proper way.
No objections from me on that.
>
> Did you read my email above? Let me explain again. Server advertises
> supported authentication schemes, for example Microsoft IIS:
> [[[
> C: GET / HTTP/1.1
> S: HTTP/1.1 401 Authorization Required
> S: WWW-Authenticate: NTLM
> S: WWW-Authenticate: Negotiate
> S: WWW-Authenticate: Basic
> ]]]
>
> Then client decide which authentication scheme to use. Serf tries to
> Negotiate, then Basic. But with proposed patch serf will try
> Negotiate, then Basic and then NTLM again, which is wrong because NTLM
> authentication already handled inside Negotiate protocol. This is one
> of the reasons why I vetoed this patch.
OK, sounds like a valid objection.
>
> My point is that serf should use NTLM *only* if server doesn't
> advertise support Negotiate.
>
> mod_auth_sspi is too simple and supports only one auth scheme which is
> controlled by SSPIPackage configuration directive. For example with
> "SSPIPackage NTLM" it offer only NTLM:
> [[[
> C: GET / HTTP/1.1
> S: HTTP/1.1 401 Authorization Required
> S: WWW-Authenticate: NTLM
> S: WWW-Authenticate: Basic
> ]]]
>
> Proper solution is to reconfigure mod_auth_sspi to use Negotiate auth
> scheme using "SSPIPackage Negotiate" directive. It this case
> mod_auth_sspi response will be:
> [[[
> C: GET / HTTP/1.1
> S: HTTP/1.1 401 Authorization Required
> S: WWW-Authenticate: Negotiate
> S: WWW-Authenticate: Basic
> ]]]
>
> And serf will handle it. But neon doesn't work in this case :) Why
> you're not fixing neon?
Now you are being ridiculous again. Maybe Neon ought to be fixed but
that would not change the fact that clients which are working
perfectly well would suddenly stop working.
> You didn't understand properly my second point about duplicating
> authentication code that already there in auth/auth_kerb.c (it's
> actually should be auth_rfc4559.c). It's not aesthetic issue, because
> auth/auth_kerb.c handles a lot of different cases that could happen
> during rfc4559 style authentications. This code is platform
> independent and tested with various servers like mod_auth_kerb, Apache
> TomCat, IIS, VisualSVN Server and others. And NTLM implementation in
> serf should reuse this tested and complicated code in auth_kerb.c.
>
> I'm going to try to plug NTLM properly in the current serf auth
> architecture on the next week.
That sounds great. If Serf "prefers" negotiate over NTLM that sounds
fine to me. But if the server is only offering NTLM it ought to work
if it is possible.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2013-06-20 17:55:09 CEST