)]}'
{
  "commit": "50bc2ea0e8f60fec17dad62ef6e54a8aed284511",
  "tree": "aeedd43a3e332b6574578400a2214e73543af935",
  "parents": [
    "39da68f22fb420d069c1e0b2796e53c728839437"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Tue Mar 14 18:28:20 2023 -0400"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Tue Mar 14 22:48:20 2023 +0000"
  },
  "message": "Tidy up HMAC_Init_ex slightly\n\nGuarding the OPENSSL_memset was unnecessary since OPENSSL_memset with\nzero length works fine. Also OPENSSL_memset, to workaround a C bug,\ninternally does the same check anyway. (But also this wasn\u0027t a context\nwhere the C bug applied.)\n\nAlso don\u0027t bother calling EVP_MD_block_size a second time when we\nalready saved it into block_size.\n\nFinally, don\u0027t bother filling key_block up to the whole\nEVP_MAX_MD_BLOCK_SIZE size. I could believe the fixed size is easier for\nthe compiler to optimize, but the XORs in setting up an HMAC cannot\npossibly be performance-sensitive, and using the actual length is\nclearer.\n\nAlso add an assert that the hash\u0027s output size fits in the block size.\nWe\u0027re implicitly relying on this when hashing the key down.\n\nChange-Id: I6ce37d41ea5bdbc8890bde7910e1b5651bc35709\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58027\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\nAuto-Submit: David Benjamin \u003cdavidben@google.com\u003e\nCommit-Queue: Adam Langley \u003cagl@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "ca774bc05ec1740bcdb60dc400c9f555b12e4e44",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/hmac/hmac.c",
      "new_id": "c6f12e2ab73bdd825655736cfeb071363eab3005",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/hmac/hmac.c"
    }
  ]
}