Greg Stein wrote:
>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?
>
Clients. Note that I don't care if these methods are in their own header
or not.
>>...
>>* 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?
>
The providers are implemented in libsvn_ra_dav/session.c, along with
getter methods. The cmdline client in the branch already uses all of them.
>>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.
>
These are currently included in libsvn_ra_dav merely for locality -
although I suppose eventually these same providers could be used for ra_svn.
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.
With a neon compiled without SSL support, most of the functions stay the
same, but the auth providers cannot fire.
>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?)
>
A GUI provider could also use the neon-parsed certificate fields. If we
eventually want to rely on neon being compiled against openssl, we could
also expose lower-level support
-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 06:34:11 2003