)]}' { "commit": "13e81fc971df6b2ac0e79e68ee23eee3ca970971", "tree": "fd223cf619949b51b8bd91bbb98e0d73d72a1b3f", "parents": [ "ebda9b3736a685d667c856bce4f2e0d109bdede6" ], "author": { "name": "David Benjamin", "email": "davidben@chromium.org", "time": "Mon Nov 02 17:16:13 2015 -0500" }, "committer": { "name": "Adam Langley", "email": "agl@google.com", "time": "Mon Nov 02 23:16:22 2015 +0000" }, "message": "Fix DTLS asynchronous write handling.\n\nAlthough the DTLS transport layer logic drops failed writes on the floor, it is\nactually set up to work correctly. If an SSL_write fails at the transport,\ndropping the buffer is fine. Arguably it works better than in TLS because we\ndon\u0027t have the weird \"half-committed to data\" behavior. Likewise, the handshake\nkeeps track of how far its gotten and resumes the message at the right point.\n\nThis broke when the buffering logic was rewritten because I didn\u0027t understand\nwhat the DTLS code was doing. The one thing that doesn\u0027t work as one might\nexpect is non-fatal write errors during rexmit are not recoverable. The next\ntimeout must fire before we try again.\n\nThis code is quite badly sprinkled in here, so add tests to guard it against\nfuture turbulence. Because of the rexmit issues, the tests need some hacks\naround calls which may trigger them. It also changes the Go DTLS implementation\nfrom being completely strict about sequence numbers to only requiring they be\nmonotonic.\n\nThe tests also revealed another bug. This one seems to be upstream\u0027s fault, not\nmine. The logic to reset the handshake hash on the second ClientHello (in the\nHelloVerifyRequest case) was a little overenthusiastic and breaks if the\nClientHello took multiple tries to send.\n\nChange-Id: I9b38b93fff7ae62faf8e36c4beaf848850b3f4b9\nReviewed-on: https://boringssl-review.googlesource.com/6417\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\n", "tree_diff": [ { "type": "modify", "old_id": "2acf4550ed445752297d31304f186ca859dcb8bf", "old_mode": 33188, "old_path": "include/openssl/ssl.h", "new_id": "f9e0d85bd65b2b0698e125c70ba5d5323305e32e", "new_mode": 33188, "new_path": "include/openssl/ssl.h" }, { "type": "modify", "old_id": "3dd5f8c5cac4fffb49fd98551adca6836b842e7f", "old_mode": 33188, "old_path": "ssl/d1_clnt.c", "new_id": "7924598e46dba1c35d9964ab238a8be0c1faabc5", "new_mode": 33188, "new_path": "ssl/d1_clnt.c" }, { "type": "modify", "old_id": "13bc0e82989e8da491ad1714bf3df871d601c9be", "old_mode": 33188, "old_path": "ssl/s3_clnt.c", "new_id": "12eb5e09097be7f6280a17f354c0063b74d50f4b", "new_mode": 33188, "new_path": "ssl/s3_clnt.c" }, { "type": "modify", "old_id": "63dcd8065f82bf77f10e23fe94558556909f611e", "old_mode": 33188, "old_path": "ssl/ssl_buffer.c", "new_id": "f1abc5376468c5d8dcf99127b3d11f04e0cd9b05", "new_mode": 33188, "new_path": "ssl/ssl_buffer.c" }, { "type": "modify", "old_id": "05348457d85f3b246478c691c7953984d1d5e345", "old_mode": 33188, "old_path": "ssl/test/async_bio.cc", "new_id": "7a5737bbeab910a8f746aaa0914f9fb4e341901f", "new_mode": 33188, "new_path": "ssl/test/async_bio.cc" }, { "type": "modify", "old_id": "1ccdf9b872a20875f8f8df6e3a0597f5b52496be", "old_mode": 33188, "old_path": "ssl/test/async_bio.h", "new_id": "fbc40163eefe9f11917f92978d8b42e66f0ecc29", "new_mode": 33188, "new_path": "ssl/test/async_bio.h" }, { "type": "modify", "old_id": "3f4e9cf4c7391a16d741c4595fd28bc54c0b106d", "old_mode": 33188, "old_path": "ssl/test/bssl_shim.cc", "new_id": "32c572e261809bc85430fa40084779ccfba62055", "new_mode": 33188, "new_path": "ssl/test/bssl_shim.cc" }, { "type": "modify", "old_id": "986e2b5d0e369601b8e86ce7d45c9b8e41e0d3cd", "old_mode": 33188, "old_path": "ssl/test/runner/conn.go", "new_id": "c911ad02b4261b386a28dee15a2b07cc0333637c", "new_mode": 33188, "new_path": "ssl/test/runner/conn.go" }, { "type": "modify", "old_id": "fac035e3e20c62aebcbe104657ce685c47af21fd", "old_mode": 33188, "old_path": "ssl/test/runner/dtls.go", "new_id": "c3ee52189179247731c6ceb31556ce8d5e2dc14d", "new_mode": 33188, "new_path": "ssl/test/runner/dtls.go" } ] }