TightVNC feature has been renamed to TigerVNC

[Adam Tkac]

On Wed, Mar 04, 2009 at 12:10:13PM +0000, Daniel P. Berrange wrote:
> On Wed, Mar 04, 2009 at 03:36:04AM -0500, Adam Tkac wrote:
> > Hi all,
> > 
> > it was some concern why TightVNC feature has been renamed to TigerVNC
> > one minute before beta freeze. Let me try explain background.
> > 
> > In Fedora 10 we have vnc based on RealVNC source but upstream doesn't
> > put any effort to accept patches which we have so I decided replace
> > RealVNC by TightVNC in F11.
> > 
> > Current TightVNC "trunk", which was supposed to be our F11 vnc, uses
> > same codebase as RealVNC. TightVNC adds Tight extension and some other
> > useful features. I joined to TightVNC upstream about one year ago and
> > successfully ported all Fedora changes to upstream.
> > 
> > Unfortunately TightVNC lead developer wasn't able to create any plan
> > for the next release of UN*X version. All UN*X developers asked him
> > what features will be in next version, when the next version will be
> > released etc. It was continual development without any milestones
> > which was unacceptable for some developers thus we created fork called
> > TigerVNC.
> > 
> > TigerVNC is new project, it exists about two weeks. All active
> > TightVNC UN*X developers left TightVNC and joined TigerVNC. Also lead
> > developer of TurboVNC (VNC which is focussed on performance, 3D gaming
> > etc) joined us so I think this project will have better future than
> > TightVNC. You can read "official" statement from upstream -
> > https://sourceforge.net/mailarchive/message.php?msg_name=alpine.LFD.2.00.0902271116020.25749%40maggie.lkpg.cendio.se.
> > 
> > Due reasons written above I decided to switch to TigerVNC ASAP because
> > I think it will be better than TightVNC.
> > 
> > I hope I threw enough light on this topic.
> 
> Thanks for the update - it is good to see that there's now a viable
> open source project for improving VNC server support on UNIX.
> 
> Do you have any plans to implement the VeNCrypt extension in the 
> server side ? This is the TLS/SSL + x509 certificate extension we
> have standardized on for QEMU, Xen, KVM and GTK-VNC (used by 
> virt-viewer, virt-manager and vinagre clients). I would also like
> to add it to the GNOME VINO, since VINO's own TLS extension is flawed
> by not using x509 credentials. That leaves TigerVNC without a good
> interoperable TLS extension, so it'd be desriable to implement VeNCrypt
> there so we have a consistent TLS extension that's interoperable
> across all the VNC clients & servers in Fedora.

Yes, we are interested in VeNCrypt extension and we think that this
is the best approach for encrypted sessions. There are some patches
based on gnutls so we can probably use them. Main reason why they are
still not in upstream is that we would like to use libnss instead of
gnutls. But we will use gnutls based patches before libnss based
support will be ready.

Btw could you point me if there is any documentation of VeNCrypt
instead of source code, please? ;)

> Following on from that I also recently defined & implemented another
> VNC auth extension based on SASL. This provides for a good extendable
> authentication capability, most importantly including GSSAPI Kerberos
> for single sign on. I've got it implemented for QEMU, KVM, GTK-VNC and
> VINO already, so again it'd be good to plan for adding it to TigerVNC
> too so we have a widely interoperable strong authentication system.

I know about SASL authentication (I'm subscribed to vnc-list ;)).
But we haven't discussed it, yet.

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.