3.1

Assets

• turbovnc-3.1.tar.gz is the official source tarball for this release. The automatically generated "Source code" assets are not supported.
• Refer to https://TurboVNC.org/Downloads/DigitalSignatures for information regarding the methods used to sign the files in this release and instructions for verifying the signatures.
• The binary packages were built with libjpeg-turbo 3.0.1 and Adoptium OpenJDK 17.0.9+9 (Adoptium OpenJDK 17.0.9+9.1 used for Windows.)

Support

Code Quality: Stable
Current Support Category: Active

Documentation

User’s Guide for TurboVNC 3.1

Release Notes

Significant changes relative to 3.1 beta2:

1. Improved the TurboVNC Viewer's handling of SSH usernames in the following ways:

   • 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.

2. The TurboVNC Server now includes various security fixes (CVE-2022-2319, CVE-2022-2320, CVE-2022-4283, CVE-2022-46340, CVE-2022-46341, CVE-2022-46342, CVE-2022-46343, CVE-2022-46344, CVE-2023-0494, and CVE-2023-1393) from the xorg-server 21.1.x code base.

3. The TurboVNC Viewer no longer requires that the VNC server support the QEMU LED State or VMware LED State RFB extension in order to use the QEMU Extended Key Event RFB extension. This fixes various key mapping issues when using the TurboVNC Viewer with wayvnc. However, it should be noted that, if the QEMU Extended Key Event extension is used without one of the LED State extensions, the lock key state on the client will lose synchronization with the lock key state on the remote desktop if a lock key is pressed outside of the TurboVNC Viewer window.