)]}'
{
  "commit": "de2cf273d76e94ee47cb4ed7e9826f68175ec217",
  "tree": "5da0c4fd46b015aad3fa6f38c9f99feca1a3bd32",
  "parents": [
    "e31e0123ea331f640852dac55c072b4cec3e3ff8"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Tue May 03 09:19:36 2016 -0400"
  },
  "committer": {
    "name": "Adam Langley",
    "email": "agl@google.com",
    "time": "Tue May 03 16:45:42 2016 +0000"
  },
  "message": "Avoid theoretical overflows in EVP_EncodeUpdate.\n\nSee also upstream\u0027s 172c6e1e14defe7d49d62f5fc9ea6a79b225424f, but note our\nvalues have different types. In particular, because we put in_len in a size_t\nand C implicitly requires that all valid buffers\u0027 lengths fit in a ptrdiff_t\n(signed), the overflow was impossible, assuming EVP_ENCODE_CTX::length is\nuntouched externally.\n\nMore importantly, this function is stuck taking an int output and has no return\nvalue, so the only plausible contract is the caller is responsible for ensuring\nthe length fits anyway. Indeed, callers all call EVP_EncodeUpdate in bounded\nchunks, so upstream\u0027s analysis is off.\n\nAnyway, in theory that logic could locally overflow, so tweak it slightly. Tidy\nup some of the variable names while I\u0027m here.\n\nChange-Id: Ifa78707cc26c11e0d67019918a028531b3d6738c\nReviewed-on: https://boringssl-review.googlesource.com/7847\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "4822fb89e2e0bed9f82cc82dccce4035de32427c",
      "old_mode": 33188,
      "old_path": "crypto/base64/base64.c",
      "new_id": "61f79cda166c6a2460573c8b01945c9bf22538a7",
      "new_mode": 33188,
      "new_path": "crypto/base64/base64.c"
    }
  ]
}