)]}'
{
  "commit": "310db06b79a8a997e077dc88bb2327992fad37bb",
  "tree": "ede69764d419321645945ee9fa9c268be78b20c2",
  "parents": [
    "fbdfefb76e8a81fd05f24be5d8c3f8732a5e6223"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@chromium.org",
    "time": "Mon Feb 16 21:06:04 2015 -0500"
  },
  "committer": {
    "name": "Adam Langley",
    "email": "agl@google.com",
    "time": "Tue Feb 17 21:03:29 2015 +0000"
  },
  "message": "Don\u0027t EVP_PKEY_copy_parameters when configuring cert and key.\n\nI believe this is a remnant of DSA. The logic strangely fails to check for\nfailure and then goes out of its way to ERR_clear_error. I believe this is so\nthat keys that are missing parameters silently move on. This dates to\nupstream\u0027s dfeab0689f69c0b4bd3480ffd37a9cacc2f17d9c, which is SSLeay 0.9.1b. At\nthat time, EVP_PKEY_copy_parameters only did anything for DSA. (Now it only\ndoes anything for ECDSA.)\n\nMy read is that this comes from DSA in PKIX\u0027s \"optional domain parameters\"\ncraziness. RFC 3279 says:\n\n   If the DSA domain parameters are omitted from the SubjectPublicKeyInfo\n   AlgorithmIdentifier and the CA signed the subject certificate using a\n   signature algorithm other than DSA, then the subject\u0027s DSA domain parameters\n   are distributed by other means.\n\nThis was probably part of some weird thing where, if your certificate is\nmissing parameters, the server would know what to use based on the private key.\n\n(Also this was making the malloc tests unhappy.)\n\nChange-Id: I8d8122a9f50a19e2bbe067f311a8e2d30774935c\nReviewed-on: https://boringssl-review.googlesource.com/3484\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "3d1bc622f1e26b5102461b57cd6cdf6fa4a03825",
      "old_mode": 33188,
      "old_path": "ssl/ssl_rsa.c",
      "new_id": "9fe73a701bc031791030cacfd332849d151f67e3",
      "new_mode": 33188,
      "new_path": "ssl/ssl_rsa.c"
    }
  ]
}