Greg Hudson wrote:
> 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.
That seems like a good idea.
> 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.
Yeah, since the remainder of the svnserve configuration stuff is
per-repository it seems like this should be as well.
>>> * 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.
Yeah, I can see how that could work, but I'm not sure it's worth the
complexity.
>>> * 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.
I'm pretty sure (judging from the code) that it does mean only version 2
clients can support SSL.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 19 04:58:43 2004