[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: On backporting r21531 to 1.4.x.

From: Vladimir Berezniker <vmpn_at_hitechman.com>
Date: 2006-10-17 01:39:21 CEST

I was away and will get back to you as soon as I got a chance to read through
the information that you provide.

Regards,

Vladimir

Samay wrote:
> Hello Vladimir,
>
> this is from a 'user' perspective. Below is a reference to how Mozilla
> Firefox addresses / facilitates SSPI/SPNego/ authentication methods.
>
> http://www.mozilla.org/projects/netlib/integrated-auth.html
>
> they have a rather simple configuration method. user configures list
> of 'servers' where Negotiate authentication should be used. They also
> provide Proxy support.
>
> as regards SSPI issues?
> a) SVN 1.4.x compiled against 0.26.1 Neon doesnt work with SPNego on
> both win32 & linux environment. However, it works fine with 0.25.5
> Neon. May be its how SVN is making use of 0.26.1 changes that is the
> issue here, beyond my skill set. I am trying to learn though.
> b) please refer to http://svn.haxx.se/users/archive-2006-09/1336.shtml
> ... not sure if this is happening due to Neon or Mod_auth_kerb ..
> however mentioned here for ur reference.
>
>> 1) Ability to disable default credential being passed.
>
> please see Mozilla link above, the configuration layout, provides
> that. In case of Negotiate, 'only' default credential, in form of Kerb
> token, are provided.
>
>> 2) Ability to pass alternate credentials but still use SSPI
>
> I doubt if its gonna be possible in case support is
> Negotiate/GSSAPI only. Usually this is provided by external helpers
> such as 'runas', 'sudo', 'kinit', etc.
>
>> 3) Ignore SSPI challenge all together
>> 4) Ability to have separate proxy, server credentials???
>
> e.g., open Pref.js in ur Firefox profile (or go to URL about:config)
> and search for Auth :) I would have posted a link to
> google.com/codesearch page for that, however, not sure what policies
> we have regarding quoting external code.
>
>> 5) Issue with GUEST credentials being used
>
> regards
>
>
> Samay
>
>
> ----- Original Message ----- From: "Vladimir Berezniker"
> <vmpn@hitechman.com>
> To: "Mark Phippard" <markp@softlanding.com>
> Cc: "C. Michael Pilato" <cmpilato@collab.net>;
> <dev@subversion.tigris.org>; "Stefan Küng" <tortoisesvn@gmail.com>
> Sent: Friday, October 13, 2006 12:14 AM
> Subject: Re: On backporting r21531 to 1.4.x.
>
>
> Resending this as original did not seem to reach the list.
>
>> "C. Michael Pilato" <cmpilato@collab.net> wrote on 10/09/2006
>> 04:01:28 PM:
>>
>>> Uh. Hm. Can you perhaps rephrase this bit, then? I obviously missed
>>> it the first time around.
>>>
>>> (that's also why I think the current (trunk) behavior of Subversion
>>> should be improved: avoid the option in the configuration file but
>>> after the first authorization failure and reauthenticate again but
>>> this time with SSPI disabled).
>>
>> I think the only issue should be whether the current way this works is
>> deemed a bug with a high enough severity to backport to an existing
>> release. I happen to think it is.
>>
>> Once that is agreed to, then whatever the best solution is,
>> regardless as
>> to whether it involves adding a new config option, should be used. Having
>> a client authenticate, fail authorization and then reauthenticate
>> does not
>> strike me as an ideal solution. Won't this happen over and over again?
>> Having an option to just turn the feature off seems better to me and
>> I do
>> not see what negative impact this has on existing 1.4 users.
>>
>> Mark
>>
>>
> Hello everyone,
>
> I am the guy who originally contributed the SSPI support to neon, and I
> would like to get it working right for majority of the users.
>
> A possible plan of attack would be:
> * Clearly define what SSPI issues are
> * Agree if there are neon API changes needed. Driven by users such as
> Subversion/TSVN
> * Clear those changes with Joe Orton (if any)
> * Implement, test, repeat...
>
>
> The SSPI issues as I understood so far are:
>
> 1) Ability to disable default credential being passed.
> 2) Ability to pass alternate credentials but still use SSPI
> 3) Ignore SSPI challenge all together
> 4) Ability to have separate proxy, server credentials???
> 5) Issue with GUEST credentials being used
>
> Please let me know if I missed anything.
>
> I have a good idea about how to deal with the first four (4). I need to
> research the GUEST issue, so any relevant info will be appreciated.
>
> At a first glance, it seems the current flag in neon can only solve #3,
> but I need to check the code to be sure.
>
> For the Subversion/TSVN team,
>
> What kind of API in neon would make it cleanest for you to work with
> SSPI?
>
> Regards,
>
> Vladimir
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 17 01:39:39 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.