qemu/qemu-sasl-01-tls-handshake-fix.patch
Glauber Costa 8571d06737 - Set Epoch to 1
- Build KVM (basic build, no tools yet)
- Set ppc in ExcludeArch. This is temporary, just to fix one issue at a
    time. ppc users (IBM ? ;-)) please wait a little bit.
2009-03-03 23:57:07 +00:00

44 lines
1.5 KiB
Diff

This patch was previously posted here:
http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00820.html
In the case where the TLS handshake does *not* block on I/O, QEMU
sends the next 'start sub-auth' message twice. This seriously confuses
the VNC client :-) Fortunately the chances of the handshake not blocking
are close to zero for a TCP socket, which is why it has not been noticed
thus far. Even with both client & server on localhost, I can only hit the
bug 1 time in 20.
NB, the diff context here is not too informative. If you look at the
full code you'll see that a few lines early we called vnc_start_tls()
which called vnc_continue_handshake() which called the method
start_auth_vencrypt_subauth(). Hence, fixing the bug, just involves
removing the 2nd bogus call to start_auth_vencrypt_subauth() as per
this patch.
vnc.c | 8 --------
1 file changed, 8 deletions(-)
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Index: kvm-84.git-snapshot-20090303/qemu/vnc.c
===================================================================
--- kvm-84.git-snapshot-20090303.orig/qemu/vnc.c
+++ kvm-84.git-snapshot-20090303/qemu/vnc.c
@@ -2096,14 +2096,6 @@ static int protocol_client_vencrypt_auth
VNC_DEBUG("Failed to complete TLS\n");
return 0;
}
-
- if (vs->wiremode == VNC_WIREMODE_TLS) {
- VNC_DEBUG("Starting VeNCrypt subauth\n");
- return start_auth_vencrypt_subauth(vs);
- } else {
- VNC_DEBUG("TLS handshake blocked\n");
- return 0;
- }
}
return 0;
}