On Fri, Sep 03, 2010 at 08:00:38AM +0200, Martin Koegler wrote:
> On Thu, Sep 02, 2010 at 08:48:47PM -0600, DRC wrote:
> > On 9/2/10 9:50 AM, Adam Tkac wrote:
> > > This type is, by default, disabled on the server. It must be enabled
> > > via commandline parameter (-SecurityTypes). Client has it disabled as
> > > well but if user specify he wants to use it (and server has Plain type
> > > enabled) then it is used. If it is client's first sectype then it is
> > > preferred over more "strong" mechanisms (TLS, for example).
> >
> > IMHO, the correct behavior should be that if the server enables this
> > security type before other security types, then the client should use it
> > unless the user specifically passes the -SecurityTypes parameter to the
> > client to disable the type. IOW, I think the Plain type should be
> > enabled by default on the client but not given priority. I agree that
> > it should not be enabled on the server without an explicit override.
>
> The client side honors the Security Type order of the server - code
> for using the client side order was removed with "Remove unused
> CConnection::setClientSecTypeOrder function" on Jul 20 2010.
If I read rfb/CConnection.cxx:CConnection::processSecurityTypesMsg()
well, client side doesn't honor server's order. Client side preference
order is specified via -SecurityTypes parameter.
$ cat CConnection.cxx
...
void CConnection::processSecurityTypesMsg()
...
for (int i = 0; i < nServerSecTypes; i++) {
rdr::U8 serverSecType = is->readU8();
vlog.debug("Server offers security type %s(%d)",
secTypeName(serverSecType),serverSecType);
// We keep trying types, to find the one that matches and
// which appears first in the client's list of supported types.
for (j = secTypes.begin(), secTypePos = 0; j != secTypes.end(); j++,
secTypePos++) {
if (*j == serverSecType && secTypePos < secTypePosMin) {
secType = *j;
secTypePosMin = secTypePos;
break;
}
}
}
...
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
