)]}'
{
  "commit": "3d5cafde207b61ab405fbb9664c3493f7a380cb5",
  "tree": "e85d1676f77595b8f08211dbb34bcbd5c43fcaa0",
  "parents": [
    "40e356af73bb6467b31706730ac871cc4fedd8a9"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Thu Apr 23 10:21:30 2026 -0400"
  },
  "committer": {
    "name": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Fri Apr 24 18:11:42 2026 -0700"
  },
  "message": "Don\u0027t skip calling the cleanup hook in EVP_PKEY_CTX when the copy hook fails\n\nThis was only reachable from malloc failure. Way back in\nhttps://boringssl-review.googlesource.com/c/boringssl/+/13830 we\nimported a change from BoringSSL to stop calling cleanup when\nEVP_PKEY_CTX_dup failed. This supposedly fixed a crash (I didn\u0027t check\nif it did at the time) but instead caused different malloc failures to\nleak memory.\n\nNow that all our cleanup functions are just a call to C++ Delete, and we\nuse C++ scopers for all the fields, the EVP_PKEY_CTX state is in a\nconsistent enough state to delete all the time anyway.\n\nWhile I\u0027m here, I\u0027ve fixed the cleanup functions to all be more\nconsistent. Some of them reset ctx-\u003edata and some of them didn\u0027t. It\ndoesn\u0027t matter if we do because the object will be destroyed immediately\nafterwards, so I standardized on the shorter pattern.\n\nTo review this, check that a failure in the copy hook never leaves the\nEVP_PKEY_CTX in a state where the cleanup hook will not safely clean\nthis up. Note that bssl::Delete, like C++ delete, gracefully handles\nnullptr.\n\nChange-Id: I874b953efbef179f1387c0a2b2e0320e6c3ff2e6\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/93627\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\nReviewed-by: Rudolf Polzer \u003crpolzer@google.com\u003e\nAuto-Submit: David Benjamin \u003cdavidben@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "adac362fbe349aa9cec67004a03f0f32adcaf633",
      "old_mode": 33188,
      "old_path": "crypto/evp/evp_ctx.cc",
      "new_id": "ffb9b6f2e30870219a6f1d2a268dc157b3f7f52e",
      "new_mode": 33188,
      "new_path": "crypto/evp/evp_ctx.cc"
    },
    {
      "type": "modify",
      "old_id": "26c47702d3528d0fbc21ceca2ae9eea82b3e7abc",
      "old_mode": 33188,
      "old_path": "crypto/evp/p_dh.cc",
      "new_id": "eaf7fadc8416512976d5ee4aa12ff013cdc71798",
      "new_mode": 33188,
      "new_path": "crypto/evp/p_dh.cc"
    },
    {
      "type": "modify",
      "old_id": "cf5851832a48d3026064577b56019ab26f6c7052",
      "old_mode": 33188,
      "old_path": "crypto/evp/p_ec.cc",
      "new_id": "ac9a489d2d55b67bdf6e5db59d4da7a1c5efc98b",
      "new_mode": 33188,
      "new_path": "crypto/evp/p_ec.cc"
    },
    {
      "type": "modify",
      "old_id": "f1a8a35aef7e484203801c9df8082259479aac0a",
      "old_mode": 33188,
      "old_path": "crypto/evp/p_hkdf.cc",
      "new_id": "14cb76cbf3c97cf5a6002a6d91eb2262ab3e9ffe",
      "new_mode": 33188,
      "new_path": "crypto/evp/p_hkdf.cc"
    }
  ]
}