I hope to review this stuff more closely soon. mbk proposed creating a
branch for it; that way we can commit it without addressing all of the
build system and configuration issues immediately.
On Mon, 2004-10-18 at 16:00, Garrett Rooney wrote:
> > * svnserve will refuse clients that does not have SSL capability.
>
> I'm not sure this is the way we should go on this...
Clearly not.
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.
> > * Since the realm is sendt as part of the greeting, this will not be
> > encrypted.
>
> That's unfortunate. Do you see a good way to change the protocol to
> avoid the leakage?
I'm not quite sure why the word "realm" is being used here. The only
"realm" involved in the svn protocol is the authentication realm, which
is not sent as part of the initial greeting.
If you mean the client URL, there is actually a reason to send this in
plain text: you may want to use different certificates (client and
server) for different repositories. Think of the client URL (or at
least the repository part of it) as an extension of the hostname and
port number.
If we decide that it's more important to hide the client URL than it is
to allow repository-dependent SSL negotiation parameters, then we can do
it, but it's a little tricky. It would go like this: the client sees
the "ssl" capability in the server and knows it's going to respond with
an "ssl" capability, so it knows there will be an SSL handshake. So it
sends a placeholder in the client URL, and then sends the real client
URL as the first thing after the SSL security layer has been negotiated.
> > * The client must at least use version 2 of the svnserve protocol.
>
> That's perfectly fine with me ;-)
I'm not sure what this means. If we're going to completely drop support
for 0.32 clients, that's probably okay, but I don't know that there's a
good reason for it. If this just means that only version 2 clients can
support SSL, that's obviously fine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 19 01:21:42 2004