)]}'
{
  "commit": "adc5ec856c557f75adc60b310e5b1d38210a289c",
  "tree": "4d53ad321f8261bee2f8e0bcc3aa6a1390f238a3",
  "parents": [
    "8a34a0fb03191770a77026da164f3ad589c61407"
  ],
  "author": {
    "name": "aliguori",
    "email": "aliguori@c046a42c-6fe2-441c-8c8c-71466251a162",
    "time": "Fri Mar 06 20:27:02 2009 +0000"
  },
  "committer": {
    "name": "aliguori",
    "email": "aliguori@c046a42c-6fe2-441c-8c8c-71466251a162",
    "time": "Fri Mar 06 20:27:02 2009 +0000"
  },
  "message": "Fix bug in TLS authentication (\"Daniel P. Berrange\")\n\nThis patch was previously posted here:\n\n  http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00820.html\n\nIn the case where the TLS handshake does *not* block on I/O, QEMU\nsends the next \u0027start sub-auth\u0027 message twice. This seriously confuses\nthe VNC client :-) Fortunately the chances of the handshake not blocking\nare close to zero for a TCP socket, which is why it has not been noticed\nthus far. Even with both client \u0026 server on localhost, I can only hit the\nbug 1 time in 20.\n\nNB, the diff context here is not too informative. If you look at the\nfull code you\u0027ll see that a few lines early we called vnc_start_tls()\nwhich called vnc_continue_handshake() which called the method\nstart_auth_vencrypt_subauth(). Hence, fixing the bug, just involves\nremoving the 2nd bogus call to start_auth_vencrypt_subauth() as per\nthis patch.\n\n\n vnc.c |    8 --------\n 1 file changed, 8 deletions(-)\n\n   Signed-off-by: Daniel P. Berrange \u003cberrange@redhat.com\u003e\nSigned-off-by: Anthony Liguori \u003caliguori@us.ibm.com\u003e\n\n\ngit-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6719 c046a42c-6fe2-441c-8c8c-71466251a162\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "67cec07a89bd8c1f758a896bfd51b01e6e3bd3db",
      "old_mode": 33188,
      "old_path": "vnc.c",
      "new_id": "816923410bd0293586d9dc7f404ae91a024ddc1d",
      "new_mode": 33188,
      "new_path": "vnc.c"
    }
  ]
}