)]}'
{
  "commit": "aa8d3b5a53ecff9befb7b0edcbbe56bb94dd3ae0",
  "tree": "60def8895ff7422f5e7d4ceadaca98cd4c95bdba",
  "parents": [
    "7c860a4f8e0ddd33bed326dfa7903c9c2ba12433"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Sat Feb 11 09:51:23 2023 -0500"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Wed Feb 22 20:05:39 2023 +0000"
  },
  "message": "Reject zero ECDSA keys in EC_KEY_set_private_key\n\nWe already reject values that are out of bounds. Also we were using the\nwrong error, so fix that. Zero should additionally be rejected,\notherwise, when signing an all-zero digest (impossible unless your\nsystem signs untrusted, pre-hashed inputs), ECDSA can infinite loop.\nThanks to Guido Vranken who reported an analogous issue with DSA in\nhttps://github.com/openssl/openssl/issues/20268\n\nWhen EC_KEYs are obtained through the parser, this CL is a no-op. The\ncorresponding public key is the point at infinity, which we\u0027ll reject at\nboth parse time and in EC_KEY_check_key. But as EC_KEY runs into\nOpenSSL\u0027s usual API design flaw (mutable, field-by-field setters over\nconstructor functions for immutable objects), we should reject this in\nEC_KEY_set_private_key too.\n\nUpdate-Note: Systems that manually construct an EC_KEY (i.e. not from\nparsing), and either omit the public key or don\u0027t call EC_KEY_check_key\nwill start rejecting the zero private key. If such a system *also* signs\nuntrusted digests, this fixes an infinite loop in ECDSA.\n\nChange-Id: I3cc9cd2cc59eb6d16826beab3db71d66b23e83ff\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57226\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "7fe2bced70e22c64708050b294c1993bff0352a7",
      "old_mode": 33188,
      "old_path": "crypto/evp/evp_tests.txt",
      "new_id": "b86b2aa547850e000c7ba7956763bf874431fcf5",
      "new_mode": 33188,
      "new_path": "crypto/evp/evp_tests.txt"
    },
    {
      "type": "modify",
      "old_id": "f391a61c7bfe1d6ffdb34fff74cb4c64e0a21679",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/ec/ec_key.c",
      "new_id": "e427e3c5df419d061372c476e599ae8838a63ace",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/ec/ec_key.c"
    },
    {
      "type": "modify",
      "old_id": "571ea58070fde5b8d63d1f8d003b984c267452e3",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/ec/ec_test.cc",
      "new_id": "9ccc54b72b6e20135bd4f320b7ec6053089fa116",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/ec/ec_test.cc"
    }
  ]
}