Sigfred Håversen wrote:
> Is the reason for not wanting SSL in all cases due to a concern for
> consumption of CPU resources? I can understand that SSL on anonymous access
> might be too much for a server.
There are at least two reasons I can think of. First is CPU resources,
second is increasing the requirements on your users. If a person only
wants annonymous access and never needs to commit changes there's no
reason to require them to have openssl installed.
> 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 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.
>>>>> * The client must at least use version 2 of the svnserve protocol.
>>>>
>
> Since the source code says that version 1 should be deprecated, I decided not
> to implent SSL for that protocol.
Yeah, I don't see any reason to support version 1 anymore, I doubt there
are a whole lot of people using it, and there's certainly no reason to
support it for SSL, since anyone who can upgrade to get SSL support
already has version 2 ;-)
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 20 15:46:50 2004