2017-02-09 Daniel P. Berrange Bump to 0.7.0 for new release 2017-02-08 Daniel P. Berrange Clamp cursor hot-pixel to be within cursor region Some broken VNC servers send hot-pixel outside bounds of the cursor. We could disconnect and report an error, but it is more user friendly to just clamp the hot pixel coords https://bugzilla.gnome.org/show_bug.cgi?id=775394 2017-02-08 Eric R. Schulz Fix memory leaks Call gnutls_deinit() after gnutls_bye(). Call g_free() in finalize(). Call g_free() in vnc_grab_sequence_free(). 2017-02-08 Daniel P. Berrange Fix some misc warnings & mem leak in test case 2017-02-08 Christophe Fergeau README: Update URL to home page The old page no longer seems to exist in GNOME's wiki. Add preconditions to VncDisplay public methods This should catch invalid arguments being passed to these. This required moving the VncDisplayPrivate *priv = display->priv; assignment as the VNC_IS_DISPLAY(display) check is also a NULL check which we want to happen before dereferencing it. Avoid crash if attempt to connect to an invalid host or port If vnc_display_open_host() is called with a NULL port or host, vnc_connection_open_host_internal() will eventually crash. This commits adds runtime checks to return early with g_return_val_if_fail() when this happens rather than crashing #0 0x00007ffff37de3d3 in __strchr_sse2 () at ../sysdeps/x86_64/strchr.S:32 #1 0x00007ffff4661a17 in g_inet_socket_address_new_from_string (address=0x0, port=0) at ginetsocketaddress.c:416 #2 0x00007ffff466b784 in g_network_address_parse_sockaddr (addr=addr@entry=0x969f50 [GNetworkAddress]) at gnetworkaddress.c:245 #3 0x00007ffff466ba94 in g_network_address_address_enumerator_next (enumerator=0x972ca0 [GNetworkAddressAddressEnumerator], cancellable=0x0, error=) at gnetworkaddress.c:919 #4 0x00007ffff727130b in vnc_connection_open_host_internal (conn=0x99bbf0 [VncConnection]) at vncconnection.c:5395 #5 0x00007ffff7271523 in vnc_connection_coroutine (opaque=0x99bbf0) at vncconnection.c:5448 #6 0x00007ffff7272e54 in coroutine_trampoline (cc=0x998080) at coroutine_ucontext.c:55 #7 0x00007ffff7272b65 in continuation_trampoline (i0=10059904, i1=0) at continuation.c:43 #8 0x00007ffff379dc00 in __start_context () at /lib64/libc.so.6 #9 0x0000000000998448 in () #10 0x0000000000000000 in () 2017-02-08 Rico Tzschichholz Add missing vala .deps files for gvnc & gvncpulse https://bugzilla.gnome.org/show_bug.cgi?id=772322 2017-02-07 Daniel P. Berrange Correctly validate color map range indexes The color map index could wrap around to zero causing negative array index accesses. https://bugzilla.gnome.org/show_bug.cgi?id=778050 CVE-2017-5885 Don't accept color map entries for true-color pixel format The color map entries should only be sent by the server when true-color flag is false. Fix bounds checking for RRE, hextile & copyrect encodings While the client would bounds check the overall update region, it failed to bounds check the payload data parameters. Add a test case to validate bounds checking. https://bugzilla.gnome.org/show_bug.cgi?id=778048 CVE-2017-5884 2017-01-26 Daniel P. Berrange Add workaround to avoid hangs when connecting to SPICE When used with QEMU at least, both SPICE and VNC live in the same port range (5900+). It is thus not entirely uncommon for a user to mistakenly connect to a SPICE server with a VNC client, or vica-verca. When connecting to VNC server with a SPICE client, you quickly get an error. This is because the VNC server sends its short greeting and then sees the RedLinkMess from the SPICE client, realizes its garbage and drops the connection. When connecting to a SPICE server with a VNC client though, you get an indefinite hang. The VNC client is waiting for the VNC greeting, which the SPICE server will never send. The SPICE server is waiting for the RedLinkMess which the VNC client will never send. In VNC the protocol starts with the follow data sent: Server: "RFB 003.008\n" Client: "RFB 003.008\n" This can be tweaked so the client proactively sends the first four bytes Client: "RFB " Server: "RFB 003.008\n" Client: "003.008\n" From the VNC server POV, it'll still be receiving the same 12 bytes from the client - it just happens that 4 of them might arrive a tiny bit earlier than the other 8 of them. IOW nothing should break in the VNC server from this change. The SPICE server, waiting for its RedLinkMess message will see these four bytes "RFB " and interpret them as the SPICE magic number. This will be invalid and so the SPICE server will drop the connection. This avoids the VNC client hanging forever when connecting to a SPICE server by mistake. 2016-10-26 Felix E. Klee Added menu option for smooth scaling Added option for smooth scaling Smooth scaling can now be turned off by setting the option "smoothing" to false. 2016-08-18 Piotr Drąg Updated Polish translation