On Sat, Jul 17, 2010 at 04:47:22PM +0200, Martin Koegler wrote: > This patchset contains various fixes/changes related to the security type > handling.
Hello Martin, I've reviewed & commited your patches, you can read my comments. Thank you very much, they really cleaned up the VeNCrypt code. > 1 removes a leftover declaration Accepted. > 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. > The rest 5-12 implements a seamless integration of the VeNCrypt security type. > The VeNCrypt security type was intended to be a generic selector allowing to > extend > the number of possible security types from 2^8 to 2^32, so that every little > project > can get their security types. The VeNCrypt code allowed to also negotiate > "traditional" > security types like None and VncAuth. This patch aligns tigervnc with the > VeNCrypt behaviour. > > With the patch, only the SecurityTypes parameter is left. It allows specifing > "old" and "new" > security types in one list, eg: VncAuth,TLSNone,None > The code will negotiate the first type of the server SecurityTypes paramter, > which is also enabled > on the client (unless the viewer would enable the client preference option). > > 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. VeNCrypt related patches were accepted with minor changes. 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
