TurboVNC Changelog

What's new in TurboVNC 3.1.1

Jan 28, 2024
  • Significant changes relative to 3.1:
  • By default, each instance of the Linux TurboVNC Server now listens on the abstract Unix domain socket, in addition to the pathname Unix domain socket (under /tmp/.X11-unix), associated with its X display number. This prevents recent versions of GDM, when configured with WaylandEnable=false, from attempting to use Display :1 for the local session if a TurboVNC session is already using Display :1. The previous behavior can be restored by passing -nolisten local to vncserver or adding -nolisten local to the $serverArgs variable in turbovncserver.conf.
  • The vncserver script now checks whether the abstract Unix domain socket associated with an X display number is in use before assuming that the display number is available.
  • Fixed an issue in the Windows TurboVNC Viewer whereby an F10 key press, followed by an F10 key release, caused the keyboard focus to be redirected to the system menu, and subsequent keystrokes were consumed by the system menu until F10, left Alt, or Esc was pressed to dismiss the menu.
  • Fixed an issue whereby GTK applications (including the GNOME window manager) running in a TurboVNC session attempted to display to a local Wayland session if one was active.

New in TurboVNC 3.1 (Dec 2, 2023)

  • Fixed a regression introduced in 3.1 beta1[3] whereby the SSH username was ignored if it was specified in the Server parameter or if it was specified in the TurboVNC Viewer Options dialog without also specifying the gateway host.
  • Fixed an issue whereby the SSH username was not saved and restored if it was specified in the TurboVNC Viewer Options dialog without also specifying the gateway host.
  • Fixed an issue whereby the SSH username was ignored if it was specified in the Server or Via parameter in ~/.vnc/default.turbovnc.
  • Added a new parameter (SSHUser) that can optionally be used to specify the SSH username. This parameter is set automatically from an SSH username specified in the Server or Via parameter, or it can be set manually.
  • To better emulate the behavior of OpenSSH, the TurboVNC Viewer's built-in SSH client now allows an SSH username specified on the command line or in a connection info file to override an SSH username specified in the OpenSSH config file.
  • The LocalUsernameLC parameter now affects the SSH username if the SSH username is unspecified.

New in TurboVNC 3.1 Beta 2 (Aug 20, 2023)

  • Fixed an issue in the Windows TurboVNC Viewer that prevented certain UTF-8 characters in the clipboard from being transferred properly.

New in TurboVNC 3.1 Beta 1 (Aug 2, 2023)

  • The TurboVNC Server and Viewer now support UTF-8 clipboard transfers.
  • The "Global" tab in the TurboVNC Viewer Options dialog now has a button that can be used to reset all options to their default values.
  • The TurboVNC Viewer now maintains a different set of options for each unique TurboVNC host.
  • The TurboVNC Server and Viewer now implement the QEMU Extended Key Event, QEMU LED State, and VMware LED State RFB extensions, which allow raw keyboard scancodes to be transmitted to the VNC server instead of X11 keysyms. Effectively, this means that the mapping of keycodes into keysyms is performed on the host rather than the client, which eliminates various system-specific and locale-specific key mapping issues (including issues with dead keys on international keyboards.) This feature also fixes lock key synchronization issues when using the TurboVNC Viewer with VMware's VNC server.
  • If the NoReconnect parameter is unset (which it is by default), the TurboVNC Viewer will now offer to reconnect if the initial connection or authentication fails.
  • The TurboVNC Server can now listen on a Unix domain socket, rather than a TCP port, for connections from VNC viewers. This is useful in conjunction with SSH tunneling, and it also allows the Unix domain socket permissions to act as an authentication mechanism for a TurboVNC session. Two new Xvnc arguments, -rfbunixpath and -rfbunixmode, can be used to specify the Unix domain socket path and, optionally, the permissions. A new vncserver argument, -uds, causes the script to automatically choose an appropriate Unix domain socket path under the TurboVNC user directory. See the Xvnc and vncserver man pages for more details.
  • The TurboVNC Viewer can now connect to a VNC server that is listening on a Unix domain socket. This is accomplished by specifying {host}::{uds_path} as the VNC server, where {host} is the hostname or IP address of the VNC host and {uds_path} is the path to the Unix domain socket on the host. If {host} is not localhost, then SSH tunneling with an external SSH client is implied. Refer to the TurboVNC Viewer's usage screen (specifically, the documentation of the Server parameter) and the TurboVNC User's Guide for more details.
  • The TurboVNC Viewer now asks for confirmation before overwriting an existing screenshot file.
  • The TurboVNC Viewer now supports a new TurboVNC-specific connection info file format. TurboVNC connection info files have an extension of .turbovnc, and each line of these files contains a TurboVNC Viewer parameter name and value separated by an equals sign (=).
  • The default values of all TurboVNC Viewer parameters can now be modified by specifying the values in ~/.vnc/default.turbovnc using the connection info file syntax described above.

New in TurboVNC 3.0.3 (Feb 28, 2023)

  • Significant changes relative to 3.0.2:
  • Fixed an issue in the Windows TurboVNC Viewer whereby a left Alt key press, followed by a left Alt key release, caused the keyboard focus to be redirected to the system menu, and subsequent keystrokes were consumed by the system menu until left Alt or Esc was pressed to dismiss the menu.
  • Fixed an issue whereby Rosetta was required in order to install the TurboVNC package for Macs with Apple silicon CPUs.
  • Fixed a regression introduced by 2.2 beta1[7] that prevented the idle timeout feature in the TurboVNC Server from working properly.
  • The Mac TurboVNC Viewer app now informs macOS that it supports HiDPI monitors. This improves the sharpness of the remote desktop and TurboVNC Viewer GUI when using a Retina display.
  • Fixed a regression introduced by 3.0 beta1[24] that caused the TurboVNC Server to become unresponsive if the network connection dropped and a VNC viewer disconnected before the network connection was restored.
  • The vncserver script no longer passes -rfbwait 120000 to Xvnc. Effectively, that hard-coded the TurboVNC Server's send/receive timeout to 120 seconds, which doesn't make sense for most modern systems and networks. (The default value if -rfbwait is not passed to Xvnc is 20 seconds, which makes more sense.) The previous behavior can be restored by adding -rfbwait 120000 to the $serverArgs variable in turbovncserver.conf.
  • Fixed an issue in the TurboVNC Viewer that sometimes caused the Java process to crash when closing the viewer window, particularly if multiple connections were open.
  • Fixed a regression introduced by 3.0.1[3] whereby the TurboVNC Viewer's built-in SSH client tried the ssh-rsa, rsa-sha2-256, and rsa-sha2-512 signature schemes in sequence for every RSA private key stored in the SSH agent, even if the SSH server did not support one or more of those signature schemes. This caused the SSH client to prematurely exceed the SSH server's maximum number of authentication attempts.
  • Fixed an issue in the TurboVNC Viewer's built-in SSH client whereby SSH private keys specified using the SSHKey and SSHKeyFile parameters or the IdentityFile OpenSSH config file keyword were added to the SSH agent's persistent keychain. The SSH client now maintains its own temporary keychain rather than modifying the agent's keychain.
  • To better emulate the behavior of OpenSSH, the TurboVNC Viewer's built-in SSH client has been improved in the following ways:
  • If the SSH agent already has a copy of an SSH private key that was specified using the SSHKey or SSHKeyFile parameter or the IdentityFile OpenSSH config file keyword, then the SSH client now promotes the agent's copy of the key to the head of the SSH client's keychain rather than adding a duplicate key to the end of the keychain. If the SSH agent does not have a copy of the specified SSH private key, then the SSH client now adds the new key to the head of its keychain if a valid passphrase for the key was specified or to the end of its keychain if a valid passphrase for the key was not specified.
  • The TurboVNC Viewer now treats ~/.ssh/id_ecdsa as a default private key. Each of the default private keys ~/.ssh/id_rsa, ~/.ssh/id_dsa, and ~/.ssh/id_ecdsa, in that order, will be added to the SSH client's keychain using the rules described above if the file exists and the SSHKey and SSHKeyFile parameters are not specified.
  • +, ^, and - can now be used at the beginning of the PubkeyAcceptedAlgorithms OpenSSH config file keyword to specify a set of algorithms that should be appended to, prepended to, or removed from the default list.
  • Fixed a regression introduced by 2.2.1[5] that caused the PreferredAuthentications OpenSSH config file keyword to be ignored.

New in TurboVNC 3.0.2 (Nov 29, 2022)

  • Significant changes relative to 3.0.1:
  • The Linux/Un*x TurboVNC Viewer now works around an issue whereby Java on Un*x platforms generates a key release event without a corresponding key press event for dead keys on international keyboards.
  • The TurboVNC Viewer no longer pops up the F8 menu if a modifier key (Shift, Ctrl, Alt, etc.) is pressed along with the menu key.
  • Hotkeys in the Windows TurboVNC Viewer can no longer be triggered using the RCtrl-LAlt-Shift modifier sequence, because Windows uses RCtrl-LAlt to represent AltGr on international keyboards.
  • The vncserver script now searches /usr/local/share/fonts for X11 fonts, which fixes an issue whereby the TurboVNC X server had few available fonts when running on recent FreeBSD releases.
  • The Windows TurboVNC Viewer no longer overrides Java's default choice of high DPI scaling algorithms (nearest-neighbor interpolation) when using integral display scaling factors such as 200%. The viewer now emulates the behavior of Windows, using bilinear interpolation with fractional display scaling factors (per 3.0[6]) and nearest-neighbor interpolation with integral display scaling factors. This improves the sharpness of text when using the Windows TurboVNC Viewer with integral display scaling factors. The turbovnc.scalingalg system property can be set to bicubic, bilinear, or nearestneighbor to override the TurboVNC Viewer's default algorithm choice.
  • The TurboVNC Server now handles multitouch events sent by the UltraVNC Viewer from touchscreen-equipped Windows clients.
  • The Mac TurboVNC Viewer no longer uses Command-V as a hotkey to toggle view-only mode. Mac applications typically use Command-V for pasting from the clipboard. Even though Un*x applications do not typically respond to that key sequence, Mac users sometimes attempt to use Command-V with TurboVNC out of habit, which caused view-only mode to be activated accidentally because of 3.0 beta1[28]. CTRL-ALT-SHIFT-V can still be used to toggle view-only mode.
  • The TurboVNC Viewer normally reserves CTRL-ALT-SHIFT-{arrow keys} as hotkeys to move the horizontal and vertical scrollbars. However, those key sequences are also used by Emacs and GNOME. Thus, the TurboVNC Viewer now sends those key sequences to the server if no scrollbars are visible or if keyboard grabbing is enabled.

New in TurboVNC 3.0.1 (Sep 1, 2022)

  • Significant changes relative to 3.0:
  • Fixed an error ("JRELoadError") that occurred when attempting to use the Mac TurboVNC Viewer app with a custom JRE based on OpenJDK 17.
  • The TurboVNC Viewer's built-in SSH client now supports the OpenSSH v1 private key format. This fixes an "invalid privatekey" error that occurred when attempting to use a private key generated by a recent version of OpenSSH with the TurboVNC Viewer without ssh-agent or Pageant.
  • The TurboVNC Viewer's built-in SSH client now supports the rsa-sha2-256 and rsa-sha2-512 signature schemes (RSA keys with, respectively, the SHA-256 and SHA-512 hash algorithms.) This improves security and compatibility with recent OpenSSH releases. (OpenSSH v8.8 no longer supports the ssh-rsa signature scheme by default, since ssh-rsa uses the now-defeated SHA-1 hash algorithm.) The built-in SSH client now also supports the PubkeyAcceptedAlgorithms keyword in OpenSSH config files, which can be used to disable specific signature schemes that both the client and server support.
  • The TurboVNC Server and Viewer now truncate both incoming and outgoing clipboard updates to the number of bytes specified by the -maxclipboard Xvnc argument or the MaxClipboard TurboVNC Viewer parameter. Previously the server only truncated incoming clipboard updates, and the viewer truncated outgoing clipboard updates while ignoring incoming clipboard updates larger than 256 kB.
  • Fixed an issue in the TurboVNC Viewer whereby specifying a key other than a function key (F1 through F12) using the MenuKey parameter caused "F1" to be selected in the "Menu key" combo box in the TurboVNC Viewer Options dialog.
  • Fixed an error ("Security type not supported") that occurred when attempting to connect to a TurboVNC session using the TurboVNC Session Manager if the "VNC" security type was disabled in the TurboVNC Viewer (by way of the SecurityTypes, SendLocalUserName, or User parameter or a corresponding check box in the TurboVNC Viewer Options dialog) and the SessMgrAuto parameter was enabled.
  • The TurboVNC Viewer now builds and runs on Macs with Apple silicon CPUs.

New in TurboVNC 2.2.6 (Feb 22, 2021)

  • The TurboVNC Server if started with the -nevershared argument now rejects new connections more gracefully by sending an RFB authentication failure message to the potential viewer to notify it of the reason behind the rejection.
  • Fixed an issue in the Java TurboVNC Viewer's built-in SSH client whereby the IdentityFile keyword in the OpenSSH config file was ignored if either ~/.ssh/id_dsa or ~/.ssh/id_rsa existed.
  • Fixed an issue with the TurboVNC Mac package whereby TurboVNC Viewer.app would not be installed into /Applications/TurboVNC if another app by the same name already existed elsewhere on the startup disk.
  • The PAM User/Password authentication method in the TurboVNC Server (which is used with the Unix Login and VeNCrypt *Plain security types) will no longer succeed if a user's account or password is expired.
  • Disabled multithreaded Tight encoding on FreeBSD and similar systems because the feature segfaults for unknown reasons.
  • Fixed an error ("Server TLS ERROR: Could not load libssl") that occurred when attempting to use TLS encryption with the TurboVNC Server (built with TVNC_DLOPENSSL=1 which is the default) running on FreeBSD 12.x.
  • Added two Xvnc command-line options (-maxauthfails and -authfailtimeout) that can be used to specify the maximum number of consecutive VNC password or OTP authentication failures allowed (0 = no limit) before connections to a TurboVNC session are temporarily blocked as well as the initial length of time for which those connections are blocked. (This timeout period automatically doubles with each subsequent consecutive VNC password or OTP authentication failure.)
  • The vncserver script now invokes /usr/bin/env perl rather than /usr/bin/perl for compatibility with FreeBSD and other operating systems that install Perl into a directory other than /usr/bin.
  • Fixed an issue in the TurboVNC Viewer whereby with certain client-side keyboard layouts (Spanish for instance) an XK_KP_Separator (0xFFAC) key symbol was erroneously transmitted to the VNC server when the numeric keypad decimal key was pressed or released even though the corresponding keyboard layout on a Un*x system would have generated an XK_KP_Decimal (0xFFAE) key symbol for the same key.
  • Fixed an issue in the Linux/Un*x TurboVNC Viewer whereby if the current keyboard layout generated an XK_KP_Separator (0xFFAC) key symbol for the numeric keypad decimal key an XK_comma (0x002C) key symbol was erroneously transmitted to the VNC server instead.
  • If interframe comparison is enabled the automatic lossless refresh (ALR) feature in the TurboVNC Server now ignores redundant framebuffer updates (framebuffer updates whose contents are completely eliminated by interframe comparison.) This prevents ALR from being defeated by ill-behaved applications that continuously render the same image.
  • Fixed an issue in the TurboVNC Server whereby when connecting over a high-latency or low-bandwidth network with the TurboVNC Viewer or another VNC viewer that supports the RFB flow control extensions the automatic lossless refresh (ALR) feature sometimes failed to send an ALR.
  • To prevent performance degradation on high-latency networks while using the automatic lossless refresh (ALR) feature the TurboVNC Server now temporarily increases the ALR timeout to ensure that the timeout is always greater than the network round-trip time measured by the RFB flow control extensions.
  • The vncserver script now checks for the swrast DRI driver under /usr/lib/aarch64-linux-gnu /usr/lib/arm-linux-gnueabihf and /usr/lib/arm-linux-gnueabi the system library paths used by Debian-based Arm Linux distributions. This fixes an issue whereby the TurboVNC Server's built-in software OpenGL implementation failed to initialize on such systems which prevented compositing window managers such as GNOME 3 from launching.

New in TurboVNC 2.2.5 (May 15, 2020)

  • The value of the MenuKey parameter in the Java TurboVNC Viewer is now case-insensitive.
  • Fixed several issues in the Java TurboVNC Viewer that prevented the configuration hierarchy (Options dialog > command line > previous settings) from being honored for certain parameters in some cases (particularly when using listen mode or making multiple connections from the same viewer instance.)
  • Fixed an issue in the Java TurboVNC Viewer's built-in SSH client whereby the SSH host key for a given TurboVNC host was not added to the list of known hosts unless the SSH known hosts file (~/.ssh/known_hosts) already existed.
  • Introduced a new Java system property (turbovnc.sshbannerdlg) that, when set to 0, causes the Java TurboVNC Viewer's built-in SSH client to display the SSH server's banner message on the command line rather than in a dialog box.
  • Fixed an issue in the Java TurboVNC Viewer whereby, in listen mode, the full-screen mode setting did not take effect if it was changed in the Default Options dialog.
  • The external SSH feature in the Java TurboVNC Viewer now redirects input and output from the SSH subprocess to the console that launched the viewer. In addition to allowing external SSH issues to be diagnosed more easily, this also allows interactive SSH authentication methods to be used on Windows. Furthermore, the Java TurboVNC Viewer now throws an error if the SSH subprocess fails to launch for any reason.
  • Fixed visual artifacts that occurred when using Hextile encoding in the Java TurboVNC Viewer with OpenGL Java 2D blitting enabled (which is the default on Mac platforms.)
  • Fixed an issue in the Windows TurboVNC Viewer whereby, in listen mode, the /jpeg, /nojpeg, and /quality command-line arguments did not take effect.
  • The TurboVNC Viewer Options dialog can now be used to allow or disallow Alt-Enter as an alternate hotkey for toggling full-screen mode.
  • Fixed an issue in the Windows TurboVNC Viewer whereby, if keyboard grabbing was enabled, using the Windows-L key sequence to lock the computer caused the Windows key (or its Un*x equivalent, the left Super key) to become stuck in the pressed state on the server. Fixed a similar issue in the Windows and Windows/Java TurboVNC Viewers whereby, if keyboard grabbing was enabled, using the Ctrl-Windows-Left or Ctrl-Windows-Right key sequence to switch virtual desktops caused the Windows key to become stuck in the pressed state on the client.
  • Fixed an issue in the Windows/Java TurboVNC Viewer whereby, if keyboard grabbing was enabled, using Alt-Tab to select another window in the TurboVNC session sometimes caused the Tab key to become stuck in the pressed state on the server.
  • Fixed multiple issues with the handling of X.509 certificates in the Java TurboVNC Viewer:
  • Fixed an issue whereby the viewer would not save an untrusted certificate if a different certificate with the same Distinguished Name (DN) had already been saved.
  • The viewer now throws an error if a certificate is not yet valid (i.e. if the start of its validity period is in the future), regardless of whether the certificate is trusted.
  • The viewer now asks for confirmation from the user before accepting an expired certificate, regardless of whether the certificate is trusted.
  • Fixed an issue whereby the viewer would not save an untrusted certificate if the saved certificates file already existed.
  • The viewer no longer displays a confirmation dialog if hostname verification fails for a saved certificate.
  • Fixed an issue in the Java TurboVNC Viewer whereby None and VNC were effectively removed from the security types list after clicking "OK" in the TurboVNC Viewer Options dialog, if one of those security types had been specified in the SecurityTypes parameter along with one of the TLS* or X509* security types.
  • The RPM and DEB packages generated by the TurboVNC build/packaging system now include a PolicyKit Local Authority (.pkla) file that prevents various authentication dialogs ("Authentication is required to create a color managed device", "Authentication is required to access the PC/SC daemon", "Authentication is required to refresh the system repositories") from popping up when using the GNOME 3 window manager with the TurboVNC Server on various Linux distributions.
  • Fixed an issue in the Windows TurboVNC Viewer whereby keyboard grabbing was always initially disabled in the second and subsequent connections initiated by the viewer, regardless of the grab mode.

New in TurboVNC 2.0.91 (Mar 22, 2016)

  • Fixed an issue in the Java TurboVNC Viewer whereby, when built against libjpeg-turbo 1.5 or later, it would generate the following error: Class not found: org/libjpegturbo/turbojpeg/TJException at run time and subsequently fail to accelerate JPEG decompression. TJException is a new class in libjpeg-turbo 1.5, and due to an oversight, VncViewer.jar was not including it.