On Wed, Jul 21, 2010 at 12:04:42AM +0200, Martin Koegler wrote:
> On Tue, Jul 20, 2010 at 05:25:16PM +0200, Adam Tkac wrote:
>
> Thank you for your effort.
>
> > On Sat, Jul 17, 2010 at 04:47:22PM +0200, Martin Koegler wrote:
> > > 2-4 fixes the security type parameter in the vncviewer. The viewer has
> > > the problem, that
> > > the handshake phase in the viewer uses a hardcoded list containing all
> > > security types.
> > > The code creating CSecurity only honors the SecurityTypes parameter,
> > > which only defaults to VncAuth.
> > > If multiple types are active in the server, vncviewer can select a type
> > > disallowed by SecurityTypes.
> > >
> > > The problem is fixed by:
> > > * Overriding the default value of SecurityTypes in the viewer
> > > * Using the content of SecurityTypes in the handshake phase
> >
> > In my opinion those fixes were too complicated. I reused code from
> > Security class and now viewer uses same mechanism as server. Allowed
> > security types are controlled via -SecurityTypes option, as in server.
>
> A typical user probably only wants to connect to a VNC server without
> guessing the correct security type and overriding settings via
> parameters. So please change the default value in the viewer, so that
> it enables all security types. The default value of the server should
> stay the same, so that nobody can start a server without authentification
> by chance.
>
> As the Security class is shared between server and client, I had no
> better idea to implement this.
This is a valid argument but I would like to see feedback from other
TigerVNC developers to decide which types should be enabled by
default. I will open a separate thread for this.
> > > Internally, server and client will always add VeNCrypt as first element
> > > of their list and add all
> > > "old" security types of SecurityTypes after that. So if client or server
> > > don't support VeNCrypt,
> > > they can only negotiate None or VncAuth.
> >
> > In my opinion this should be configurable, not hardcoded. I haven't
> > updated default SecurityTypes value yet, I will do it when I merge
> > X509 support.
>
> In Security::GetEnabledExtSecTypes,
> if (*i >= 0x100)
> derives the behaviour from the original VeNCrypt code. It allowed the
> usage of VncAuth and None too:
>
> | bool SSecurityFactoryTLS::isSecTypeSupported(rdr::U32 secType) {
> | switch (secType) {
> | #ifdef HAVE_GNUTLS
> | case secTypePlain:
> | case secTypeTLSNone:
> | case secTypeTLSVnc:
> | case secTypeTLSPlain:
> | case secTypeX509None:
> | case secTypeX509Vnc:
> | case secTypeX509Plain:
> | case secTypeVeNCrypt:
> | #endif
> | return true;
> | default:
> | return SSecurityFactoryStandard::isSecTypeSupported(secType);
> | }
> | }
You are right, current code in TigerVNC trunk is stricter than
VeNCrypt. However I tried to test original VeNCrypt code and gtk-vnc
implementation (which implements VeNCrypt and popular vinagre client
is based on it) and vinagre can't cope with "standard" security
types as VeNCrypt subtypes.
Do you think this functionality is really useful? From my point of
view, when there is no interesection between VeNCrypt subtypes between
client & server then client can simply not use VeNCrypt and use
standard security type, can't it?
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
