2.2.8 ESR

Extended Support release for project sponsors

Official binaries, source tarball, and change log are available at:
https://github.com/TurboVNC/turbovnc.esr/releases/tag/2.2.8-esr

2.2.90 (3.0 beta1)

Assets

• turbovnc-2.2.90.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 2.1.2 and and Adoptium OpenJDK 11.0.13+8.

Support

Code Quality: Beta
Current Support Category: EOL

Documentation

User’s Guide for TurboVNC 3.0 (Beta)

Release Notes

Significant changes relative to 2.2.7:

1. A custom JRE, based on OpenJDK and containing only the modules that the TurboVNC Viewer needs, can now optionally be included in 32-bit Windows and 64-bit Linux, Mac, and Windows TurboVNC installations and packages by setting the TVNC_INCLUDEJRE CMake variable to 1. When including a custom JRE, OpenJDK 11 or later must be used.

   Since it is now possible to package the Windows/Java TurboVNC Viewer in such a way that it does not require a separate installation of Java, the native Windows TurboVNC Viewer has been retired and replaced with the Java TurboVNC Viewer, which means that the Java TurboVNC Viewer is now the only TurboVNC Viewer. The native Windows viewer will continue to be maintained in TurboVNC 2.2.x on a break/fix basis only. The native Windows viewer, owing to its use of raw Win32 GUI code rather than a modern GUI framework, has become difficult to maintain and even more difficult to extend. Meanwhile, the Java viewer provides similar levels of performance and more features, including some features (TLS encryption and SSH tunneling, most notably) that would have been difficult to implement in the native viewer.

   Retiring the Windows TurboVNC Viewer has resulted in the following (hopefully temporary) feature regressions for Windows clients, relative to TurboVNC 2.2.x:

   • The ability to set different viewer options for each VNC server
   • The ability to save connection info files
   • 3-button mouse emulation
   • Bump scrolling in full-screen mode
   • Wacom tablet support (although the Windows TurboVNC Viewer, owing to its use of the Wintab API, only supported older Wacom tablets)

2. Added a screenshot feature to the TurboVNC Viewer that allows an image of the remote desktop to be saved to the client machine.

3. Added a window tiling feature to the TurboVNC Viewer that automatically arranges all viewer windows in a grid pattern when a hotkey is pressed or an option is selected in the F8 or Mac menu.

4. The TurboVNC Viewer can now automatically connect to multiple VNC servers, applying a different set of options for each. This is accomplished by separating the command-line arguments for each VNC server with --.

5. The TurboVNC Viewer now includes the TurboVNC Session Manager, which allows users to remotely manage multiple TurboVNC sessions running on a particular TurboVNC host. If no display number or port is specified in the "VNC server" field, the TurboVNC Viewer will connect to the specified TurboVNC host using SSH, list all TurboVNC sessions running under the user's account, and display a dialog that allows the user to choose a session to which to connect, kill any of the sessions, generate a new OTP for any of the sessions, or start a new session. Previously, the TurboVNC Viewer defaulted to Display :0/Port 5900 when no display number or port was specified, but it is now necessary to specify :0 or ::5900 in order to connect to Display :0/Port 5900. The TurboVNC Session Manager uses the TurboVNC Viewer's built-in SSH client (it cannot use an external SSH client because of the need to leave the SSH session open and reuse it to run multiple commands), so it is affected by the SSHConfig, SSHKey, SSHKeyFile, SSHKeyPass, and SSHPort parameters.

6. The zero-install Java Web Start feature and built-in HTTP server in the TurboVNC Server have been removed, along with the corresponding vncserver command-line option (-nohttpd), Xvnc command-line options (-httpd and -httpport), security configuration file directive (no-httpd), and turbovncserver.conf variables ($enableHTTP and $vncClasses.) This reflects the fact that Java Web Start is now a legacy technology. JWS is no longer provided in Java 11 and later, so once Java 8 stops receiving public updates, the ability to deploy the TurboVNC Viewer using JWS will be limited. These features will continue to be supported in TurboVNC 2.2.x on a break/fix basis.

7. MinGW can now be used instead of Visual C++ when building the TurboVNC Viewer (more specifically, the TurboVNC Helper library) for Windows.

8. The TurboVNC Viewer authentication dialog will now indicate whether the connection is encrypted, unencrypted, or redundantly encrypted.

9. The vncserver script can now optionally start a simple web server that serves up noVNC (an HTML 5/JavaScript VNC viewer) along with each TurboVNC session, using a new command-line option (-novnc) or turbovncserver.conf variable ($noVNC) to specify the noVNC installation directory. The vncserver script also creates a unique PID file for the noVNC web server process and kills that process when the TurboVNC session is killed.

10. The vncserver script now enables the -autokill option by default, which creates a more intuitive interface for new TurboVNC users. A new command-line option (-noautokill), or the existing $autokill turbovncserver.conf variable, can be used to disable the feature.

11. The TurboVNC Viewer's built-in SSH client can now read SSH private keys from ssh-agent or Pageant. Note that the SSH client does not understand the IdentitiesOnly keyword in OpenSSH config files and behaves as if IdentitiesOnly is yes. Otherwise, with the exception noted in 2.2.1[5], its behavior should be the same as that of OpenSSH.

12. The X startup script (which is used to launch a window manager or other applications in a TurboVNC session) can now be specified using two new turbovncserver.conf variables, $xstartup and $noxstartup, which are the equivalents of the vncserver -xstartup and -noxstartup command-line options.

13. The TurboVNC Server now installs the default xstartup.turbovnc script into the same directory as vncserver, and vncserver always uses that default script rather than a per-user xstartup.turbovnc script. This facilitates upgrading xstartup.turbovnc on a system-wide basis when the TurboVNC Server is upgraded. A per-user X startup script can still be used by specifying it with the -xstartup command-line option or the $xstartup turbovncserver.conf variable.

14. The default X startup script (xstartup.turbovnc) has been streamlined to improve cross-platform compatibility. The script now attempts to match the value of the TVNC_WM environment variable, which is set by the vncserver -wm command-line option or the $wm turbovncserver.conf variable, with a session desktop file under /usr/share/xsessions (or /usr/local/share/xsessions on *BSD systems.) If a matching session desktop file exists, then xstartup.turbovnc populates the appropriate XDG environment variables from the entries in that file and then executes the window manager startup program/script specified in the file.

15. The $autoLosslessRefresh, $pamSession, $multiThread, and $numThreads turbovncserver.conf variables are now deprecated, since $serverArgs can be used to accomplish the same thing.

16. The TurboVNC Server can no longer be built using GnuTLS. Supporting GnuTLS was a stopgap measure intended for power users who needed access to encryption features that, at the time, either OpenSSL or TurboVNC's OpenSSL wrapper did not provide. However, that feature gap has since been closed, and given the fact that TurboVNC's OpenSSL wrapper has better performance and receives more attention from the TurboVNC developers and user community, there is no compelling reason to use the GnuTLS wrapper anymore. The 2.2.x version of the TurboVNC Server will continue to support GnuTLS on a break/fix basis.

17. The TurboVNC Server is now based on xorg-server 1.20.13, which fixes several minor X server bugs.

18. The TurboVNC Server's built-in unaccelerated GLX/OpenGL implementation no longer supports indirect rendering. Indirect rendering is limited to the OpenGL 1.4 API, and it performed sluggishly in the TurboVNC Server due to the fact that X servers are single-threaded. (On some platforms, the TurboVNC Server would become unresponsive for seconds at a time when users interacted with 3D applications that used indirect rendering.) Indirect rendering was generally only necessary on older systems that lacked libglvnd and that had vendor-specific GPU drivers installed, but it has always been possible to use direct rendering on such systems-- either by using VirtualGL or by manipulating LD_LIBRARY_PATH or LD_PRELOAD to cause OpenGL applications to use the Mesa implementation of libGL rather than the vendor-specific implementation. Indirect rendering-- and the TurboVNC-specific X server modifications that allowed it to perform as well as possible-- will continue to be supported in TurboVNC 2.2.x on a break/fix basis.

19. The TurboVNC Viewer's built-in SSH client now displays the SSH server's banner message on the command line by default. Set the turbovnc.sshbannerdlg Java system property to 1 to display the banner message in a dialog box instead, thus restoring the default behavior of TurboVNC 2.2.x.

20. The TurboVNC Se...

2.2.7

Assets

• turbovnc-2.2.7.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 2.0.6.

Support

Code Quality: Stable
Current Support Category: Extended

Documentation

User’s Guide for TurboVNC 2.2.7

Release Notes

Significant changes relative to 2.2.6:

1. The Java TurboVNC Viewer now temporarily re-enables double buffering in Swing and Java 2D if any TurboVNC Viewer dialog other than the profiling dialog has the keyboard focus. This fixes various minor cosmetic issues with the TurboVNC Viewer Options dialog, particularly on Mac platforms, that occurred if the viewer was actively drawing framebuffer updates while the dialog was visible.

2. Fixed an error ("java.nio.BufferOverflowException") that occurred in the Java TurboVNC Viewer when attempting to use one of the X509* security types with the TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 TLS 1.3 cipher suites, which are preferred by OpenSSL 1.1.x.

3. The built-in HTTP server in the TurboVNC Server now adjusts the value sent in the "Content-Length" HTTP header to accommodate variable substitutions in the JNLP template. This fixes an issue whereby certain web browsers would refuse to download the automatically-generated JNLP file.

4. The built-in HTTP server in the TurboVNC Server now handles HTTP 1.1 HEAD requests, which are sent by recent versions of Java Web Start.

5. vncpasswd, when invoked with no arguments, now creates the ~/.vnc directory if it does not exist. This makes the actual behavior of vncpasswd match its documented behavior.

6. The values of the AlwaysShowConnectionDialog, Colors, and Encoding parameters in the Java TurboVNC Viewer are no longer saved when "OK" is clicked to dismiss the TurboVNC Viewer Options dialog, nor are they restored when the viewer is launched. Because those parameters can only be specified on the command line or in a connection info file, automatically restoring their previous values led to confusing behavior. (That behavior made more sense prior to TurboVNC 2.2, because the Options dialog did not automatically save the current options.) Since TurboVNC 1.2.2, the Windows TurboVNC Viewer has similarly avoided saving/restoring the values of command-line parameters that have no GUI equivalents.

7. Fixed an issue in the Java TurboVNC Viewer whereby, in listen mode, clicking "OK" to dismiss the Default Options dialog caused all security types and SSH options to be disabled in or deleted from the saved defaults. This led to unexpected behavior if a user subsequently attempted to make a forward RFB connection using the viewer.

8. Worked around an issue in Java whereby changing the scaling factor or toggling view-only mode while the Mac TurboVNC Viewer was in full-screen mode sometimes caused the viewer to exit full-screen mode.

9. Fixed an issue in the Mac TurboVNC Viewer whereby, after using Command+Tab to switch to another application while the viewer was in full-screen mode with multi-screen spanning enabled, switching back to the TurboVNC Viewer effectively disabled multi-screen spanning.

10. Fixed an issue in the Linux/Un*x TurboVNC Viewer whereby automatic multi-screen spanning sometimes behaved incorrectly if the remote desktop size or the scaling factor was changed while the viewer was in full-screen mode or transitioning into full-screen mode.

11. Fixed an issue whereby the Java TurboVNC Viewer would throw a NullPointerException if view-only mode was toggled in the TurboVNC Viewer Options dialog, and full-screen mode was not also toggled, prior to connecting to a VNC server.

12. Added a new parameter to the Java/Mac/Un*x TurboVNC Viewer (ConfirmClose) that, when enabled, causes the viewer to prompt for confirmation before closing a connection.

2.2.6

Assets

• turbovnc-2.2.6.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 2.0.6.

Support

Code Quality: Stable
Current Support Category: Extended

Documentation

User’s Guide for TurboVNC 2.2.6

Release Notes

Significant changes relative to 2.2.5:

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

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

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

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

5. Disabled multithreaded Tight encoding on FreeBSD and similar systems, because the feature segfaults for unknown reasons.

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

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

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

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

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

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

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

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

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

2.2.5

Assets

• turbovnc-2.2.5.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 2.0.4.

Support

Code Quality: Stable
Current Support Category: Extended

Documentation

User’s Guide for TurboVNC 2.2.5

Release Notes

Significant changes relative to 2.2.4:

1. The value of the MenuKey parameter in the Java TurboVNC Viewer is now case-insensitive.

2. 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.)

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

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

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

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

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

8. Fixed an issue in the Windows TurboVNC Viewer whereby, in listen mode, the /jpeg, /nojpeg, and /quality command-line arguments did not take effect.

9. The TurboVNC Viewer Options dialog can now be used to allow or disallow Alt-Enter as an alternate hotkey for toggling full-screen mode.

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

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

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

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

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

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

2.2.4

Assets

• turbovnc-2.2.4.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 2.0.4.

Support

Code Quality: Stable
Current Support Category: Extended

Documentation

User’s Guide for TurboVNC 2.2.4

Release Notes

Significant changes relative to 2.2.3:

1. The Windows/Java TurboVNC Viewer now works around an issue whereby the operating system does not send a key release event to applications if one of the Shift keys is released while the other Shift key remains pressed. This issue did not affect the native Windows TurboVNC Viewer, since it does not distinguish between the left and right Shift keys.

2. The TurboVNC Viewer now transmits an XK_KP_Separator (0xFFAC) key symbol rather than an XK_KP_Decimal (0xFFAE) key symbol for the keypad decimal key if the client's locale uses a comma rather than a period for a decimal symbol. This emulates the behavior of Linux.

3. Fixed an error ("JRELoadError") that occurred when attempting to use the Mac TurboVNC Viewer app with Java 13.

4. It is no longer necessary to set the JAVA_HOME environment variable in order to use the Mac TurboVNC Viewer app with Java 11 and later.

5. Fixed an issue whereby, if the physical screens on the client had mismatched resolutions or were offset, the TurboVNC Viewer would not use all of the available screen real estate in full-screen mode with multi-screen spanning enabled. The viewer now properly fills all screens in this case, as long as automatic desktop resizing is enabled and the VNC server supports Xinerama (multiple virtual screens), i.e. if the server's virtual screen layout is being set based on the client's physical screen layout.

6. The Windows TurboVNC Viewer should now build properly with Visual Studio 2015.

7. The TurboVNC Server is now based on xorg-server 1.19.7, which fixes several minor X server bugs.

8. The TurboVNC Server now supports the X Record Extension. This extension can be disabled, if desired, by passing -extension XTEST to vncserver.

2.2.3

Assets

• turbovnc-2.2.3.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 2.0.3.

Support

Code Quality: Stable
Current Support Category: Extended

Documentation

User’s Guide for TurboVNC 2.2.3

Release Notes

Significant changes relative to 2.2.2:

1. The Elliptic Curve Diffie-Hellman (ECDH) key exchange algorithm is now supported by the TurboVNC Server when using OpenSSL 1.0.2 or later.

2. A new security configuration file directive (permitted-cipher-suites) in the TurboVNC Server and a new Java system property (turbovnc.ciphersuites) in the Java TurboVNC Viewer can now be used to specify a list of permitted TLS cipher suites for the TLS* and X509* security types.

3. Fixed an issue in the Mac TurboVNC Viewer whereby drawing tablet stylus buttons were ignored or mapped to incorrect mouse button events.

4. The built-in HTTP server in the TurboVNC Server now accepts : and @ in any TurboVNC Viewer parameters that are appended to the URL. This allows for specifying an SSH username in the Via parameter and an RFB display/port in the Server parameter.

5. The X RandR outputs in the TurboVNC Server have been renamed to "VNC-0", "VNC-1", etc. This prevents a dialog ("Authentication is required to create a color managed device") from popping up when using the GNOME 3 window manager on recent Linux distributions, including Fedora, RHEL 8, and Ubuntu 18 and later.

6. Fixed a packaging regression, introduced by 2.2 beta1[17], that prevented full-screen multi-screen spanning from working properly with the Mac TurboVNC Viewer app.

7. Fixed a regression introduced by 2.2 beta1[11] that caused the TurboVNC Server to leak memory when certain X11 applications or frameworks requested that clipboard updates from the X server be converted to UTF-8 (by calling XConvertSelection() with a target of xaUTF8_STRING.)

8. Fixed an error ("java.lang.IllegalArgumentException: Error in security property. Constraint unknown: ECDH_ DH_RSA") that occurred when attempting to use any of the TLS* security types with the Java TurboVNC Viewer running under Java 7u211, 8u201, 11.0.2, or later with OpenSSL 1.1.x.

9. Fixed an issue (CVE-2019-15683) in the TurboVNC Server whereby a specially-crafted VNC viewer could be used to remotely trigger a stack overflow in the server by sending it a malformed RFB Fence message. This issue could never have been encountered when using any of the VNC viewers that currently support the RFB Fence message (TurboVNC and TigerVNC.) Furthermore, since exploiting the issue would have first required successfully authenticating with a TurboVNC session, the issue did not generally provide an attack vector for anyone other than the session owner and any collaborators authorized by the owner.

10. Fixed various issues with remote mouse events that would occur when running the Linux TurboVNC Viewer in a Wayland session.

11. The TurboVNC Server now generates a 2048-bit DSA key for use with the TLS* security types. This fixed an error ("dh key too small") that occurred when attempting to connect, using one of those security types, to a TurboVNC session running on a RHEL 8 host. It also fixed an error ("javax.net.ssl.SSLHandshakeException: DHPublicKey does not comply to algorithm constraints") that occurred when attempting to connect, using one of the TLS* security types, to a TurboVNC session with the Linux TurboVNC Viewer running on a RHEL 8 client. A new security configuration file directive (tls-key-length) can be used to restore the behavior of previous releases of TurboVNC (generating a 1024-bit DSA key) or to increase the key length for additional security.

2.2.2

Assets

• turbovnc-2.2.2.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 2.0.2.

Support

Code Quality: Stable
Current Support Category: Extended

Documentation

User’s Guide for TurboVNC 2.2.2

Release Notes

Significant changes relative to 2.2.1:

1. Fixed an error ("javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)") that occurred when attempting to use any of the TLS* security types with the Java TurboVNC Viewer running under Java 7u211, 8u201, 11.0.2, or later.

2. Fixed an issue in the Java TurboVNC Viewer's built-in SSH client whereby values for the ServerAliveInterval keyword in the OpenSSH config file were interpreted as milliseconds rather than seconds. This caused the SSH connection to fail if the value specified for ServerAliveInterval was too low.

3. Fixed a regression introduced by 2.2.1[6] that caused constant flickering in the UltraVNC Viewer when it was used with the TurboVNC Server.

4. Fixed an issue in the TurboVNC Server whereby, if interframe comparison was enabled and the remote desktop was resized to a smaller size, the server would sometimes send a framebuffer update that exceeded the new desktop dimensions. This crashed the UltraVNC Viewer.

5. Fixed a denial-of-service (DoS) vulnerability in the TurboVNC Server that was exposed when many RFB connections were made to the server and never dropped, thus exceeding the Xvnc process's allotment of file descriptors. When this occurred, it triggered an infinite loop whereby the TurboVNC Server's listener socket handler returned immediately with an EMFILE ("Too many open files") error, but the handler continued to be called by the X.Org code because the incoming RFB connection never succeeded. This infinite loop prevented the TurboVNC session owner from launching any X11 programs in the session (since those require Unix domain socket connections) until one or more of the RFB connections dropped, and the continuous flood of error messages in the session log caused the log to grow by megabytes per second until all available disk space was exhausted. The TurboVNC Server now sets a reasonable RFB connection limit (which can be adjusted using a new Xvnc argument, -maxconnections) and rejects all new connections once this limit has been reached. The upper limit for -maxconnections should be low enough to avoid the aforementioned EMFILE error and infinite loop.

6. Fixed an issue in the Linux/Un*x TurboVNC Viewer whereby, if multiple buttons on an extended input device (such as a drawing tablet) were pressed or released in rapid succession, some of those button events could accidentally be discarded by the TurboVNC Helper under certain circumstances, leading to a loss of synchronization between the client's and the TurboVNC session's extended input device button state. From the point of view of applications running in the TurboVNC session, the extended input device buttons appeared to stick in the down or up position.

2.2.1

Assets

• turbovnc-2.2.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 2.0.1.

Support

Code Quality: Stable
Current Support Category: Extended

Documentation

User’s Guide for TurboVNC 2.2.1

Release Notes

Significant changes relative to 2.2:

1. The standalone Mac TurboVNC Viewer app will now use the JRE pointed to by the JAVA_HOME environment variable, if that variable is defined. This facilitates using the viewer with Java 11, which doesn't provide a separate JRE and thus doesn't install anything under /Library/Internet Plug-Ins/JavaAppletPlugin.plugin (the directory in which the Mac TurboVNC Viewer app launcher normally looks for a JRE.)

2. The Windows TurboVNC Viewer packages no longer include a custom build of PuTTY. An optimized version of PuTTY 0.60 was originally included in TurboVNC 0.4/Sun Shared Visualization 1.1 because, at the time, the stock version of PuTTY was slow, and installing OpenSSH generally required Cygwin. The custom build of PuTTY was retained in TurboVNC 1.2, because few Windows SSH implementations had proper IPv6 support at the time. However, in 2018, numerous Windows SSH clients will work properly with the TurboVNC Viewer, and generally with better performance than our custom build of PuTTY.

3. Fixed an issue in the vncserver script whereby generating an initial one-time password (OTP) would fail if X11 TCP connections were disabled (which is now the default, because of 2.2 beta1[8]) and the hostname of the TurboVNC host resolved to its external IP address rather than to its local IP address.

4. The Java TurboVNC Viewer will now display all informational messages and warnings from its built-in SSH client whenever the logging level is >= 110.

5. The built-in SSH client in the Java TurboVNC Viewer has been improved in the following ways:

   • The SSH client will now prompt for an SSH key passphrase if one is required but has not been specified using the SSHKeyPass parameter. This emulates the behavior of OpenSSH.
   • The SSH Password dialog will no longer be displayed unless SSH password authentication is necessary. Previously, the dialog was displayed even if the hostname was invalid.
   • Closing the SSH Password dialog will now immediately cancel SSH authentication.
   • The SSH client will now automatically read and process the OpenSSH configuration file stored in ~/.ssh/config (or the location specified in the SSHConfig parameter), if the file exists. Parameters read from the OpenSSH configuration file will take precedence over any TurboVNC Viewer parameters.
   • A new Java system property (turbovnc.sshauth) can be used to enable or disable SSH authentication methods, as well as to specify their preferred order.

6. Fixed a race condition in the TurboVNC Server that, under rare circumstances, caused the TurboVNC Viewer to incorrectly assume that the server did not support remote desktop resizing.

7. Fixed an issue in the vncserver script whereby changing the value of $vncUserDir in turbovncserver.conf did not change the default locations of the VNC password file, the X.509 certificate file, and the X.509 private key file. The script now defers setting the default locations of those files until after turbovncserver.conf is read, and the script now allows the locations of all three files to be specified in turbovncserver.conf.

8. The vncserver script now allows VirtualGL to be enabled using the turbovncserver.conf file.

9. The vncserver script now allows the window manager startup script to be specified using a new command-line option (-wm) or turbovncserver.conf variable ($wm.) This is useful when starting TurboVNC sessions at boot time, and for other situations in which setting the TVNC_WM environment variable is not possible.

10. The TurboVNC Server now properly handles installations in which the system-wide TurboVNC configuration file (turbovncserver.conf) and security configuration file (turbovncserver-security.conf) are located in a directory other than /etc.

11. Introduced a new turbovncserver.conf variable ($serverArgs) that can be used to specify additional arguments for Xvnc. This allows any TurboVNC Server option to be enabled or disabled on a system-wide or per-user basis, even if that option has no corresponding turbovncserver.conf variable.

12. Fixed an issue in the Windows/Java and Un*x TurboVNC Viewers whereby, when pressing and releasing both the left and right locations of a particular modifier key (Shift, Ctrl, Alt, etc.), only one of the key releases was sent to the VNC server. Fixed a similar issue in the Mac TurboVNC Viewer under Java 11 whereby, when pressing and releasing both the left and right Alt keys in the same order, a left Alt key press and an AltGr key release (or vice versa) were sent to the VNC server.

13. Fixed a segfault in the TurboVNC Server that occurred, under rare circumstances, when a viewer disconnected.

14. Fixed an issue in the TurboVNC Server, introduced by 2.2 beta1[11], that prevented client-to-server clipboard transfers from working properly with some Qt applications.

2.2

Assets

• turbovnc-2.2.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 2.0.0.

Support

Code Quality: Stable
Current Support Category: Extended

Documentation

User’s Guide for TurboVNC 2.2

Release Notes

Significant changes relative to 2.2 beta1:

1. The Alt button in the Java/Mac/Un*x TurboVNC Viewer toolbar now works properly. Previously, it was sending an Alt key press and a Ctrl key release.

2. Fixed an issue whereby, when using certain Command-{key} sequences in the Mac TurboVNC Viewer (specifically: Command-`, which switches between the two most recent viewer windows; Command-H, which hides all viewer windows; Command-Q, which exits the viewer; and Command-P, which toggles the profiling dialog), {key} was unintentionally transmitted to the VNC server.

3. Fixed a segfault in the TurboVNC Server that occurred when attempting to disable the Composite extension. This was a regression caused by a bug in the xorg-server 1.19.6 code.

4. The default xstartup.turbovnc script that the TurboVNC Server creates now works around an issue whereby the desktop contents would not be displayed when running the GNOME Classic window manager on RHEL/CentOS 7 or recent Fedora releases.

5. The default xstartup.turbovnc script that the TurboVNC Server creates now launches Unity 2D by default on Ubuntu 12, as was the case with TurboVNC 2.1.x. Unity 3D 5.20.x does not work properly with the TurboVNC X server, and Unity 2D provides a similar user experience.

6. The default xstartup.turbovnc script that the TurboVNC Server creates now properly launches the GNOME 3, GNOME Flashback (Metacity), and MATE window managers on Ubuntu 18.

7. Fixed an issue whereby the TurboVNC Server would fail to launch via the vncserver script (giving the error "Unrecognized option: -x509cert") if the server was built with TVNC_USETLS=OpenSSL or TVNC_USETLS=GnuTLS and the OpenSSL or GnuTLS headers/libraries were not installed.

8. The -list option for the vncserver script no longer lists orphaned TurboVNC sessions (sessions for which a PID file exists in the user's VNC directory but for which the corresponding Xvnc process is no longer running.)

9. Fixed an issue in the Java TurboVNC Viewer whereby, when using SSH tunneling with the built-in SSH client, the SSH connection would remain open even if the associated VNC connection had been closed.

10. Fixed an issue in the vncviewer-javaw.bat script, which is used to launch the Java TurboVNC Viewer on Windows without a console window, whereby jawt.dll would not be found when using certain versions of the Oracle JRE.

11. The Java TurboVNC Viewer now builds successfully with JDK 11.

12. Fixed an issue in the Mac TurboVNC Viewer whereby the "Preferences..." option in the VncViewer menu (and its associated hotkey, Command-,) would pop up a new copy of the Options dialog even if the Options dialog was already visible.

13. Worked around an issue in Java 9 through 11 that caused the Profiling dialog in the Mac TurboVNC Viewer to immediately disappear if it was popped up using the Command-P hotkey.