These packages were built with libjpeg-turbo 1.4.2:
http://sourceforge.net/projects/libjpeg-turbo/files/1.4.2/

Packaging changes

A new build of the Linux RPMs and DEBs was uploaded on 2015-11-05, because the original build errantly included the libjpeg-turbo 1.4.1 JNI JAR files instead of the 1.4.2 JNI JAR files.

Package signatures

To ensure the integrity of the TurboVNC binary packages, the RPM and DEB files and the source tarball are signed using the following key:
http://www.TurboVNC.org/key/VGL-GPG-KEY-1024
http://pgp.mit.edu/pks/lookup?op=get&search=0x6BBEFA1972FEB9CE
and the Windows installers are signed using a code signing certificate.

2.0.1

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 user name to the external SSH client, which caused SSH authentication to fail unless the remote and local user names 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 user name.

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.