)]}'
{"id":"openvpn~1831","triplet_id":"openvpn~master~Ib0e7c9d3a2f4e6b8c1d5a9f7e3b2c4d6a8f1e5b3","project":"openvpn","branch":"master","attention_set":{},"removed_from_attention_set":{"1000003":{"account":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"last_update":"2026-08-03 15:10:11.000000000","reason":"\u003cGERRIT_ACCOUNT_1000003\u003e replied on the change","reason_account":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"}},"1000001":{"account":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"last_update":"2026-08-13 16:25:42.000000000","reason":"Change was submitted"}},"hashtags":["mailsubmitted"],"change_id":"Ib0e7c9d3a2f4e6b8c1d5a9f7e3b2c4d6a8f1e5b3","subject":"ssl: Do not queue control ciphertext while a packet is still queued","status":"MERGED","created":"2026-07-30 09:03:40.000000000","updated":"2026-08-13 16:25:42.000000000","submitted":"2026-08-13 16:25:42.000000000","submitter":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"total_comment_count":1,"unresolved_comment_count":0,"has_review_started":true,"submission_id":"1831","meta_rev_id":"5ff34c39fd439873674aee5bea2bb113c6fae677","_number":1831,"virtual_id_number":1831,"owner":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"actions":{},"labels":{"Code-Review":{"all":[{"value":0,"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},{"value":0,"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"}],"values":{"-2":"This shall not be submitted","-1":"I would prefer this is not submitted as is"," 0":"No score","+1":"Looks good to me, but someone else must approve","+2":"Looks good to me, approved"},"default_value":0}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"}],"CC":[{"_account_id":1000026,"name":"openvpn-devel","email":"openvpn-devel@lists.sourceforge.net","username":"openvpn-devel"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2026-07-30 09:03:41.000000000","updated_by":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"reviewer":{"_account_id":1000026,"name":"openvpn-devel","email":"openvpn-devel@lists.sourceforge.net","username":"openvpn-devel"},"state":"CC"},{"updated":"2026-07-30 09:03:41.000000000","updated_by":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"reviewer":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"state":"REVIEWER"}],"messages":[{"id":"1bbd7e56da2e51ea307b4e5dc13bdeef2291d952","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2026-07-30 09:03:40.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"e3943de44d3235645887709c7e062d9dae9ef195","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2026-08-03 15:10:11.000000000","message":"Patch Set 1: Code-Review+2\n\n(1 comment)","accounts_in_message":[],"_revision_number":1},{"id":"cd1088ec0b41cf081b137682e904d4be655044e7","tag":"autogenerated:gerrit:setHashtag","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2026-08-05 13:43:46.000000000","message":"Hashtag added: mailsubmitted","accounts_in_message":[],"_revision_number":1},{"id":"5ff34c39fd439873674aee5bea2bb113c6fae677","tag":"autogenerated:gerrit:merged","author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2026-08-13 16:25:42.000000000","message":"Change has been successfully pushed.","accounts_in_message":[],"_revision_number":2}],"current_revision_number":2,"current_revision":"f264f6274b1696d28b277f5dd0fa93d889eb6f80","revisions":{"1e8bc06b45f792230e2bea4643053a50fade344c":{"kind":"REWORK","_number":1,"created":"2026-07-30 09:03:40.000000000","uploader":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"ref":"refs/changes/31/1831/1","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/31/1831/1","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/31/1831/1 \u0026\u0026 git checkout -b change-1831 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/31/1831/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/31/1831/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/31/1831/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/31/1831/1","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/31/1831/1 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"2c8baca423b236ab12f7519b68ed88b4a709d0d1","subject":"Correctly calculate packet id size when epoch packet format is in use"}],"author":{"name":"Frank Lichtenheld","email":"frank@lichtenheld.com","date":"2026-07-28 15:51:13.000000000","tz":120},"committer":{"name":"Frank Lichtenheld","email":"frank@lichtenheld.com","date":"2026-07-30 08:52:16.000000000","tz":120},"subject":"ssl: Do not queue control ciphertext while a packet is still queued","message":"ssl: Do not queue control ciphertext while a packet is still queued\n\nAn outgoing control channel packet is handed to the link layer as a\nbuffer descriptor pointing into the reliable send buffer it was built\nfrom, and the packet id sits in that buffer\u0027s headroom, right in front\nof the payload.  If the entry is reused before the packet has been\nwritten out, buf_copy_n() writes the new payload and\nreliable_mark_active_outgoing() prepends the new packet id exactly over\nthe packet id of the queued packet, while its opcode, ACK array and\nlength stay untouched.  The queued packet then goes out with somebody\nelse\u0027s packet id.\n\nObserved in a TCP p2p handshake: both peers reset simultaneously, the\npeer\u0027s two HARD_RESET packets arrive back to back, so io_wait_dowork()\ntakes the residual data shortcut (event_set_status \u003d SOCKET_READ) and\ndoes not write out our already queued HARD_RESET retransmit.  The ACK\nin the second peer reset then purges our reset from the send window,\ntls_process_state() moves to S_START and queues the ClientHello into\nthe very same (now inactive) entry.  Result on the wire: a HARD_RESET\nwith the ClientHello\u0027s packet id 1, followed by the ClientHello with\nthe same id 1.  The receiver consumes the reset, advances its receive\nwindow, and drops the real ClientHello as a replay - the handshake\ndeadlocks until it times out.\n\nThe send path in tls_process_state() and the dedicated ACK path in\ntls_process() are already guarded by to_link-\u003elen, only the ciphertext\nqueueing was not.  Guard it as well.  A pending to_link makes\ntls_process() report itself as active, so we are called again as soon\nas the packet has been written out.  In the error path this can drop a\nTLS alert that we would have queued, which is in line with that path\nnot ensuring delivery anyway.\n\nChange-Id: Ib0e7c9d3a2f4e6b8c1d5a9f7e3b2c4d6a8f1e5b3\nSigned-off-by: Frank Lichtenheld \u003cfrank@lichtenheld.com\u003e\n"},"branch":"refs/heads/master"},"f264f6274b1696d28b277f5dd0fa93d889eb6f80":{"kind":"TRIVIAL_REBASE_WITH_MESSAGE_UPDATE","_number":2,"created":"2026-08-13 16:25:42.000000000","uploader":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"ref":"refs/changes/31/1831/2","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/31/1831/2","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/31/1831/2 \u0026\u0026 git checkout -b change-1831 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/31/1831/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/31/1831/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/31/1831/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/31/1831/2","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/31/1831/2 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"800ba2cfccf2173c466f9b57381bb6244110117f","subject":"Fix extracting IV_MTU"}],"author":{"name":"Frank Lichtenheld","email":"frank@lichtenheld.com","date":"2026-08-05 13:43:36.000000000","tz":120},"committer":{"name":"Gert Doering","email":"gert@greenie.muc.de","date":"2026-08-13 14:58:59.000000000","tz":120},"subject":"ssl: Do not queue control ciphertext while a packet is still queued","message":"ssl: Do not queue control ciphertext while a packet is still queued\n\nAn outgoing control channel packet is handed to the link layer as a\nbuffer descriptor pointing into the reliable send buffer it was built\nfrom, and the packet id sits in that buffer\u0027s headroom, right in front\nof the payload.  If the entry is reused before the packet has been\nwritten out, buf_copy_n() writes the new payload and\nreliable_mark_active_outgoing() prepends the new packet id exactly over\nthe packet id of the queued packet, while its opcode, ACK array and\nlength stay untouched.  The queued packet then goes out with somebody\nelse\u0027s packet id.\n\nObserved in a TCP p2p handshake: both peers reset simultaneously, the\npeer\u0027s two HARD_RESET packets arrive back to back, so io_wait_dowork()\ntakes the residual data shortcut (event_set_status \u003d SOCKET_READ) and\ndoes not write out our already queued HARD_RESET retransmit.  The ACK\nin the second peer reset then purges our reset from the send window,\ntls_process_state() moves to S_START and queues the ClientHello into\nthe very same (now inactive) entry.  Result on the wire: a HARD_RESET\nwith the ClientHello\u0027s packet id 1, followed by the ClientHello with\nthe same id 1.  The receiver consumes the reset, advances its receive\nwindow, and drops the real ClientHello as a replay - the handshake\ndeadlocks until it times out.\n\nThe send path in tls_process_state() and the dedicated ACK path in\ntls_process() are already guarded by to_link-\u003elen, only the ciphertext\nqueueing was not.  Guard it as well.  A pending to_link makes\ntls_process() report itself as active, so we are called again as soon\nas the packet has been written out.  In the error path this can drop a\nTLS alert that we would have queued, which is in line with that path\nnot ensuring delivery anyway.\n\nChange-Id: Ib0e7c9d3a2f4e6b8c1d5a9f7e3b2c4d6a8f1e5b3\nSigned-off-by: Frank Lichtenheld \u003cfrank@lichtenheld.com\u003e\nAcked-by: Arne Schwabe \u003carne-openvpn@rfc2549.org\u003e\nGerrit URL: https://gerrit.openvpn.net/c/openvpn/+/1831\nMessage-Id: \u003c20260805134336.163392-1-frank@lichtenheld.com\u003e\nURL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg38133.html\nSigned-off-by: Gert Doering \u003cgert@greenie.muc.de\u003e\n"},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}