)]}'
{
  "commit": "ee477d433e0297dcdd4e51139fcbd0700cf794df",
  "tree": "e2acc6bec929890f1157ef89e3f501188f18af96",
  "parents": [
    "8a3b2692bcc68ea4c68d2bdd00d5ec647e33b769"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Fri Aug 26 16:24:49 2022 -0400"
  },
  "committer": {
    "name": "Adam Langley",
    "email": "agl@google.com",
    "time": "Mon Aug 29 20:40:17 2022 +0000"
  },
  "message": "Add EVP_HPKE_KDF_hkdf_md.\n\nSome HPKE consumers call into the KDF directly. We don\u0027t have an EVP_KDF\nabstraction and it\u0027s not clear to me how settled \"KDF\" is as an\ninterface. (HPKE specifically assumes an extract/expand pair.)\n\nFor now, just add EVP_HPKE_KDF_hkdf_md which is defined to only work for\nHKDF KDFs. As we don\u0027t implement ID -\u003e KDF lookup ourselves and expect\ncallers to decide which algorithms they want to export, any future\nnon-HKDF-based KDF won\u0027t affect existing callers anyway. If that\nhappens, we can make this return an EVP_KDF or just add\nEVP_HPKE_KDF_{extract,expand} depending on universal this turns out to\nbe.\n\nChange-Id: I93b9c8a5340472974a6f1bfc45154371d8971600\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54085\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\nCommit-Queue: Adam Langley \u003cagl@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "6e3d5e871cbee700bdbd849037025b10cd673141",
      "old_mode": 33188,
      "old_path": "crypto/hpke/hpke.c",
      "new_id": "e49b46df319a130950821e9ce87d196b78003ede",
      "new_mode": 33188,
      "new_path": "crypto/hpke/hpke.c"
    },
    {
      "type": "modify",
      "old_id": "5b0373db0f3d546afc33a44169359119615dce1d",
      "old_mode": 33188,
      "old_path": "include/openssl/hpke.h",
      "new_id": "c90dfb4f49747605c72ae081b220756433190c98",
      "new_mode": 33188,
      "new_path": "include/openssl/hpke.h"
    }
  ]
}