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

Re: certs review

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-03-12 20:04:41 CET

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".

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.

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 12 18:06:02 2003

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.