de2cf273d7
See also upstream's 172c6e1e14defe7d49d62f5fc9ea6a79b225424f, but note our values have different types. In particular, because we put in_len in a size_t and C implicitly requires that all valid buffers' lengths fit in a ptrdiff_t (signed), the overflow was impossible, assuming EVP_ENCODE_CTX::length is untouched externally. More importantly, this function is stuck taking an int output and has no return value, so the only plausible contract is the caller is responsible for ensuring the length fits anyway. Indeed, callers all call EVP_EncodeUpdate in bounded chunks, so upstream's analysis is off. Anyway, in theory that logic could locally overflow, so tweak it slightly. Tidy up some of the variable names while I'm here. Change-Id: Ifa78707cc26c11e0d67019918a028531b3d6738c Reviewed-on: https://boringssl-review.googlesource.com/7847 Reviewed-by: Adam Langley <agl@google.com> |
||
---|---|---|
.. | ||
base64_test.cc | ||
base64.c | ||
CMakeLists.txt |