- The spice-client package has been upgraded to upstream version 0.8.2, which provides a number of bug fixes and enhancements over the previous version, including:
- Various code cleanup modifications, such as removing unused variables, dead code and typos, have been included.
- Several package build changes, such as enabling a silent build and a cleanup in the configure.ac script have been included.
- White spaces in values for the
--host-subjectcommand line option are now ignored.
- A new
--versioncommand line option for the
spiceccommand has been added.
- The libcacard package has been upgraded to upstream version 0.15.0, which provides a number of bug fixes and enhancements over the previous version, including a fix for the following bug:
- Some AET middleware did not work correctly with the
CKM_RSA_X_590encrypting mechanism even though it reported support for this mechanism. Consequently, if such middleware was used by libcacard virtual smart cards, smart cards failed to emulate any RSA authentication based operations, such as requesting a security pin or retrieving user certificates. The library has been modified to handle
CKM_RSA_X590failures by falling back to use
CKM_RSA_PKCSencryption. Virtual smart cards now work correctly with AET middleware.
- Although old SPICE-related packages (such as cairo-spice) are no longer required to be installed with the spice-client package, they were still needed by a previously installed spice-client or spice-server package. With the
Obsoletelines in the package spec file, updating spice-client forced an update of spice-server as well, and vice versa. With this update, all "Obsolete" lines have been removed from the
spice-client.specfile, and updating spice-client no longer forces the update of spice-server.
SPICEclient did not correctly handle monitor setting routines when it was running on a client machine with multiple monitors. As a consequence, the client entered an infinite loop while trying to rearrange monitors, which eventually caused the client to terminate unexpectedly. With this update, the code has been modified to prevent the client from entering this loop, and the client thus no longer crashes.
SPICEclient failed to connect to the SPICE server on the target host after a virtual machine had been migrated to a remote machine. This happened when the migration of the virtual machine took longer than the expiration time of the SPICE ticket that was set on the target host. Without a valid password, the SPICE server refused connection from the SPICE client and the SPICE session had to be closed. To prevent this problem, support for spice semi-seamless migration has been added. Other components such as spice-protocol, spice-server and qemu-kvm have also been modified to support this feature. SPICE now allows the SPICE client to connect to the SPICE server on the target host at the very start of the virtual machine migration, just before the migrate monitor command is given to the qemu-kvm application. With a valid ticket on the target host, the SPICE ticket on the destination no longer expires and the SPICE client now remains open when the virtual machine migration is done.
- Due to an incorrect condition in the code, the
SPICEclient could attempt to free memory that has already been freed. Therefore, when the KDE desktop screen of the client machine with the running SPICE client was locked, the SPICE client terminated unexpectedly with a segmentation fault after unlocking the screen. The code has been modified to free memory correctly, and the SPICE client no longer crashes in the scenario described.
- When running multiple
SPICEclient sessions at the same time and the screen resolution on the client machine was changed, the SPICE client could often enter an infinite loop in the code. As a consequence, the X Windows server consumed up to 100% of CPU and caused the client machine to be unresponsive. With this update, the underlying code has been modified to prevent the client from entering the loop, and the problem no longer occurs.
- The help description for the
--disable-effectsclient WAN options was inaccurate. With this update, the
spicec --helpcommand now clearly states that these WAN options have effect only
if supported by the guest vdagent.
- Due to the way the
SPICEserver establishes secured connections, the SPICE client log contained secure-connection messages that included the misleading string,
connect_unsecure. With this update, the function used to establish secure connections has been renamed and secure-connection messages in the client log now contain the
- On a Linux guest that uses the Xinerama extension, X Windows creates a non-primary screen surface before it creates the primary screen surface when creating secondary screens on start up. Unfortunately, the
SPICEclient expected an existence of the primary screen surface when it attempted to handle the creation of non-primary screen surfaces. The primary surface did not exist at the time, therefore the SPICE client terminated unexpectedly. With this update, the SPICE client now ensures that the screen exists before starting operations on it. The SPICE client no longer crashes in the scenario described.
- Previously, the
--smartcard-dbclient command line option was not handled properly. As a consequence, when running with this option, the
SPICEclient terminated with the following error message:
Error: unhandled exception: cmd line errorWith this update, the
--smartcard-dboption is now handled properly and the SPICE client works as expected using this option.
- When attempting to connect to a Linux guest using the
SPICEclient with WAN options and the SPICE agent (
vdagent) was running on the guest, the client initiated handshaking. If the vdagent did not support WAN options, it did not reply to the client and connection thus failed with the
vdagenttimeout. Also with certain WAN options, such as
--color-depth 16, the attempt to connect failed with the vdagent timeout even though no
vdagentwas running on the guest. With this update, the SPICE client checks capabilities of the vdagent. If vdagent does not support WAN options or there is no
vdagentrunning on the guest, the client continues with the message sequence initiation and connection is now successful.
- Due to a missing error code setting in the source code, the
exit code 0when running without the
--hostcommand line option, although the client correctly displayed the following error message:
spicec: missing --hostWith this update, the missing line in the code has been added, and the SPICE client now correctly exits with the
error code 14in this scenario.