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.
Thanks for your patchset, after quick look they seem fine and really useful
for me.
I will process & commit them this week, together with the X509 support which
is already in my patch queue so VeNCrypt support should be finally complete.
Regards, Adam
> 1 removes a leftover declaration
>
> 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
>
> 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.
> If both support VeNCrypt, the server will send the full list also containing
> TLSNone, TLSVnc, ...
> As a side effect, the VeNCrypt selector is now always compiled in.
> HAVE_GNUTLS only disables compiling
> the TLS based security types.
>
> 7 enhance the normal security type parsing code, so that it can support 2^32
> security types.
> 6+8+11+12 integrate the VeNCrypt security types into the normal code
>
> Regards,
> Martin K�gler
>
> Martin Koegler (13):
> 1) Remove leftover code
> 2) Allow changing the default value of string parameters
> 3) Fix default security type setting of vncviewer
> 4) Use SecurityTypes Parameter in vncviewer
> 5) Variable is only used as CSecurity/SSecurity
> 6) Move VeNCrypt security types
> 7) Use U32 as internal SecurityType type
> 8) Support VeNCrypt Security types in normal security type parser
> 9) Add logging code
> 10) Pass Security instance to VeNCrypt security
> 11) Use SecurityType also as configuration for VeNCrypt
> 12) Create VeNCrypt security types in Security class
> 13) Move x509 certificate parameters
>
> common/rfb/CConnection.cxx | 30 ++++-----
> common/rfb/CConnection.h | 8 ---
> common/rfb/CSecurityVeNCrypt.cxx | 52 +++------------
> common/rfb/CSecurityVeNCrypt.h | 7 +-
> common/rfb/Configuration.cxx | 6 ++
> common/rfb/Configuration.h | 1 +
> common/rfb/Makefile.am | 16 +++--
> common/rfb/SSecurityPlain.cxx | 4 -
> common/rfb/SSecurityPlain.h | 4 -
> common/rfb/SSecurityVeNCrypt.cxx | 128
> ++------------------------------------
> common/rfb/SSecurityVeNCrypt.h | 27 +-------
> common/rfb/Security.cxx | 105 ++++++++++++++++++++++++++-----
> common/rfb/Security.h | 31 ++++++---
> unix/vncviewer/CConn.cxx | 3 -
> unix/vncviewer/vncviewer.cxx | 1 +
> win/vncviewer/CConn.cxx | 2 -
> win/vncviewer/CConn.h | 1 -
> win/vncviewer/vncviewer.cxx | 1 +
> 18 files changed, 165 insertions(+), 262 deletions(-)
>
>
> ------------------------------------------------------------------------------
> 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
--
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
