On Thu, Nov 11, 2010 at 03:42:39PM +0100, Adam Tkac wrote:
6. Implment TLS security type
7. Implement X509 Security types
Just a design question. Wouldn't be better to merge TLSTunnel,
TLSTunnelBase and X509Tunnel classes to the one class as I did it in
common/rfb/CSecurityTLS.*? In my
Honestly, I didn't develop those extensions, so I'm trying to process
the information second-hand. :) If the same functionality can be
implemented without using the Tight security type, then I guess I have
no problem with removing it. UCAR ultimately wants to look at
implementing the TurboVNC
This patchset updates the java code so that it can support all VeNCrypt security
types.
On thing I noticed, is that the tigervnc server and java client (but not the
unix/win client)
support the TightVNC security type.
This security type is selected by default, if it is supported by server and
TurboVNC 1.0 uses the Tight security type to implement its auth
extensions, and it relies upon the ability to advertise capabilities to
the client using that mechanism. Whether or not the Tight security type
actually does anything in our implementation, I think it is important to
be able to
On Sun, Nov 07, 2010 at 12:52:54PM -0600, DRC wrote:
TurboVNC 1.0 uses the Tight security type to implement its auth
extensions, and it relies upon the ability to advertise capabilities to
the client using that mechanism. Whether or not the Tight security type
actually does anything in our
