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

Re: [PATCH] SSL layer for svnserve

From: Sigfred Håversen <bsdlist_at_mumak.com>
Date: 2004-10-20 18:42:28 CEST

On Wednesday 20 October 2004 15.45, Garrett Rooney wrote:
> Sigfred Håversen wrote:
> > We could allow non-SSL access for anonymous users, but all other users
> > are required to use SSL. svnserve could send this in the greeting as a
> > new capability "ssl-auth", meaning that anonymous access may or may not
> > be encrypted at the discreetion of the client.
> >
> > So svnserve will send one of two capabilities :
> >
> > ssl All access must must SSL
> > ssl-auth All access, except anonymous, must use SSL.
> >
> > The client will then respond with the capability "ssl" for starting the
> > SSL handshake. If no SSL is wanted by the client, then it will not send
> > the ssl capability. Note that a client may very well use SSL even for
> > anonymous access.
> >
> > With the two ssl capabilities, the setup and usage of SSL in svnserve
> > should be fairly easy to understand as well as administrate.
> That seems reasonable to me.
> >>>I also don't much like the mess of new command-line options. I'd like
> >>>to either see these moved to the repository config file (although that
> >>>means the greeting will specify the "ssl" capability even if the server
> >>>has configured no certificates, which means the ssl handshake had better
> >>>do something intelligent even if there are no certificates), or see
> >>>svnserve grow a server configuration file before we add this many global
> >>>options.
> >>
> >>Yeah, since the remainder of the svnserve configuration stuff is
> >>
> >>>per-repository it seems like this should be as well.
> >
> > 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.

If the certificate is specified in the repo config, then svnserve does not
know if it has a valid certificate when a client connects. All it knows
is that it can handle SSL, if needed. The more tricky part is to handle
the SSL handshake, and that probably require more communication between
client and svnserve before actual SSL handshake. After the greeting, svnserve
can check that a certificate is indeed present in the repo, and then
load/verify it. At this stage the client and svnserve can continue with the
SSL as desribed above. Actually, with this approach svnserve does not need to
announce ssl capability at greeting as this will be handled with further
handshaking. But this does add complexity, and perhaps a change in the
protocoll as well.

> If you do want the ability to have a single auth configuration that
> affects all repositories, perhaps we could add it in as a command line
> option (or a global config file or whatever) that can be overridden in
> the individual repositories, but honestly I don't think it's that
> important, the per-repository stuff seems to work just fine now.

I think that having two different places for SSL certificates might be


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 20 18:42:55 2004

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.