Ben Collins-Sussman wrote:
>David Waite <mass@akuma.org> writes:
>
>
>
>>The only dependancy the existing providers have have on neon is the
>>set of failure flags passed in to the server cert validator. The
>>prompting providers will rely on pulling the (neon-parsed) certificate
>>structure out of the auth baton hash. Neither one of these should be a
>>runtime dependancy.
>>
>>
>
>I think our final goal is this:
>
> * libsvn_ra_dav is the only library dependent on neon.
> *theoretically*, it may not be compiled at all: no ra_dav, no neon.
> It's perfectly fine for a client (cmdline, gui, etc) to pick and
> choose which RA layers are built and loaded via DSO.
>
> * the neon cert callbacks are defined in libsvn_ra_dav, obviously,
> since they depend on neon.
>
> * the cert *providers* are defined in libsvn_client, making them
> usable by any client, and any RA layer.
>
> * the cert providers shouldn't depend on neon, since ra_dav may not
> exist. they should define the credentials they return as
> abstractly as possible: "path to a client cert file",
> "passphrase to unlock a cert", or "server cert errors we can
> ignore".
>
We can have our own flags for the SSL errors to remove the dependancy on
neon for the structures. However, there may also be neon values passed
in via the auth baton structure, such as the neon ssl certificate field
structure. What would be appropriate in the case where the cmdline
server cert provider wants to display the fields of the certificate when
asking the user if they wish to override the warnings - where would this
provider be located?
>Does that make sense, David? Do you think you can migrate the
>providers into libsvn_client and then redefine the server-cert error
>codes in svn itself (svn_error_codes.h)? You'd simply have your neon
>callback 'map' the neon error codes to svn error codes.
>
I am not sure about the last case above - I was actually going to move
things over to libsvn_client last night, but deferred because of the
neon dependancy for the cmdline client fields.
>Ultimately, gstein and I have been discussing doing away with
>libsvn_auth altogether: the library, that is. The library has only a
>single C file with provider registration and looping logic... so we'll
>probably end up moving that C file into libsvn_subr, and toss
>libsvn_auth. svn_auth.h won't change a bit.
>
Very cool :-)
-David Waite
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 12 21:12:05 2003