On Wednesday 20 October 2004 15.45, Garrett Rooney wrote:
> Sigfred Håversen wrote:
>> I would prefer that svnserve has it's configuration file separate from
>> the repository config file. It think it will be simpler to
>> administrate,
>> as well as code, to let svnserve have a certificate that is shared
>> with
>> all the repositories. This does not exclude the possibility of client
>> authentication based upon client certificates, though. The approved
>> client certificates should be per repository, and listed in the
>> repository config file, of course.
>
> I don't see why SSL configuration should be any different from
> svnserve's current auth options, which are per-repository. I know that
> I personally have multiple repositories served up via svnserve on my
> server, and they have different sets of users and different rules
> regarding authentication. There doesn't seem to be any reason (IMO) to
> make SSL a special case.
What if someone is serving the same repository from two different
machines? (Maybe serving FSFS repository off a high-performance SAN,
would that work?) Or two different interfaces on the same
high-performance machine using a local disk? (That would probably work
today with either BDB or FSFS.)
Since server cert is tied to hostname, having this per-repos-config
seems like it might be problematic. Each server servicing a particular
interface will need a different server certificate. (It seems to me
that the use of CN=hostname requirement for SSL on the web is limiting
and that fundamentally, a checking of anything specifically expected
such as a realm name by a particular CA would be a good
alternative--just as the server expects to get in a client certificate,
but I don't know that the available SSL libraries are written to
support such client-cert<=>client-cert communication.)
Using Apache, we have a per-server config file for this (Apache's own
config file), so this would work with Apache.
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 20 19:25:57 2004