In the absence of a firewall, the default VNC execution mode is insecure. It encourages transmission of passwords in the clear over the local net. Therefore, the -localhost option should be the default. In the presence of a firewall, either the customer punches an insecure hole for VNC leading to disclosed passwords, or they use ssh tunneling, in which case having the -localhost default suffices. In either case, -localhost should be the default mode of operation. On another note, would RedHat integrate an OpenSSL/StartTLS patch if I could dig one up?
I tend to agree, although it seems to be hard enough already for people to get VNC working what with one thing and another. I certainly think it should be mentioned in the example in /etc/sysconfig/vncservers. Not sure about OpenSSL -- if you file the patch in a separate bug report I'll take a look. It would be great if vino could support secure connections out of the box: I think that's probably what most new users use first.
Pardon a silly question, but just in case... I do not *recall* any command line option to vncserver that would be equivalent to -remotehost. If -localhost becomes the default, then we may need to add a new option to allow remote connections to be enabled. And if we do *that*, we need a global configuration file option to prohibit its use. No urgency, and I think this can wait to see if there is pushback, but I wanted to have it in the record...
As I hinted in comment #1 (but perhaps did not make explicit), we will add the '-localhost' option to the example in the sysconfig file, but the default behaviour of Xvnc will be unchanged.
I understand why this is the right fix from your perspective, but can you tell me if there is a way to push the RFE upstream? Does RealVNC have a method for accepting bug requests?
The best thing to do is send email to the vnc-list mailing list I think.