On Thursday, August 1, 2002, at 01:01 PM, Ben Collins-Sussman wrote:
> Daniel Berlin <dberlin@dberlin.org> writes:
>
>> We only need to provide some callbacks for neon, and be able to
>> provide
>> client certificates for it when requested.
>
> I didn't realize neon already understood certificate challenges -- I
> thought we were blocking on that feature!
>
> So the *real* challenge of this issue is coming up with a nice way to
> store and manage certificates. I suspect that stashing certs in every
> single .svn/auth/ area (as we do with 'username' and 'password' files)
> isn't going to fly very well. Maybe a subdir within ~/.subversion/
> needs to hold them.
Actually, I did it like proxies.
That way, wherever the heck they want to put the certs is fine, they
just tell us where it is.
IE we have an ini file (or registry, in the case of windows) in
.subversion with
[groups]
Apache = *.apache.org
[Apache]
certificate=/etc/myapachecert.pem
It doesn't make sense to make client certs an authenticator in and of
itself:
1. It forces certificate management to be done by the client,
entirely, for no good reason. If it's just an ini file, it can still
easily be managed by the client, but the client doesn't have to worry
about all the specifics and stuff behind the scenes.
2. Neon expects the certs to be loaded using neon's cert loading
functions. Thus, if the client manages certs completely on it's own,
it now needs to link with neon and use these functions.
3. There's no really good other way to manage certs anyway, so each
client will likely come up with something like an ini file anyway (or
registry, in the case of windows), each completely incompatible.
It's like forcing clients to manage proxy information entirely. It's
much easier to let them manage the ini file, and take care of the
details for them.
>
> But now I fear we're jumping the gun yet again; gstein had/has plans
> to write libsvn_auth, which would be a big reorganization of how the
> client manages credentials in general. Maybe that library should
> happen first?
>
>
> ---------------------------------------------------------------------
> 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 Thu Aug 1 19:34:59 2002