)]}'
{
  "commit": "ddecaabdc8c950d1417ed69785ac17c3400bae4c",
  "tree": "d11de0a32114a04874fc820c67a915c0e3aef26e",
  "parents": [
    "a4646740ecee1190a5f0d085b4aa172311a16ad8"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Thu May 13 13:53:36 2021 -0400"
  },
  "committer": {
    "name": "CQ bot account: commit-bot@chromium.org",
    "email": "commit-bot@chromium.org",
    "time": "Fri May 14 21:00:23 2021 +0000"
  },
  "message": "Check hs-\u003eearly_session, not ssl-\u003esession, for the early data limit.\n\nServerHello/EncryptedExtensions/Finished is logically one atomic flight\nthat exits the early data state, we have process each message\nsequentially. Until we\u0027ve processed Finished, we are still in the early\ndata state and must support writing data. Individual messages *are*\nprocessed atomically, so the interesting points are before ServerHello\n(already tested), after ServerHello, and after EncryptedExtensions.\n\nThe TLS 1.3 handshake internally clears ssl-\u003esession when processing\nServerHello, so getting the early data information from ssl-\u003esession\ndoes not work. Instead, use hs-\u003eearly_session, which is what other\ncodepaths use.\n\nI\u0027ve tested this with runner rather than ssl_test, so we can test both\npost-SH and post-EE states. ssl_test would be more self-contained, since\nwe can directly control the API calls, but it cannot test the post-EE\nstate. To reduce record overhead, our production implementation packs EE\nand Finished into the same record, which means the handshake will\nprocess the two atomically. Instead, I\u0027ve tested this in runner, with a\nflag to partially drive the handshake before reading early data.\n\nI\u0027ve also tweaked the logic to hopefully be a little clearer.\n\nBug: chromium:1208784\nChange-Id: Ia4901042419c5324054f97743bd1aac59ebf8f24\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47485\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "457696d813f3e3a153a96e800d596cbbc15c8d9c",
      "old_mode": 33188,
      "old_path": "ssl/s3_pkt.cc",
      "new_id": "450f7dc0b028a6268697d34e82d3f880e365cef5",
      "new_mode": 33188,
      "new_path": "ssl/s3_pkt.cc"
    },
    {
      "type": "modify",
      "old_id": "89313493c687dcff69b25f5a421ab1c901f4313c",
      "old_mode": 33188,
      "old_path": "ssl/test/bssl_shim.cc",
      "new_id": "9438c1f11ac6b948ca7ba81c4a5b6a0f07d4d1b1",
      "new_mode": 33188,
      "new_path": "ssl/test/bssl_shim.cc"
    },
    {
      "type": "modify",
      "old_id": "c169d2d05247ae1d5355a5dec4ceedf1e0f117ca",
      "old_mode": 33188,
      "old_path": "ssl/test/runner/runner.go",
      "new_id": "f802585f185e48228e5e3e1d371c88a7a97f7311",
      "new_mode": 33188,
      "new_path": "ssl/test/runner/runner.go"
    },
    {
      "type": "modify",
      "old_id": "fff536f3e8e1a6f81f0e91310fa88a93afaf7d02",
      "old_mode": 33188,
      "old_path": "ssl/test/test_config.cc",
      "new_id": "e933f0f996cc6de4ae772044265eaa8d6c697373",
      "new_mode": 33188,
      "new_path": "ssl/test/test_config.cc"
    },
    {
      "type": "modify",
      "old_id": "f4e3f61a536ac663868e11cc04ecfc5a559fb264",
      "old_mode": 33188,
      "old_path": "ssl/test/test_config.h",
      "new_id": "f4ddba236b8daeb138eca8e298014185d310c45e",
      "new_mode": 33188,
      "new_path": "ssl/test/test_config.h"
    },
    {
      "type": "modify",
      "old_id": "2c558a425c248a541f187f1a8f1d581ff2d6c150",
      "old_mode": 33188,
      "old_path": "ssl/test/test_state.h",
      "new_id": "d9fe945ac2821704d7d6d4e864b0ea7aa0b5c83b",
      "new_mode": 33188,
      "new_path": "ssl/test/test_state.h"
    }
  ]
}
