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.*?
On Sun, Nov 07, 2010 at 05:50:51PM +0100, Martin Koegler wrote:
>
> Please note, that this does not affect the Tightvnc encoding.
>
> patch 1-7 update the java code to support all VeNCrypt security types:
> * patch 1 adds constants
> * patch 2 implements the chooser
> * patch 3 updates the authen
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 au
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
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 advert
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
