)]}'
{
  "commit": "8514bf3baf3a9a3c56785f9f8f28ff1a12d9489e",
  "tree": "77ea104da01877545b1287dca9e2d6db5eeb2f98",
  "parents": [
    "83824d298cf2272a265c44336a493c76d843b93a"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Sun Sep 22 15:17:44 2024 -0400"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Tue Sep 24 18:42:13 2024 +0000"
  },
  "message": "Add a test for a subtle corner of 0-RTT and version tracking\n\nThis is a huge mess. I was trying to simplify our version state to be:\n\n- Version not known\n- Version not known but sending 0-RTT at V\n- Version known to be V\n\nBut it turns out we can actually have both early version and true\nversions existing and at different values. There are two cases:\n\n1. We send TLS 1.3 early data and get back a TLS 1.2 ServerHello. We\n   will return an error but, at least right now, we continue to present\n   a self-consistent TLS 1.3 picture, even though we send the\n   protocol_version alert at TLS 1.2.\n\n2. [Does not exist yet] We send TLS 1.4 early data and get back a TLS\n   1.3 ServerHello. This isn\u0027t even fatal to the connection, so we\n   especially should keep reporting the early session until\n   SSL_reset_early_Data_reject.\n\nCase 2 is extra weird because we won\u0027t actually immediately flag the\nmismatch as a 0-RTT reject! Right now we don\u0027t run the reject ceremony\nuntil we read EncryptedExtensions, but at that point we\u0027ll have even\ndecrypted a record under the other version.\n\nBut this case also doesn\u0027t exist today. There is an analogous thing that\ndoes exist today with the cipher suite. For both the version and the\ncipher suite, we get around this right now by having the SSLAEADContext\nhold on to this information, so we pull it out of there.\n\nWe could instead run the rejection ceremony at multiple points in the\nhandshake, as soon as we detect any kind of inconsistency. Not sure\nwhich is best. Either way, let\u0027s test this case.\n\nChange-Id: I333175b25ba35261e1dd7d02e9ec1d9f1d43ff73\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/71531\nReviewed-by: Nick Harper \u003cnharper@chromium.org\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "37766b2aeba3ab3d5f813d0e0fa6b766f78e9f0e",
      "old_mode": 33188,
      "old_path": "ssl/ssl_test.cc",
      "new_id": "46d5af943a48cb08360900b8aaf1e04ec964727c",
      "new_mode": 33188,
      "new_path": "ssl/ssl_test.cc"
    },
    {
      "type": "modify",
      "old_id": "13ad4d10b4c5866dc3e8895e8274d379bb8647e2",
      "old_mode": 33188,
      "old_path": "ssl/ssl_versions.cc",
      "new_id": "2f71978c3265b47d15f617facd305acba9fccafc",
      "new_mode": 33188,
      "new_path": "ssl/ssl_versions.cc"
    }
  ]
}