On Thu, Feb 10, 2011 at 04:01:26AM -0600, DRC wrote: > We had one-- the Tight Security Extension. :) I signed off on removing > it before I fully understood the ramifications.
Please don't mix up Encryption with VeNCrypt. VeNCrypt consists of two parts: 1) An extended chooser, which has enough available security type numbers even for every hobby developer. 2) New security types (TLS encryption with/without certificates, Username/Password authentification + various combinations also reusing the classic security types). The Tight security extension was a different chooser implementation (so was something similar to 1): It included a (never implemented) tunnel type [=encryption] and an authentification type. So the main difference is, that with VeNCrypt you can say that the server allows "(TLS with VNCAuth) or (X509 with None)", while tight allowed only "(TLS or X509) and (VNCAuth or None)". Any security type (encryption or authentification) can be hooked into VeNCrypt as it could be hooked into the Tight Security Type. Side node: In my option, it would be the best, to let the VeNCrypt security type vanish for our users (by putting it automatically as first element to the list of enabled security types) - so enabling it by default as done for the tight security type. This still works, even if the user only enables VNCAuth/None and/or communicates with a non-VenCrypt capable VNC implementation. A user is more likely to think, that he wants eg. X509Plain as first, VncAuth as second and TLSNone as third alternative. Currently, he has to add VeNCrypt manually. If he does not add it as first element, the effective order is different: * First come all standard security types from the list up to the position of VeNcrypt. * After that the whole list is appended. Regards, Martin Kögler ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
