Comment 5 for bug 1589923

I added this to my list a while ago but now closed out the immediate tasks for artful, so I'm coming back here.
Writing repro steps which will be needed for the SRU.

# Brute force create dummy keys for this
openssl req -out ca.pem -new -x509
openssl genrsa -out server.key 1024
openssl req -key server.key -new -out server.req
echo 00 > file.srl
openssl x509 -req -in server.req -CA ca.pem -CAkey privkey.pem -CAserial file.srl -out server-cert.pem
openssl genrsa -out client.key 1024
openssl req -key client.key -new -out client.req
openssl x509 -req -in client.req -CA ca.pem -CAkey privkey.pem -CAserial file.srl -out client-cert.pem
ln -s ca.pem ca-cert.pem
ln -s server.key server-key.pem

# run qemu with x509 websocket
/usr/bin/qemu-system-x86_64 -vnc 0.0.0.0:1,tls,x509=$(pwd),websocket=5707

It is not crashing and I can even connect with krdc (likely also other clients) against it without breaking.

But then I'd think your command above for the crash was the one for the crash in 2.6 which was yakkety.

But what is left to fix is the dropped connection [1] in 2.5 (Xenial).

I tried to read a better testcase out of that mail thread but failed, if you'd have a better setup description to still trigger this blocked handshake that eventually fails once the signal sets data - that would be great.
The actual report I found [2] is actually this bug bridges onto the ML so no more info there for me.

[1]: https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01884.html
[2]: https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01917.html