Re: certs review

On Mon, Mar 10, 2003 at 04:48:57PM -0800, Ben Collins-Sussman wrote:
>
> David, here's a short review of all the cumulative changes you've made
> to your issue-650-certs branch:
>
>
> * svn_ra_dav_h

Who is going to include this?

>...
> * This is great stuff, all in all. As you said, there are still a
> couple of pieces needed to make this cert-stuff feature complete:
>
> * a prompting provider for server-certs. presumably the specific
> error would arrive via auth_baton runtime hash, and the provider
> would ask the user if the particular error is ok to ignore. it
> also means that this provider could be loaded unconditionally,
> and server-certs could be validated even when no CAcerts.pem
> file is mentioned in the config file.
>
> * a prompting provider for client-certs. it can simply ask for
> the location of a key file.
>
> Both prompting providers would be registered *after* file providers,
> and make use of the prompt function within svn_client_ctx_t.

And how does the app get to these providers?

> Keep up the great work! I feel a merge to trunk coming very soon.

I see a big problem to solve before doing any kind of a merge. Two points:

1) what lib are these providers defined within?
2) how does the app decide to link against that lib and include them into
   the list of providers?

For example, if we say the lib is 'libsvn_ra_dav', then we have a problem
with that link from the client to ra_dav. That direct link doesn't happen
today; instead, the app links to RA, which then links to the "available" RA
specific libraries.

Also, do we always want to link to those providers? The answer basically
relies on "do we have SSL available?" Of course, we don't actually do that
detection -- Neon does.

The code is nice and all, but I don't see an obvious path for linking it
into the client(s). (just realized that: what about GUI clients wanting to
make use of this stuff, too?)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org