Skip to content

2.0.1
Compare
Choose a tag to compare
@dcommander dcommander released this 26 Oct 23:50
· 1377 commits to main since this release
2.0.1
148edb2

Assets

  • turbovnc-2.0.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 1.4.2.

Support

Code Quality: Stable
Current Support Category: EOL

Documentation

User’s Guide for TurboVNC 2.0.1

Release Notes

Significant changes relative to 2.0:

  1. When using an external SSH client with the Via or Tunnel parameters, the Java TurboVNC Viewer was not passing the SSH username to the external SSH client, which caused SSH authentication to fail unless the remote and local usernames were the same. This has been fixed.

  2. Fixed an issue whereby the TurboVNC X server was erroneously generating X11 MotionNotify events every time a mouse button was pressed or released, regardless of whether the pointer had actually moved. This caused problems with certain applications (for instance, in GNOME Terminal, text was selected when single-clicking on it rather than double-clicking or click-dragging on it.)

  3. The /desktopsize server option now works properly with the Windows TurboVNC Viewer.

  4. Fixed an issue that prevented VeNCrypt authentication from working in the Java TurboVNC Viewer when connecting to a server that supports both the TightVNC and VeNCrypt security extensions.

  5. Improved the GUI for specifying the X.509 CA certificate and CRL in the Java viewer, and added new command-line/applet parameters (X509CA and X509CRL) that can be used to specify these files without using the GUI.

  6. The Java viewer will now report an error if one of the security types specified in the SecurityTypes parameter is invalid. This prevents hard-to-diagnose issues (such as authentication errors or the wrong security type being selected) if one of the security types is misspelled.

  7. The TightVNC/TurboVNC-specific "Unix Login" authentication scheme can now be enabled/disabled by using the Java TurboVNC Viewer's SecurityTypes parameter, similarly to other authentication schemes and VeNCrypt security types. Furthermore, the NoUnixLogin parameter now disables the VeNCrypt *Plain security types as well as the Unix Login security type, and the User and SendLocalUserName parameters now disable any of the VeNCrypt security types that don't require a username.

  8. The Java TurboVNC Viewer now supports (and prefers) elliptic curve ciphers when using the Anonymous TLS security types. Additionally, the Java TurboVNC Viewer now uses TLS v1.1+ by default instead of TLS v1.0.

  9. Improvements to the handling of X.509 certificates in the Java TurboVNC Viewer:

    • Fixed a NullPointerException that would occur when attempting to use one of the X.509 security types without specifying an X.509 certificate authority (CA) certificate.
    • If the server's certificate is signed by an unknown CA, then the viewer will pop up a dialog that gives the user the option to trust the certificate for future connections.
    • The viewer can now handle X.509 certificate files containing multiple concatenated certificates.
    • The viewer now performs hostname verification using either the X.509 v3 subjectAltName (SAN) extension or, if SAN is not present, the subject CN field.

  10. When entering full-screen mode or using the "Default Window Size/Position" feature in the TurboVNC Viewer (both Java and Windows), the viewer will now use the monitor containing the largest number of pixels from the viewer window as the "primary" monitor, for the purposes of spanning. Thus, if the viewer window is mostly contained on a monitor other than the left/top one, entering full-screen mode or setting the window to the default size/position will no longer cause the window to jump to the left/top monitor.

    OS X Yosemite introduced an optional feature (enabled by default) called "Spaces", whereby each monitor occupies its own independent space when in full-screen mode (thus allowing full-screen mode to be enabled independently on each monitor.) Previously, when this feature was enabled, moving the TurboVNC Viewer window to a monitor other than the left/top one and entering full-screen mode would result in a black screen. This bug fix allows Primary spanning to work properly with Spaces, but note that no other spanning mode will work properly unless the Spaces feature is disabled.

    Both viewers contain a new command-line option/parameter (-firstmonitorisprimary for the Windows viewer, CurrentMonitorIsPrimary=0 for the Java viewer) that allows the previous behavior (always treating the left/top monitor as the primary) to be restored.

  11. The Java TurboVNC Viewer now supports the BGR555 pixel format, which is reported to be necessary when connecting to some embedded devices.

  12. The Java TurboVNC Viewer now encodes the clipboard as ISO-8859-1 when sending it to the server, instead of UTF-8. The RFB spec requires that the clipboard be encoded as ISO-8859-1, so it is possible that attempting to encode it as UTF-8 was causing problems with certain applications.

  13. The TurboVNC Server now allows the maximum clipboard transfer size to be specified, by way of a new Xvnc argument (-maxclipboard). Previously the limit was hard-coded to 1 MB. Furthermore, the TurboVNC Server now truncates clipboard updates larger than the max. clipboard size instead of ignoring them.

  14. The Java TurboVNC Viewer now allows the maximum clipboard transfer size to be specified, by way of a new parameter (MaxClipboard). The Java TurboVNC Viewer now also truncates any clipboard transfers greater than MaxClipboard (which is set to 1 MB by default.) This prevents the viewer from sending clipboard data to the server that will ultimately be discarded.

Assets 15
Loading