)]}'
{
  "commit": "71147d3763466094df692df97afef42e4ce26a4f",
  "tree": "4f85d8ee52549747bcd0fc4101f6344bdf45de80",
  "parents": [
    "41478ebb2fde8bdaad1a5554a4391c0834abfc07"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Thu Aug 14 15:25:30 2025 -0400"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Thu Aug 14 13:14:14 2025 -0700"
  },
  "message": "Deprecate EVP_PKEY_set_type\n\nThis function is practically useless. It makes a typed but empty key,\nwhich is somehow distinct from an untyped and empty key. Looking for\ncallers within our tests and externally, the patterns are:\n\n- EVP_PKEY_set_type(EVP_PKEY_X25519) followed by\n  EVP_PKEY_set1_tls_encodedpoint. This is regrettably needed for that\n  API to work, but we\u0027ve also marked EVP_PKEY_set1_tls_encodedpoint as\n  deprecated, I think because of this weird half-empty state. Sadly this\n  means we can never totally remove this, and we\u0027re stuck with some of\n  these half-empty states.\n\n- EVP_PKEY_set_type(EVP_PKEY_NONE). This is used in some tests by\n  callers who try to test their \"unknown type\" codepaths. The usual\n  pattern is they load a key and then set the type to EVP_PKEY_NONE.\n\n  The result of this is an empty EVP_PKEY, identical to just calling\n  EVP_PKEY_new. Loading the key was never useful. It\u0027s also an error!\n  The function fails because EVP_PKEY_NONE is not a supported type.\n  Callers were relying on a quirk that we clear the key before noticing\n  the parameters are wrong. Write a test and update the comment so we\n  don\u0027t forget this behavior is depended on. (Though I\u0027m going to try to\n  fix everyone relying on this.)\n\n- EVP_PKEY_set_type(EVP_PKEY_RSA), etc. This does not produce a valid\n  key. It\u0027s done in some test code to avoid loading a real key. Our own\n  tests do this too, though it\u0027s also to test that\n  EVP_PKEY_missing_parameters works for this weird empty state, that\n  ideally wouldn\u0027t be possible in the first place.\n\nThe immediate motivation is that the work to make EVP more\nstatic-linker-friendly collides a bit with\nEVP_PKEY_set_type(EVP_PKEY_EC). If we\u0027re trying to treat P-256 and P-384\nas distinct EVP_PKEY types, it\u0027s unclear how that operation is supposed\nto work.\n\nBug: 42290409\nChange-Id: Id4368e049abea698f0eaed1419cb366a5fe3a424\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81269\nAuto-Submit: David Benjamin \u003cdavidben@google.com\u003e\nReviewed-by: Lily Chen \u003cchlily@google.com\u003e\nCommit-Queue: Lily Chen \u003cchlily@google.com\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "82a98dda5c0b5921d570b94a3934f5e596e9c9cd",
      "old_mode": 33188,
      "old_path": "crypto/evp/evp.cc",
      "new_id": "806c34c3b90aac25e9116a001867f8c5edbb6750",
      "new_mode": 33188,
      "new_path": "crypto/evp/evp.cc"
    },
    {
      "type": "modify",
      "old_id": "eac46e8e8f9cd48bfd6f156b98bbf20ed442f84d",
      "old_mode": 33188,
      "old_path": "crypto/evp/evp_extra_test.cc",
      "new_id": "f39f49343fb3e154a8a3604a3a12d972943d5716",
      "new_mode": 33188,
      "new_path": "crypto/evp/evp_extra_test.cc"
    },
    {
      "type": "modify",
      "old_id": "13bf55ef48a3e7c4c022db0a9b4273e4e5fdb907",
      "old_mode": 33188,
      "old_path": "include/openssl/evp.h",
      "new_id": "805aed632ee0a2c35182a18761f64e8363400aac",
      "new_mode": 33188,
      "new_path": "include/openssl/evp.h"
    }
  ]
}