[cvsnt] Re: Linux & sserver?

[Rolf Wilms]

Thanks a lot for your comments. After thinking about this a bit more, I came
to the conclusion that the change to make "require encryption" work with
Eclipse should be made in Eclipse. While I still believe that it would also
be possible to make that change in CVSNT, this would only work with sserver.
In the case of gssapi or sspi it wouldn't, because here wrap/unwrap are not
noops. I think Eclipse needs to allow connection methods to provide their
own response handlers to make this all work.


"Tony Hoyle" <tmh at nodomain.org> schrieb im Newsbeitrag
news:c6k9l6$88o$1 at paris.nodomain.org...
> Rolf Wilms wrote:
> > If you're talking about Eclipse using sserver to connect to a CVSNT set
to
> > "Require Encryption", then it may be related to the following problem:
> >
> > CVSNT expects the client to send "Protocol-encrypt" as a response when
> > there is "Require Encryption". Eclipse does not know about this
response.
> > I see two options to resolve this problem:
> >
> > a) Eclipse is extended at the command level to support
"Protocol-encrypt".
>
> Or it could send Gssapi-encrypt (which should already be supported on some
> level by eclipse as it's a standard part of the original protocol).  The
> old name still works as a synonym even though encryption has moved on
since
> then.
>
> > b) CVSNT removes this requirement since with sserver the encryption is
> > done at the connection level and "Protocol-encrypt" is a noop anyway.
>
> It isn't a noop - it actually changes the way the server talks to the
> client.  On sserver the implementation is (currently) a noop, but it's not
> an optional part of the encryption process.
>
> It also validates that the client has stated that the protocol is in fact
> encrypted - there's a handshake in which the server asks for or demands
> encryption, and the client acknowledges that request.  It is entirely
> possible to make a plaintext sserver client - plaintext SSL exists (I may
> implement it someday to support the authentication only encryption that is
> currently the same as encryption on sserver).
>
> Tony
>
>
>