VNC development plan - discuss

[Daniel P. Berrange]

On Wed, Mar 07, 2007 at 08:38:51AM +0100, Adam Tkac wrote:
> Daniel P. Berrange napsal(a):
> >Since we're on the subject of VNC servers, its a good time to bring up the
> >question of virtualization. With Xen in the mix there are actually 2 
> >further
> >VNC server implementations in Fedora...
> >
> >   - Xen para-virtualized guest console server
> >   - QEMU / KVM / Xen fully-virtualized guest console server
> >
> >The former is currently based on libvncserver which turned out to be an 
> >really bad mistake. The code is horribly complicated / obtuse and has 
> >completely unsafe use of pthreads synchronization primitives. The QEMU VNC
> >server is a from sratch impl of the RFB protocol which is directly part of
> >the QEMU codebase.  It is my intention that the current Xen paravirt VNC
> >server will be re-written to use more-or-less the same code as the current
> >QEMU impl, which will bring it down from ~20,000 lines of C, to ~2,000.
> >Now this isn't directly relevant, since the code isn't really suitable for
> >turning into a standalone VNC server. I just wanted to point out that 
> >you should be wary of picking libvncserver as the basis of a shared RFB
> >impl in its current form, since the codebase isn't all that nice to work 
> >with.
> >  
> 
> Don't tell me about xen's virtual console. I have dreams about nasty 
> mouse tracking 
> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221360) every 

I know, I know  - its awful. In the virt-manager which is in rawhide this
is worked around by doing a pointer grab & hiding the local cursor. Not ideal
but a hell of alot better than current. The root problem is not really VNC's
fault though - we get absolute mouse coords in the local GTK widget, these
are passed over VNC as absolute coords to Xen, then passes them upto the
guest OS as absolute coords, and finally the guest X server translates them
to relative coords and applies mouse acceleration again :-( I've figured out
a Xorg config stting to make it use absolute coords in the guest, so now its
just a case of making X auto-configure this out-of-the-box.

> night. If you're going to do major changes on vnc bits in xen, I'm ready 
> to help you with this development. If you're really looking for good RFB 
> Protocol implementation I think that RealVNC's implementation is best 
> (stable, robust, c++ implementation for server and viewer side). 
> Recently I've created package named vnc-libs (in rawhide) which contains 
> this implementation. You could write me mail if this solution sounds 
> good for you ;)

I'll investigate vnc-libs to see how easy it'd be to use. I've also got to
take in account upstream Xen development though - current thoughts are that
the Xen paravirt VNC server should use same VNC code as the existing QEMU 
server so that Xen folks only have a single impl to maintain. I'll let you
know if I've any Q's

> >The caveat is that AFAIK, Fedora doesn't have any VNC viewer program that
> >supports encryption aside from SSH tunnelling - not a huge problem since 
> >virt-manager has an embedded GTK VNC widget which can do the job, but it
> >would be nice to have a standalone viewer for virtual machine consoles.
> >
> >So if we're thinking of long term Fedora VNC development plans, we should 
> >make sure encryption / authentication is on the list for both client & 
> >server.
> >  
> 
> You're right. Current VNC security model was good in 80s but nowadays is 
> complete unusable. I want make vnc secure but protocol is protocol... 
> (http://www.realvnc.com/docs/rfbproto.pdf). We can't make RedHat's vnc 
> which will have perfect security policies but which is incompatible with 
> other vnc implementations. Btw VeNCrypt looks fine. I could do 
> investigations what could be ported to our vnc to improve security.

Yes, I choose VeNCrypt becasue there is a formal RFB authentication protocol
allocated to it in the VNC spec now. I certainly don't want anything to be
Red Hat specific about it, because this is be targetted for upstream QEMU
and Xen codebases. BTW, I asked the VeNCrypt developers for a spec for their
protocol extension, and here's the info they gave back...

http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00006.html

NB, they're basically tracking RealVNC releases for their implementation. 
The implementation they have though is not as complete as it needs to be,
in particular they've not done any x509 certificate validation on client 
or server yet.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|