)]}'
{
  "commit": "16bb6cde3f7d7517b859df01320f9bcdb8c8567b",
  "tree": "39b6bea9f8610ced9e67638cfc242a59e245b20e",
  "parents": [
    "df41163cb2463d62c9b217ea06aa667a1a01b706"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Mon May 11 12:06:51 2026 -0400"
  },
  "committer": {
    "name": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Mon May 11 09:35:33 2026 -0700"
  },
  "message": "Fixup some minor issues in HPKE P-256 key derivation\n\np256_private_key_from_seed should reject the zero scalar. It is\ncomputationally infeasible to find any input that hits this case, so no\nunit test or practical consequence, but we should match the spec I\nsuppose.\n\nSee https://www.rfc-editor.org/rfc/rfc9180.html#name-derivekeypair\n\nAlso add some missing error checks for p256_public_from_private. Other\nthan the computationally infeasible zero scalar above, this is\nimpossible except for ec_point_mul_scalar_base\u0027s fault protection logic\n(which is impossible unless there\u0027s another bug or CPU fault).\n\nChange-Id: I6961601f4036829c8dba990922b4135c0e141df8\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/95188\nAuto-Submit: David Benjamin \u003cdavidben@google.com\u003e\nPresubmit-BoringSSL-Verified: boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com \u003cboringssl-scoped@luci-project-accounts.iam.gserviceaccount.com\u003e\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "130a9b37c11d11f3e3c615dc1b31cf225f45859c",
      "old_mode": 33188,
      "old_path": "crypto/hpke/hpke.cc",
      "new_id": "2365a53b183095d9479e8bca74f10fe0e1c939af",
      "new_mode": 33188,
      "new_path": "crypto/hpke/hpke.cc"
    }
  ]
}