提交 35140f33 编写于 作者: R Richard Levitte

Abdelilah Essiari <aes@george.lbl.gov> reports that for very small

records, EVP_EncodeUpdate() may misbehave.  This happens when there's
a record boundary between the two ending b64 equal signs, which makes
EVP_EncodeUpdate think there has been more than one EOF, and therefore
add an extra NUL at the end of the output buffer.  This fix corrects
that problem.
上级 15c2e126
...@@ -292,7 +292,17 @@ int EVP_DecodeUpdate(EVP_ENCODE_CTX *ctx, unsigned char *out, int *outl, ...@@ -292,7 +292,17 @@ int EVP_DecodeUpdate(EVP_ENCODE_CTX *ctx, unsigned char *out, int *outl,
/* If we are at the end of input and it looks like a /* If we are at the end of input and it looks like a
* line, process it. */ * line, process it. */
if (((i+1) == inl) && (((n&3) == 0) || eof)) if (((i+1) == inl) && (((n&3) == 0) || eof))
{
v=B64_EOF; v=B64_EOF;
/* In case things were given us in really small
records (so two '=' were given in separate
updates), eof may contain the incorrect number
of ending bytes to skip, so let's redo the count */
eof = 0;
if (d[n-1] == '=') eof++;
if (d[n-2] == '=') eof++;
/* There will never be more than two '=' */
}
if ((v == B64_EOF) || (n >= 64)) if ((v == B64_EOF) || (n >= 64))
{ {
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册